Lab streaming layer (LSL)

Hi Jaewon,

We are using LSL to save skin conductance data recorded from Bioplux sensors (https://www.pluxbiosignals.com/collections/biosignals-for-physiology/products/electrodermal-activity-eda-sensor-1) to ML data file.

The data is getting saved in the AnalogData.LSL field, but for each trial the no. of LSL samples recorded is different from, say, the no. of Eye position samples collected in that trial.

Does that mean that the LSL data is not temporally synchronized to the start of the trial as eye data is?
Is there a way to synchronize the two data streams post data collection?

Thanks.

It is the Bioplux acquisition system that collects samples from the sensor and sends to LSL. NIMH ML simply imports data stored in LSL when a trial ends. Considering the clock difference and the network speed, there is no guarantee that you get the same number of samples from both streams.

NIMH ML clears LSL when starting each trial (or when starting the 1st trial if using ITI recording), so the recording start time should be close each other. The timestamps of LSL samples are stored in the first column of the data, so you can resample LSL data to align it with eye data, if necessary.
https://monkeylogic.nimh.nih.gov/docs_MainMenu.html#LSL

Thank you, Jaewon.

So, you mean to say that both Eye data and LSL data saved in the AnalogData field are by default synchronized to start with Trial start time as given by CodeTimes value corresponding to Behavioral code = 9?

Is this regardless of the actual timestamp value shown in the 1st column of LSL field?

Because we seem to be getting some negative timestamps in the LSL 1st column, before positive values start off (pls see attached image)

Thanks.

First of all, the code 9 is not the trial start time.
https://monkeylogic.nimh.nih.gov/board/read.php?2,1551,1551#msg-1551

Your 1st column does not look like timestamps. The unit of the timestamp is supposed to be milliseconds. What is the sample rate of the LSL data? Are you using the latest NIMH ML?

Thanks, Jaewon.

The sampling frequency for GSR is set at 1000 Hz. And we are using the NIMH ML 2.2.29 version.

If ML is just saving whatever LSL has got from the GSR device, then the odd looking timestamp values could be an issue related to Opensignals (the application that communicates with the sensor) and LSL. Unfortunately, there is little to play with, in terms of setting options on the app, to change how it sends data to LSL and check if that makes any difference.

Also, would you expect the analog GSR data to be of the same length as eye data, given that the sampling frequency of Eyelink is also 1000Hz.

Thanks.

Your figure shows 3 columns. Because of the timestamps, the saved LSL data is supposed to have one more column than what you choose in the LSL menu of NIMH ML. Is that the case in your data file? Did you choose 2 LSL streams to save?

No. What I said above is still applied and it is possible to get a different number of samples. However, the difference should be 1 or 2 samples at most.

If you are doing ITI recording, negative timestamps are also possible since new samples may be added while moving the retrieved samples to NIMH ML during ITI. The number of those samples should not be many, though.

-----

From the data you provided, I think the opensignal software collects 150 samples and sends them together as a block to LSL, instead of sending one single sample 150 times. This causes the synchronization problem. If a trial ends between the update cycles of the 150-sample block, the length of the LSL data will be shorter than the eye data because some portion of the LSL data is not updated yet. It can be longer in the next trial though, since the portion not received in this trial will be added to the next trial (if ITI recording is turned on).

In this case, the first column of the data (i.e., LSL timestamps) is useless; those numbers do not show the sample intervals. It seems that the Bioplux people expected this, since they added their own timestamps to the data. I think the second column is the timestamps they added and the third column is the sensor values.

Although GSR data is being sampled at 1 kHz, it is uploaded to LSL only at ~6.7 Hz (= 1000/150), so the sync accuracy between the LSL and eye data will be limited.