How steady is Cyton's sampling rate? [resolved]
I analyzed how erratic the eeg signal is, as was recorded by openBCI. Discovered that the sample rate is not constant. It speeds up, slows down, bursts, pauses.
Sample 1: mean 260hz, variance 20, min 111hz, max 340hz
Sample 2: mean 186hz, variance 41, min 74hz, max 399hz.
Sample 3: mean 250.5hz, variance 12.6, min 180hz, max 307hz
Such huge differences in sample rate! Sample 2, on average, was only detecting up to 93hz brainwaves! This is for 8-channels, via bluetooth and recommended bluetooth dongle.
How can I get a more consistent reading? (Other than WiFi shield, which for me is so far even buggier).
Comments
How are you computing your sample rates? By the "time stamp" values in the CSV file produced by the GUI? These numbers are quite variable and reflect OS scheduling latencies for the GUI / Hub app when the radio packets are received. You cannot use these number as the times at which the EEG sample was taken. They are the time stamp when the radio packet was received by the GUI app.
Actually sample rate is quite stabile. Although the Cyton does not have a crystal clock. So rate may be say 250.05 or 249.92 etc. But stays stabile at that value. With very small variance.
What is your application?
Regards, William
https://www.google.com/search?as_q=time+stamp&as_sitesearch=openbci.com
Ah... let's assume the Cyton is capturing and transmitting steadily, and that the irregularity is introduced elsewhere. How can we cut out the irregularity? Is there a way to access the received packets as soon as they come in, and bypass the GUI entirely?
What is your end application? Most signal processing of EEG can allow some variation of sample reception time. If you are doing band based neurofeedback, then your band filters handle this and absorb any reception variation. Band filter response times depend on filter order and can be in the range of a few hundred milliseconds. Quite adequate for neurofeedback reward / inhibit feedback.
Various apps such as BioEra and BrainBay can receive the Cyton data stream directly without the GUI. Also OpenViBE has a Cyton serial stream driver.
One reason the GUI / Hub time stamps are so variable, is that the Hub + GUI is fairly heavyweight combination of multiple processes. A decision made for portability over three OSes.
I recommend BioEra if you are going to be doing neurofeedback. It will also be supported by Pete Van Deusen's Brain-Trainer protocols shortly. BioEra is the base layer of many highly regarded commercial NFB apps such as LENS, Cygnet, etc.
Could we more simply streamline things by ditching the OpenBCI GUI and runn Hub by itself? So far we've been using the bundled version for Mac.
Hub is too heavyweight. BioEra would work fine. What do you do with the FFT? Most band based neurofeedback uses just plain DSP filters of various bandpasses. You could also use BrainBay, tutorial here,
https://sites.google.com/site/biofeedbackpages/brainbay-openbci
BioEra has a steep learning curve. Pete Van Deusen's Brain-Trainer protocol suite will be available soon for BioEra. Currently it only runs on Bioexplorer, which lacks OpenBCI support; and is unlikely to get it.
Another alternative are various interface libraries for Cyton. These exist in Python, C variants, Java, Matlab, etc. Thus your app could use the library to access the data stream directly.
Another alternative to BioEra, BrainBay is OpenViBE, which has a direct serial port interface. It's more geared to BCI than biofeedback.
I checked out OpenViBE but it doesn't currently work on Mac. Using the Cyton libraries might be our best bet for getting the data more directly.
Most Windows EEG, NFB, BCI apps can run under VirtualBox on the Mac. BioEra is a Windows app, as is BrainBay. Most clinical NFB apps are Windows.
Hey @wjcroft — not seeing stead sample rates even using python SDK on OSX.
The sample rate of the clock on the Cyton board is CONSTANT. But there is no crystal oscillator on the board, so it can be slightly different from exactly 250.000 Hz. For example it might be 250.050 or 249.933, etc. That rate is constant, it does not 'jitter', change back and forth. The technical term for this difference from exact 250.000 is called 'drift', a very slight constant difference from 250.000.
The "sample rate" you are computing, my perception, is confused by the OS scheduling delays for processes, including the Python interpreter. So it looks different or bursty from the 250 Hz.
Didn't we go over all this previously on this thread? Where I mentioned the GUI has the same type of burst scheduling effects. Yet the EEG samples are all at a constant 250.xxx rate.
What is your application? Have you been able to use the various Brainflow signal process libraries? In those libraries you just specify your sample rate. In this case as 250 Hz.
https://brainflow.readthedocs.io/en/stable/
Regards, William
Remember also, that the Cyton sample stream is coming through a usb serial COM or /dev port. This in itself introduces various buffering delays.
Indeed @wjcroft — in the last few minutes we discovered that...
python user.py -p /dev/tty.usbserial-DM01HZ0H --add streamer_oscyielded low and variable sample rates from 146-200
python user.py -p /dev/tty.usbserial-DM01HZ0H --add streamer_tcpyielded fairly consistent range between 249/250
python user.py -p /dev/tty.usbserial-DM01HZ0H --add streamer_lslalso yielded fairly consistent range between 249/250
python user.py -p /dev/tty.usbserial-DM01HZ0H --add udp_serverwas pretty broken and nondeterministic
Who's in charge of the OSC streamer? It seems to be underperforming and / or broken.
There are TWO Python repos, the newer one is pyOpenBCI, which shows an LSL example,
https://github.com/OpenBCI/pyOpenBCI
The older repo is now deprecated and no longer getting active support,
https://github.com/OpenBCI/OpenBCI_Python
I recommend going with the LSL over the OSC, as LSL has wide acceptance in the neuroscience community and interfaces with many analysis apps.
https://github.com/sccn/labstreaminglayer/wiki
Argh... thanks @wjcroft — but jeez, again I have been misled by following the OpenBCI website! Can someone please update https://openbci.com/index.php/downloads to point to the new pyOpenBCI? Right now it directs readers like myself to the deprecated one, in which we have mis-invested 4 hours!
@retiutut
Mentioning Richard @retiutut. Our OpenBCI main site Download page should link to the new Python vs the old.
And for Strikeroot, Our master Github page, is always the most current across all systems,
https://github.com/openbci
And the docs page DOES direct to the newer repo:
https://docs.openbci.com/docs/06Software/01-OpenBCISoftware/Python
I have made an internal ticket for this, thanks for tagging me.
Hey @retiutut — Thanks for all the updates to OpenBCI_GUI. If you read this thread, you'll see we found the end-user sample rate very inconsistent. Did you do anything specifically (with Hub or the Py libraries) to improve the ultimate sample-rate that OpenBCI_GUI achieves?
Josh, can you clarify, "...found the end-user sample rate very inconsistent..." Didn't we cover this on previous comments? The sample rate at the Cyton IS very consistent. It is the buffering in the serial port, OS, etc., that varies slightly. The sample rate that counts for signal processing, neurofeedback, etc., is the hardware sample rate at the Cyton.
William
I understand the sample rate on the Cyton is fixed and reliable. Sorry if I'm not phrasing this well. I mean the end-user sample rate, or the rate at which the OpenBCI_GUI receives the data or that one can access the raw data on the PC / client side. If you calculate the rate at which data is acquired at the very end of the whole data flow, then you get an effective end-user sample rate which is much lower than the sample-rate of the Cyton that you started with. If you have another word other than "sample rate" to refer to the rate at which the samples are available to the end-user, I am happy to use it.
What I am bringing awareness to is how much lag and stuttering is introduced by OpenBCI_Hub and the Py libraries as it tries to make that serial data available. Because of them, the effective sample rate available to apps is quite volatile. If you scroll up you'll see the effective sample rate comparison between OSC, TCP, and LSL, and so on with one of the Py libraries. OSC was especially bad and I don't think it improved when we tried the other Py library.
Our analysis was that data was being made available to OpenBCI_GUI at irregular rates far below the steady 249/250 sample rate provided by Cyton at the beginning of the data stream. AND that this bottleneck was NOT being introduced by GUI but by the underlying streamer libraries being used. All this was to ask whether @retiutut was aware of the bottlenecks on the software side and had made improvements, either in Hub or GUI.
We are making improvements constantly and we have been trying to remove the Hub for half a year.
Hello, some observations I made while working on this timing issue:
My Cython 16-channel sampling rate is not exactly 125.00 Hz; for me it is ~ 125.20 Hz. It does remains constant. I estimate the sampling rate by reading out the timestamps from the LSL protocol and do some calculations on the assumed times using exactly with 125 Hz and those timestamps measured with LSL. The LSL timestamps are a bit noisy, I think due to CPU being busy with other tasks and such. Especially important is that this delta-t can be accurately used to figure out from the LSL timestamps when data skips have occurred in your data; i.e. when bluetooth missed 1 or 2 samples.
The fig shows shows with black line a detected 'missed sample' from the timings that LSL produces.
You actually need to carefully calibrate and measure the accumulated time delay throughout the length of measurement, especially if you have timestamps from another device and need to put markers into the (stored) EEG with f.e. MNE Python. It's a bit clunky but still doable. If you don't then on a measurement lasting 10 minutes you can get an inaccuracy in marker timing of about 200-300 msec; this is too much for EEG!
Once you take care of the sampling rate, and the jumps, I think you should still be able to get back to a pretty good accuracy of the markers that falls within ~ 8 msec (i.e. the delta-t between 2 samples measuring @ 125 Hz). I like to have the 16 channels for trying to do ICA-like rejections; but the srate does have its challenges. I'd love to see support for 250 Hz @ 16 channels over bluetooth.
I use the openbci_lsl.py script, since it's much faster than using the Hub / GUI. The GUI is fine for checking the EEG connections with the head, and seeing if the USB Bluetooth is connected properly. But for measuring, it's rather slow and hogs the CPU. Also there seems to be an accumulated delay between actions in the real world and inspection in the on-line EEG traces. I think it's fine if you have a dedicated CPU used only for the GUI. But if you wish to do something more/else or stimulation, then try to use another computer and stream the data.
I guess the clinical-grade amplifiers such as EGI, Brain Products and NeurOne have the perfect sampling rates with no sample dropouts, but then again - those cost you the big bucks!
Hello, I'm currently using the Cyton Board for EMG purposes, but it seems we have an issue with the sampling rate.
While the expected rate is 250 Hz, when we experimentally assessed this value we got an effective value of 250.3 Hz. Our first question would be whether this is something reasonable to get and if so, do we expect this value to be stable across time or could it fluctuate across sessions?
Thanks for your attention and support!!
@monsomor, hi.
I merged your new thread into this existing thread on the same topic. Please see the comments on the above thread, in particular this comment,
https://openbci.com/forum/index.php?p=/discussion/comment/12235/#Comment_12235
This thread is a bit old, but the info about sample rate and buffering is still accurate. OpenBCI devices now use the Brainflow library to access the hardware, see, https://brainflow.readthedocs.io/en/stable/
Regards, William