Bursting behavior of data from Python?
Not sure if this should go in software forum, please move if appropriate.
I use Python to interface with the hardware. I have a V3-32 main board and a Daisy board, collecting 16 channels EEG data. I don't see any markings on the USB dongle to indicate a version, so there must just be one?
Anyhow, here's the problem: the time stamps for the samples being recorded in the callback function (the arg for board.start_streaming) are showing that the samples are bursting at roughly 0.5sec apart. In other words, every 0.5sec or so there are a bunch of data points. It's the same for every channel. In theory, the callback should be getting called every 1/125 seconds and so the time stamp of each sample should be separated by roughly 0.008 sec.
Here is a very rough psudo-code for Python:
import time
def callback(sample):
store_chan_data(sample.channel_data)
store_timestamp(time.clock() - time_master)
main:
time_master = time.clock()
board.start_streaming(call=callback)
Any idea why it's bursting like this? Or is that just how the radio functions?? If that's just how the radio functions, then can I just assume the samples actually are being collected 1/125 sec apart on the actual OpenBCI hardware?
If that's not how it's supposed to work, is it more likely an issue with the serial port, the PySerial module or something wrong with the radio firmware?
Thanks!
Comments
http://openbci.com/forum/index.php?p=/discussion/643/packet-loss-with-openvibe-and-python
http://openbci.com/forum/index.php?p=/discussion/378/openbci-python-unreliable-linux-mac-acquisition
Etc.
The data packets and their sequence numbers should reliably increment by 1 each time. Only very occasionally should you see other increments when a packet is lost. How does the data stream look with the OpenBCI_GUI? I assume you have applied the FTDI OS adjustments to avoid serial stream buffering.
http://openbci.com/forum/index.php?p=/search&Search=LatencyTimer
William
I'm not actually losing the packets. I'm getting all the sample.id numbers (in sequence). The issue I'm facing is that when I use Python's time modules to time all the function calls, then the timing of when the samples are recording isn't every 1/125 sec. It's much more bursty behavior. And that could be a number of reasons.
But if the OpenBCI hardware can reasonable ensure that sample.id = i is spaced apart from sample.id = i+1 by 1/125sec, then I'll just use (a continuous version of) the sample.id times the sampling period as a "timestamp".
It would be great if some resolution was found for the Python issues. Many users have reported this, as the previous links show. It also seems to be OS dependent. Can you try another OS?
Yes the radio is bursting at 4 or 8 ms intervals. One sample packet per transmission.
Have you configured the LatencyTimer as suggested?
re: PPM crystal specs. The mainboard sample clock is NOT independently crystal controlled, and some slight drift is to be expected. Also see,
http://openbci.com/forum/index.php?p=/discussion/313/ads1299-sample-rate-drift-or-jitter
http://openbci.com/forum/index.php?p=/discussion/129/ads1299-sample-rate-threading