Data timestamp

dhruvsakalley · January 2015

I'm trying to write a client for OpenBCI with C#, I succeeded in getting the data into a csv, but I noticed I could not find any reliable way of telling the actual timestamp of the data origin. The 33 byte packet does not have any timestamp on it, the sample id is the same for the whole chunk of data transferred. These data chunks do not come at a regular interval or with regular size. I was able to form them into 33 byte packets and interpret the data they carry but there is no way of telling if they are ordered correct, and when they originated.

The time part is crucial for any cue based BCI. I wonder if this information is already available by some other means? How do other software like the GUI handle it?

I apologize for being superficial and not digging into the code myself, but I would like a direct answer if possible from the community.

Regards,

Dhruv

wjcroft · January 2015

Dhruv, take a look at these posts,

http://openbci.com/forum/index.php?p=/discussion/198/timing-marks-buffering-delays-etc

http://openbci.com/forum/index.php?p=/discussion/200/latency-timer-windows-control-panel-setting

http://openbci.com/forum/index.php?p=/discussion/199/latency-timer-os-x-new-info-plist

---

The ADS1299 is sampling at 250 samples/sec. So you can interpret the packet index as 1/250th of a second ticks. All packets are ordered as they were received. If you are referring to synchronization of your EEG with external timing signals, that's on the first link above.

No EEG amp that I am aware of puts 'absolute' time stamps in the data stream.

William

chipaudette · January 2015

I concur with William's reply.

To reinforce his statement, the packets cannot come out-of-order. This is not like TCP/IP over WiFi, this is a serial link replacement via bluetooth -- bytes come out in exactly the same order as they went it. Corruption of the bytes is always possible, but having them change their order is not.

Also note that all of the EEG channels are sampled simultaneously, so you can assume that all 8 channels occurred at the same moment in time. As a result, there is only one packetID for the whole 33 byte packet.

From packet to packet, you should see that the packetID increments by one (until it wraps around). If you see the packetID correctly incrementing each time you get a packet, then you're getting all of the data.

Chip

dhruvsakalley · January 2015

Thanks for answering my question William. The above links have been a great help.

Also thanks Chip for confirming this observation. I realized that the header information or some other source is causing my bytes to shift. I'm currently correcting that, will update more later.

wjcroft · January 2015

Dhruv, if you want to see the C++ code that Brainbay uses to sync up and parse the incoming packets, look at the module ob_eeg.cpp . It's a state machine that is called on each incoming byte. A similar state machine approach is used in OpenViBE.

https://github.com/ChrisVeigl/BrainBay

William

Data timestamp

Comments