How is packet loss handled?
Note: I am not interested in how to avoid packet loss. This has been extensively covered in other threads. I have existing data with lost packets that I need to handle. So I want to know how, precisely, it manifests. Hopefully, someone can help.
For the setup, I'm running a Cyton on Bluetooth (the old Cyton, with batteries, I'd have to look up the revision if that's relevant) plus the OpenBCI_GUI v 6.0.0. beta-1.
So:
- Can I rely on the idea that the first column of the .csv created by the GUI will have skipped values, and the values that are skipped are the lost samples? So that I can e.g. just boost the timebase by an extra n *4 ms (1/250 Hz, right)? to have the correct offset after n dropped samples?
- Or can there be somehow skipped samples that don't show up in the .csv?
- Is there a difference to the .txt-raws, is either better to figure this out?
Knowing the answers to that would be a great help for me. Does anyone know?
Edit:
I'm asking this, because I have an especially corrupted snippet looking like this:
68, 69, 70, 95, 72, 93, 74, 80, 91, 77, 78, 89, 87, 98, 84, 85, 96, 99, 100 etc.
so do I interprete this as lacking e.g. samples 96-71 (going once past 255 to start back at 0), or is there a chance it misses more than one 0-255 chunk there? Is there any way to tell?
Comments
Hi NR,
Yes the sample index column normally cycles through 0 to 255 and back. So missing sample numbers imply missing packets.
Samples occur at 250 Hz, every 4 milliseconds. If you see the sample in the csv, it was recorded; missing samples are not.
The 'time stamp' values in the csv are assigned as the samples are received at the GUI / Brainflow, so reflect latencies in radio packets, usb buffering, OS delays, etc.
It should be possible, using a usb extension cable to get the dongle closer to the Cyton. This can minimize packet loss.
Regards, William
Hi, thanks for your quick reply! That already helps me with the occasional misses (which is relevant, because I'm aligning that data to other data).
Is there also a way to detect if more than 255 samples dropped, like I wrote in the edit? I almost suspect not, given what I now know, since, as an example: 67-66 could either mean 255 samples dropped, or 510 or 765, or ... as at that point, connection was so spotty that his cannot be ruled out -- and the file can't separate that?
As for the suggestion, like I said; it's fine now, it was a source of interference I removed and it has been very fine since. Just I'd be loath to dump the already recorded data, unless absolutely necessary because it cannot be saved (i.e. given proper timebases -- naturally it will have gaps).
Normally it would be rare for more than 255 to be dropped. That would signify an extremely poor connection. The packet widget can inform you of the dropped packets, during a session. There are no other packet counters than the one byte value 0 to 255.
https://docs.openbci.com/Cyton/CytonDataFormat/#binary-format
And the packet widget information isn't saved ... Maybe something for a session log file in a future version of the GUI? Sounds useful, anyway.
Right. I think this clears up all my questions and now I can work on the data. Thanks again for the quick help