Clarification on first header bytes for bluetooth protocol


#1

To clarify, I wanted to confirm the possible first header bytes one could see.

All header bytes must be either

FF = First byte of sync packet
E0 or E8 = Uncompressed EEG (0 or 8 being the flag nibble)
D0 = Error Flags (unlikely to see)
C0 = Compressed EEG
B0 = Battery
A0 or A8 = Accelerometer (0 or 8 being the flag nibble)
90 = DRL/REF (2nd nibble is unused)
00 = Invalid

This will help me a lot in determining whether I have a header byte or just a data value.

Also, is there a range that the number of bits for CEEG values is likely to be? I can’t tell if I’m parsing numbers correctly, which is making it very difficult to correctly parse my data stream.

And finally, to gather a goodly-sized sample of bluetooth data, how many bytes should I gather at once to have a nice set to work with?

Thank you. I’m working on an arduino-based project, so I have to use the data streaming protocol.


#2

Keep in mind that the published bluetooth protocol only applies to the Muse 2014 headband. The Muse 2016 headband uses Bluetooth 4.0 and a different protocol. You can tell the difference between the 2 headbands by looking at the number of micro USB ports. Muse 2014 has 2 ports, Muse 2016 has 1.

It may be easier to use a mobile device (iOS or Android) to connect to the headband and then forward the data to the Arduino. There are applications for iOS and Android that can send the headband data as an OSC (Open Sound Control) formatted stream and I think that there are OSC libraries for the Arduino which would simplify the parsing.

What you have listed for the Muse 2014 header bytes looks accurate though.

Hope that helps.


#3

Is there anywhere that has the 2016 protocol listed? There is literally zero real development documentation on the 2016 version.


#4

Thank you! I am definitely working with the 2014 headband.

Using a mobile device would definitely be easier, wehterh I was sendign the data via OSC or whatever, but the reason I haven’t done that so far is that these are wearable tech fashion pieces that usually travel without me, and it would be challenging for people to have to install and pair the headsets with new phone each time the piece is shown (and if I wanted to show the piece on a mannequin, they would have to leave that phone there). I originally thought it would be too ridiculous to get android phone specifically for that, but it has actually been really, really difficult to parse the bluetooth data. Since I have gone extremely far down the rabbit hole, I would really rather not start this project over again from scratch.