The time synchronization methodology of LSL is described here. On this page is a description of the experimental validation of the synchronization capabilities of LSL. Below, it will be demonstrated that LSL introduces timing errors of less than 1 millisecond. This result holds both on a single computer and when a local network is introduced.
Throughout, a distinction is made between software events and hardware events. Software events are those created using an LSL stream with irregular timing. Hardware events are voltages switching on lines which are acquired with a scientific grade data acquisition device and saved to an LSL stream with a set acquisition rate. Software events are limited by the ability of the operating system to generate events at a specific time. Hardware events are limited by the sampling rate of the signal generation and acquisition devices.
These tests were run on LSL version 1.0.30 under Windows 7, 64 bit.
In the first protocol, synchronized software and hardware events were output by computer A, acquired by computer A, and saved by computer A using the LSL Lab Recorder. The hardware events were output by a National Instruments PCI-6230 (or NI PCIe-6321) data acquisition card and controlled by custom software (written in C using the National Instruments provided NI-DAQ SDK). The following procedure was used:
* Set an output channel to 1 volt, using NI PCI-6230, running at 10 kHz.
* Once the output channel is above 0.5 volt (measured using feedback into an input channel on the NI PCI-6230), output LSL software event.
* Once 500 microseconds have elapsed from setting the line to 1 volt, set the line to 0 volts.
The output channel is also input into a Biosemi analog input box, running at 2048 Hz.
The data was loaded in MoBILAB and analyzed. Below is the data detail for one event as saved by LSL. The vertical red line is the software event. The blue spike is the hardware event. The horizontal red line is the hardware event measurement threshold.
Below is the latency (hardware event time - software event time) over time. There is jitter from -0.08 ms to 0.11 ms with occasional outliers. The dominant cause of jitter is the (relatively low) 2048 Hz sampling rate of the Biosemi. The outliers are caused because occasionally a software event is delayed by the OS a small amount after the hardware event is begun. There is also a small drift. Variable drift is likely caused by temperature variations changing the clock frequencies. Constant drift (when it occurs) is likely caused by statistical error in the fit of the Biosemi timestamps.
Below is histogram of the latency, with statistics.
We then have that the uncorrectable synchronization between a continuous LSL stream and a irregular LSL stream is well less than 1 ms. In general, note that streams will have a constant latency offset. This is corrected for in the biosemi stream header, with the following block (see XDF description for more details):
<desc>
<synchronization>
<offset_mean>0.00772</offset_mean>
</synchronization>
</desc>
This indicates that if nothing is done, the hardware events would be 7.72 ms later than the software events. Generally, this block must be added (by the application developer) for each stream of interest.
In this protocol, the hardware and software events were output by computer A and acquired by computer B. For the hardware pathway, the events were output by the NI-6230 in computer A and acquired by the biosemi attached to computer B. The software events were generated by an LSL stream on computer A and passed over the network to computer B.
The hardware events are still electrically connected to the data saver. However, the software events now have network connection (as well as two different computer clocks) to contend with. Since this is the only significant difference between the two protocols we anticipate that any difference in timing is due introduction of error in measuring the timing of the software events.
Below are the same three plots, but in the new protocol. Here, the range of latency is -0.36 to -0.21 ms, and the mean is 7.9 ms. The difference in latency between the networked and the non-networked protocol is -0.29 ms, corresponding to a slightly later reported event code time.
It is recommended that any modalities that are needed for your setup are tested using protocols similar to the ones described here. These tests verify that LSL is reliable on order of 1 ms, but if an individual device is not reliable, your mileage may vary. Typically, devices which output data at a constant frequency will have low jitter. The timing offset, though, will be difficult to predict and should be measured and corrected for in the stream header. Software events are more difficult. The test described above used a research grade data acquisition card to trigger the software events. In ordinary circumstances, software events will be difficult to control. Even though LSL will mark their time correctly, it may be difficult to get them to be generated at the exact moment desired when using consumer grade OSes and devices. Look here for the analysis of some other modalities in more detail.
The data for this report was taken on 2013/05/02