I am getting LSL streams from openbci gui to pylsl and trying to get an absolute timestamp with the correct epoch. But since the timestamp sent by Gui is relative, matching it with any other external timeseries becomes hard. Anyway to avoid this simply by adding to the timestamp the current time from the gui perhaps?
absolute timestamp in LSL stream
macOS mojave 10.14.5
4.12 May 2019
tested on standalone and Processing
Cyton+Daisy
No
There is not enough information here. I take it you are streaming TimeSeries over LSL.
Also, you claim that GUI is sending invalid timestamps, and I don't see any timestamps being sent explicitly by the GUI.
If the GUI is sending a timestamp, it's from the LSLLink dependency. https://github.com/jfrey-xx/LSLLink
@compmonks It might be possible to use a different version of push_chunk function that includes the timestamp. Check out the code below for unfiltered EEG data over LSL:
} else if (this.protocol.equals("LSL")){
float[] avgPowerLSL = new float[numChan*numBandPower];
for (int i=0; i<numChan;i++){
for (int j=0;j<numBandPower;j++){
dataToSend[j+numChan*i] = dataProcessing.avgPowerInBins[i][j];
}
}
outlet_data.push_chunk(dataToSend);
As you can see, the GUI seems to send data only (currently).
@compmonks Can you please provide the steps to reproduce your issue?
@retiutut ,thanks for the comment. I looked a these lines you pointed out in W_networking
and for both unfiltered and filtered data I simply modified the push_chunk:
import java.lang.System;
...
outlet_data.push_chunk(dataToSend,System.currentTimeMillis());
What LSL does, when a timestamp is not provided, is adding one based on the local-clock. I guess it is taking as a zero epoch the time when processing starts running the code so the timestamps will always be relative to the session and not the current date. Adding a specific timestamp as a second parameter correct this issue but then I am not sure how reliable currentTimeMillis() is here.
In general, it could be useful to add an option in the GUI for this so that LSL networking with third part softwares would be be easier.
Cheers ;).
@compmonks Thanks for trying a solution on your end! I can try out this method with GUI->OpenVibe. Adding a dropdown might be confusing. Maybe we can add a timestamp for all LSL TimeSeries data ,filtered and unfiltered.
For what you are doing, would it make sense to add a timestamp for other data types?
For the comfort of easily combining timeseries from possibly multiple sources I would say yes. In general, that would a useful feature. The LSL inlet contains info on its creation date as well, so relative time to the session can always be found easily.
@compmonks re: timestamps vs. external trigger. Even if you had a timestamp feature, isn't using an external trigger (through an Aux data input), the better way to sync multiple data streams? I realize stream syncing was a goal of LSL, but P300 work may still require maximum accuracy.
@wjcroft no arguing from my side on that point :) .
I am only saying that since the feature is already ready in the LSL code, why not put it? It could be useful for unforeseen cases.
Optionally the capture time of the most recent sample, in agreement with local_clock(); if omitted, the current time is used.
The time stamps of other samples are automatically derived based on the sampling rate of the stream.
/**
* Push a chunk of multiplexed samples into the outlet. Single timestamp provided.
* @param data A rectangular array of values for multiple samples.
* @param timestamp Optionally the capture time of the most recent sample, in agreement with local_clock(); if omitted, the current time is used.
* The time stamps of other samples are automatically derived based on the sampling rate of the stream.
* @param pushthrough Optionally whether to push the chunk through to the receivers instead of buffering it with subsequent samples.
* Note that the chunk_size, if specified at outlet construction, takes precedence over the pushthrough flag.
*/
@compmonks Going ahead with the outlet_data.push_chunk(dataToSend,System.currentTimeMillis()); fix applied to all data types for LSL
Most helpful comment
For the comfort of easily combining timeseries from possibly multiple sources I would say yes. In general, that would a useful feature. The LSL inlet contains info on its creation date as well, so relative time to the session can always be found easily.