Order of the raw EEG data

[vattha]

Dear James

Thanks for the wonderful app. My muse is the 2016 one. I set the app to transfer at the constant rate (~256Hz), and use the osc streaming. I wonder if the raw data from the muse headband arrives at an osc server chronologically, i.e. the raw data corresponding to the brain activity sampled early in time will arrives at the osc server before the raw data sampled later. If this is not the case, what if I choose to directly record the raw data from the app. If both cannot guarantee the order of the data, could you please suggest a way out? Thanks in advance .

Best,
vattha

[James]

Yes. All the data is sent in order. So you *should* receive it in order. I say should, as UDP is a "fire and forget" protocol and it is possible, on a badly configured network that the packets arrive out of order. However, in this day and age, it's very unlikely! You can confirm the correct order on receipt by reading the timestamps.

In order to read the timestamp, you will need to read it from the OSC Bundle, not the OSC Packet.

OSC Bundle: {TimeStamp} + {OSC Packet}

OSC Packet: {EEG Data}

[vattha]

I am new to osc. I work on python and use python-osc. It would be so kind of you if you could please provide some clues on reading the timestamp of OSC bundle. What I have found is https://mind-monitor.com/FAQ.php#oscspec, in which I could not see the timestamp.

best,
vattha

[James]

I don't think that you can read timestamps (bundle timetag) in python-osc, sorry.

[vattha]

Is the timestamp generated by the muse or the app?

[James]

In the app when the data is received.

[stellarpower]

So, would the recommended way to get the timestamp for each packet be to take the timestamp on the bundle, then assume the sampling rate is known and increment the timestamp from the bundle for each message accordingly?

Also, is the sample rate 256 Hz for the Muse 2? I have the product code MU-03 on the device in front of me. I assumed so from the FAQ, but wasn't sure I could tell without calculating it manually from how many packets I receive as both options are listed.

On that topic, could some of these details be added to the OSC spec please? I think that section could possibly be expanded to cover the format on the wire in more detail, and some other questions I have seen here on the forum.

[stellarpower]

Also, I'm on an old version of the app (2.1.1) - did the bundling format change at all at some point? I only seem to be getting single messages in my bundles, and from what I see on Wireshark this tallies up with what my OSC library implementation is telling me - the UDP packets are about 60 bytes long. Thanks.

[James]

I wouldn't bother trying to get the timestamp. If it was working perfectly, all it would tell you is the time of flight for the packet, since you already have a real time clock on the receiving computer and these days they're all in sync. I would just use the local time if you want to log it for some reason.
The original first gen Muse was 220Hz, all others are 256Hz.
The OSC spec has never changed. You are correct at each bundle only has one message. As the timetag is per bundle, and the time changes between each message, this necessitates a new bundle for each message.
I've updated the wording on the OSC FAQ regarding 220Hz vs 256Hz, let me know if there's anything else you think I should add.

[stellarpower]

The main reason was for trying to debug this high-frequency noise I'm seeing; I was adapting the OSC forwarding code I have to spit out some CSV and then aim was to compare it against what the app saves and graph both offline, and I wanted to get it as accurate and precise as possible.

I'm also not sure if some of the upstream programs I have in the pipeline will link the timestamp to their internal clock when received or use the timestamp the packet is received - if it hypothetically uses the timestamp that the data comes into MindMonitor then hopefully that should result in a more accurate stream for the training protocols that can work around any possible latency issues in the network.

FYI I'm getting multiple bundles of the same message type (e.g. EEG or gyro) in a row with the same timestamp, but I'll either use the local clock on the receiving end or calculate manually or something similar.

On the website wording - I think in summary what has been discussed here would be helpful - that you're using bundles over raw messages, and that each bundle only has one message, along with a timestamp.

Thanks!