problem with accumulating delay when using LSL Widget
Hi,
In my research group, we did some investigation of the delay and jitter existing due to problems with the sampling rate. For the testing purposes, we used OP803SL phototransistor connected to the first channel of Cyton+Daisy (16ch in total), that produce square impulses hardware - hw markers). For stimulus display (a white circle on the screen) we used OpenVIbe Designer with the following configuration:
1) OpenVIbe connected to the OpenBCI_GUI via LSL Widget (LSL Streaming option in OpenVIbe acquisition server) with and without drift correction of 2ms / 8blocks /sec
2) OpenVIbe connected to the OpenBCI_Python via lsl_streaming (LSL Streaming option in OpenVIbe acquisition server) with and without drift correction of 2ms / 8blocks /sec
3) OpenVIbe connected directly via OpenVIbe driver from acquisition server with and without drift correction of 2ms / 8blocks /sec
4) OpenVIbe connected to Micromed (Treviso, Italy) via TCP streaming (System Acquisition Plus<--->Acquisition Server Openvibe)
The white circle appeared every 1.5sec (approx. 40min in total, 1600 repetitions). The recordings have been done on a machine with Windows 10 with delay settings set to minimum (according to the instructions). The data have been saved as gdf files with the software markers inserted by OpenVibe (red - marker 0). The difference between 0 (red) and 5 (green) is the effective delay of the system.
All 16 channels were recorded, so that the full capacity of transmission can be tested. The electrodes 2-16 were kept in the water to avoid railing .(red 0- software marker (sw), green - 5 marker inserted using (hw- OP803SL), 7 (magenta)-end of stimuli presentation sw)
1) using OpenBCI_GUI via LSL Widget we obtained this:
No drift correction
With drift correction
What we can see from these two figures is is that the delay at the 1st 1 trial is about 100ms(t=1.5s) and it grows up to 2500ms (2.5sec) at 1600th appearance of the circle at approx. t=40min. We can see that the delay grows linearly telling us that there are probably additional samples added either by OpenVIbe Acquisition Server or by OpenBCI_GUI. Furthermore, the drift correction enabled on OpenVIbe acquisition server didn't show any effect. (see the difference between these two photos).
2) Using OpenBCI_python script for LSL streaming we obtained the same results.
3) Using OpenVIbe drivers that directly interface with the Board http://openvibe.inria.fr/drivers-openbci/
No drift correction (keep in mind that here the Y-axis are different)
mean (stdev) delay: 45 (7,5) msec
Drift correction
The results here are much better and acceptable. The delay of 50ms with a small standard deviation and no jitter seems to fit most of the experiments. However, what I notice is this pattern of delay that is specific for blocks and I don't understand what is the cause?
Finally,4) we compared with the CE medical device 32 electrodes Micromed system that interface with the OpenVIbe via TCP streaming between OpenVibe Acquisition Server and System Evolution (Acquisition software by Micromed). We did this just to have a point of reference about a possible delay. We have obtained this:
With drift correction (very similar results without):
Mean: 110.89 ms
St.dev: 19.5 ms
It is not perfect, but relatively constant. The bursts seem to be characteristics of the TCP congestion control since the test in this case really involved two different PC-s directly connected with 100Mbps ethernet.
In conclusion, we have to see what is really going with LSL Widget/Acquisition Server, since this behavior is critical not only for ERP studies but also for many other applications. The delay of 2.5sec is unacceptable. On the other hand, i would recommend OpenVIBE driver, but it is outdated, no impedance measurement available, no channel configuration possibility, so it has to be combined with OpenBCI_GUI, that also can create some problems (such as "port in use", because OpenBCI-hub was not closed properly. etc.).
Comments