Cyton data format - why choose 0xA0 as header byte? Can it occur in the eeg data bytes?

Comments

• wjcroft Mount Shasta, CA

  January 2019

  Mark, hi.

  
  

  Yes it can appear in the data. All the parsing routines have a "state machine" where they consume the incoming packets to get proper alignment. The sync/start bytes are ignored when in the data portion. The routines also check the packet counter byte, as further proof of this, which increments on each packet.
  

  
  

  Regards,

  
  

  William

  
  
• markosullivan

  January 2019

  Hi William,

  
  

  Thanks for your reply.

  I'm trying to send the Cyton board data to an Android phone using a HC-06 Bluetooth module.

  But in Android, I can't guarantee that the full packet is going to arrive together.
  The packets are broken up into different arrangements of bytes.
  They are always in the correct order, but the first byte isn't always the sync byte. (i.e. the first byte I might receive might be half way through the packet and it will carry on from there)
  
  

  So I'm scanning through the data byte by byte essentially until I find the sync byte, but if the sync byte isn't exclusive to the rest of the data, then that's not a reliable way for me to find the start of the packet.

  
  I suppose, I'll just have to scan for the sync byte, then start a buffer, and 32 bytes later, check to see if that byte is the footer. If not, then I started on a sync byte that just happened to occur in the EEG or Aux data.

  
  

  Unless you can think of any other ideas?

  
  

  Thanks

  
  
• wjcroft Mount Shasta, CA

  January 2019

  Here is some sample C code from BrainBay, the OpenBCI parser starts at line 727,

  
  

  https://github.com/ChrisVeigl/BrainBay/blob/master/src/ob_eeg.cpp
  

  
  

  This is what is called a state machine. The routine is called for each byte in the stream, and maintains a state variable.

  
  

  Ignore the comment "when data contains lots of A0's, sync could not reestablish." That is not true, the glitch was due to very early V1 firmware problems. This code works fine for 8 channel data, but was created before the final 16 channel hardware was available. 16 channel parsing is not as simple as this code, as packets are sent in an alternating 8 channel packet format. Nonetheless, this code does work correctly for the 8 channel format (without the different end code bytes).
• Billh

  January 2019 edited January 2019

  With a packet size of 33 the chance of a received 0xA0 being random data is 33/256, and if you use that 0xA0 to start a bad packet you will correct within 66 bytes, because the next (pseudo)interval will not start with 0xA0 255/256 of the time. So no worries as long as you have a good connection.