Cyton packet format question, extra byte ? [resolved]

mjmcmahonmjmcmahon Dublin Ireland
edited July 2021 in Cyton

Hi All

I wonder if somebody can help clarify a question around the data format for OpenBCI V3.1.2. - I have been working on an app which consumes raw data from the OpenBCI Cyton and I am expected the data to be in following format as per the documentation:

  • Byte 1: Header
  • Byte 2: Sample Number
  • Bytes 3-5: Data value for EEG channel 1
  • Bytes 6-8: Data value for EEG channel 2
  • Bytes 9-11: Data value for EEG channel 3
  • Bytes 12-14: Data value for EEG channel 4
  • Bytes 15-17: Data value for EEG channel 5
  • Bytes 18-20: Data value for EEG channel 6
  • Bytes 21-23: Data value for EEG channel 6
  • Bytes 24-26: Data value for EEG channel 8
  • Bytes 27-28: Data value for accelerometer channel X
  • Bytes 29-30: Data value for accelerometer channel Y
  • Bytes 31-32: Data value for accelerometer channel Z
  • Byte 33: Footer

However when I examine the data stream this is what I am getting

So the data format appears to actually be as follows

  • Byte 1: A0 (Header)
  • Byte 2: 41 (Packet Counter?)
  • Byte 3: 02 (Sample Number)
  • Bytes 4-6: 8A 2C AA (Data value for EEG channel 1)
  • Bytes 7-9: 8A 3A 39 (Data value for EEG channel 2)
  • Bytes 10-12: 85 AF D3 (Data value for EEG channel 3)
  • Bytes 13-15: 88 07 CF (Data value for EEG channel 4)
  • Bytes 16-18: 86 92 CB (Data value for EEG channel 5)
  • Bytes 19-21: 86 95 5C (Data value for EEG channel 6)
  • Bytes 22-24: 87 BA 89 (Data value for EEG channel 7)
  • Bytes 25-27: 87 92 1A (Data value for EEG channel 8)
  • Bytes 28-29: 00 00 (Data value for accelerometer channel X)
  • Bytes 30-31: 00 00 (Data value for accelerometer channel Y)
  • Bytes 32: 00 (Data value for accelerometer channel Z)
  • Bytes 33: C0 (Footer)

I am getting what looks like a packet counter at Byte 2 which right shifts all the values and I only see five values for accelerometer data.

I would greatly appreciate if anyone can shed some light - what am I missing?

Thanks

Michael

Comments

  • retiututretiutut Louisiana, USA

    Maybe it would be easier to use BrainFlow instead?

    https://brainflow.org

  • wjcroftwjcroft Mount Shasta, CA

    Michael, yes, Richard @retiutut is correct, you should be using Brainflow to read the Cyton serial stream instead of trying to parse it yourself. The documentation on the packet format is correct. I believe the 'extra byte' stuff you are seeing is an artifact of the way the Cyton onboard firmware debug / status output, formats the hex output. When you are viewing with a terminal emulator. Normally this 'extra byte' is part of the protocol between the RFduino's and is removed before it reaches the serial input buffer on the laptop.

    Regards, William

  • mjmcmahonmjmcmahon Dublin Ireland
    edited July 2021

    Hi William and Richard - thank you both for getting back to me on this. Unfortunately, I am also seeing the same issue when I run the data through OpenBCI GUI 5.0.5. The GUI removes the header and footer however the 'Sample Index' is showing as 65 (i.e. Hex 41) and then shifts everything right - so it looks like the 'Sample Number' is actually getting calculated as part of EEG Channel 1 and this issue then cascades across all channels.

    I need to manipulate the raw data for my research however I can work around this issue as I do not need the accelerometer information but it would be good to understand what is going on for anyone else encountering a similar issue. I wondering if there is a mismatch between the Board Software V3.1.2 and the Radio Firmware Version on the Dongle?

    Regards
    Michael

  • wjcroftwjcroft Mount Shasta, CA

    When did you purchase this Cyton? Has it ever worked correctly? Was there in a the past an attempt to upgrade firmware? Is it possible the firmware upgrade only updated the PIC32 main processor, but neglected to do the entire upgrade process which starts with the RFduino radio chips on dongle and mainboard?

    https://github.com/OpenBCI/OpenBCI_Cyton_Library/blob/master/UPGRADE_GUIDE.md
    https://docs.openbci.com/docs/02Cyton/CytonRadios
    https://docs.openbci.com/docs/02Cyton/CytonProgram

    William

  • mjmcmahonmjmcmahon Dublin Ireland

    Hi William

    Thanks for your continued assistance. Answers to your questions below:

    Q: When did you purchase this Cyton?
    A: I purchased the Cyton Board in July 2016.
    Q: Has it ever worked correctly?
    A: I am not sure if it ever worked correctly as I cannot find any old data files however this issue has certainly existed since early last year.
    Q: Was there in a the past an attempt to upgrade firmware?
    A: Yes I have updated the firmware from 2.x to 3.x
    Q: Is it possible the firmware upgrade only updated the PIC32 main processor, but neglected to do the entire upgrade process which starts with the RFduino radio chips on dongle and mainboard?
    A: I have only ever upgraded the Cyton firmware and I have never updated the radio firmware

    Do you know if there is a command to check the Radio Firmware Version?

    Thanks

    Michael

  • wjcroftwjcroft Mount Shasta, CA

    Q: Has it ever worked correctly? A: I am not sure if it ever worked correctly as I cannot find any old data files however this issue has certainly existed since early last year.

    Umm, I don't quite understand. Are you the owner who purchased in 2016? Did the Cyton operate correctly at that time?? Data files are not needed. It either worked or did not work. It must have worked correctly, otherwise you would have complained, no?

    According to the date on this V1 firmware link (mid 2016),

    https://github.com/OpenBCI/OpenBCI_Cyton_Library/releases/tag/v1.0.0

    You may indeed have the V1 radio firmware. So you now have a mix of V3 PIC32 and V1 RFduino firmware. You should follow the directions here:

    https://github.com/OpenBCI/OpenBCI_Cyton_Library/blob/master/UPGRADE_GUIDE.md
    https://docs.openbci.com/docs/02Cyton/CytonRadios
    https://docs.openbci.com/docs/02Cyton/CytonProgram

    "...however this issue has certainly existed since early last year..." What happened in early 2020, was that the time you loaded the V3 PIC32 firmware?

    Regards, William

  • wjcroftwjcroft Mount Shasta, CA

    Another way to confirm correct radio firmware, is to try some of the commands listed in section 5. Expand the arrow to see section. These commands just configure radio channels using V2 radio firmware serial port commands.

    https://docs.openbci.com/docs/01GettingStarted/01-Boards/CytonGS#5-optional-settings

  • mjmcmahonmjmcmahon Dublin Ireland

    Hi William

    I purchased the Cyton board in 2016 for a Hackaton where we worked on a basic BCI-VR using OpenVibe and it did appear to work fine however I was not examining the raw data closely at the time and the issues is subtle since I still receive data from the board and it is not immediately apparent that the packet counter is right shifting the values which throws out the calculation for each channel. I put it away after that and did not really use it again until last year and that was when I loaded the V3 PIC32 firmware.

    So I tried the commands listed in section 5 as you suggested and the results would seem to confirm that I need to update the radio firmware. If I try auto-scan it recognises the board is connected and returns info but it also gives a 'Fails to connect using COM4' warning.

    However, even with the error, I am able to Start a Session which returns data from the board and you can see the impact of the packet counter on Channel 1

    So I will attempt to update the Radio Firmware and report back. It is a pity that the RFduino USB Shield seems to have been discontinued - it is getting quite difficult to find one now and it looks like to simplest way to update that firmware.
    Thanks
    Michael

  • wjcroftwjcroft Mount Shasta, CA

    Michael, hi again.

    So I will attempt to update the Radio Firmware and report back. It is a pity that the RFduino USB Shield seems to have been discontinued - it is getting quite difficult to find one now and it looks like to simplest way to update that firmware.

    The simplest way to upgrade the RFduino firmware, is with the previous links. The 'Wifi Shield' will eventually be back in the shop, but even if it was available, it would not be able to upgrade your RFduino radios. It DOES allow Wifi transfer of data, but it also requires a fully working Cyton with up to date firmware.

    Best regards, William

  • mjmcmahonmjmcmahon Dublin Ireland

    Hi William

    I am following those instructions closely - I was just referring as an aside to the availability of the RFduino USB Shield mentioned as an FTDI cable breakout option for the serial connection between the board and computer when updating the Radio Firmware. In any case I have purchased the SparkFun FTDI Basic Breakout - 3.3V (DEV-09873) which should do the job fine.

    Thanks

    Michael

  • wjcroftwjcroft Mount Shasta, CA

    The Cyton dongle can also act as a 'passthrough', I see that was likely what you were referring to:

    https://docs.openbci.com/docs/02Cyton/CytonRadios#program-device-radio-with-openbci-dongle

    The breakout you mention will probably be easier to use.

  • mjmcmahonmjmcmahon Dublin Ireland

    Hi William

    I have been attempting to upgrade the RFduino firmware as recommended over the last few days however I am encountering an issue

    I am using a Sparkfun FTDI Basic Breakout 3.3V (DEV-09873) to upload the firmware code to the Cyton Board RFduino. My 32 bit Cyton board does have the blue buttons so I am assumming that I do not need the 0.1uF capacitor as per the documentation it should already be on the board.

    My setup is as below and I am using a 4pin female header to keep the wires in place.

    FTDI RX --> RF TX
    FTDI TX --> RF RX
    DTR --> RF RST
    GND --> GND

    However when I attempt to upload the software I do see the TX and RX led's blinking several times but I consistently get one of the two following errors:


    I have looked through the forum and seen the same issue come up a few times but I have not seen a explanation of what is causing it or how to resolve this problem.

    https://openbci.com/forum/index.php?p=/discussion/269/unable-to-program-onboard-rfduino
    https://openbci.com/forum/index.php?p=/discussion/2663/rfduino-usb-shield-to-program-device-radio-fail

    Any idea what is going on?

    Regards

    Michael

  • wjcroftwjcroft Mount Shasta, CA

    Are you using the capacitor as instructed here:

    https://docs.openbci.com/docs/02Cyton/CytonRadios#ftdi-basic-breakout

    Sparkfun makes an FTDI breakout as well, and they come in a couple of flavors. 5V and 3V. By now, you know that you want the 3V Version. [pic coming soon] The Basic Breakout isn't as fancy as the FTDI Friend, but you do need to put a 0.1uF capacitor between the DTR pin and the RF RST pin. Also, if you have a version of this board with a voltage selection on the back, make sure that it has the 3.3V pads connected and the 5V pads cut!

  • mjmcmahonmjmcmahon Dublin Ireland

    Ah - OK so this is where I was getting a bit confused - further up in the instructions on the page it states

    If you have blue buttons on your board you do not need the 0.1uF capacitor because it is already on the board.

    which I do have on my Cyton board.

    So I assume this instruction is intended to be specific to programming the DEVICE Radio with OpenBCI Dongle. However if you are using the Sparkfun FTDI Basic Breakout 3.3V (DEV-09873) then the capacitor is still required.

    In any case I have ordered some 0.1uF capacitors and they should arrive tomorrow so I will give it another shot.

    Thanks for the continued assistance William - I will update the thread on progress.

  • mjmcmahonmjmcmahon Dublin Ireland

    Unfortunately no luck. I have been trying with the inclusion of the 0.1uF capacitor.

    DTR --> 0.1uF capacitor --> RF RST

    As with previous attempts I see the TXD and RXD LED's flash and then I get the same error message:

    "expecting 14, got 30
    fail....fail....fail...."

    Any further ideas on how to resolve or approach this issue would be appreciated.

  • wjcroftwjcroft Mount Shasta, CA

    Michael, hi.

    Sorry you are having all these upload failures. See this other thread link below for some suggestions. In particular at the end of the thread, RomanKT (Roman Butsiy) shows a revised (latest version 2.3.3) RFDLoader that possibly avoids this timing related glitch you are seeing with the older RFDLoader being used as default. Windows exe and Linux exe provided. For example on Windows that file replaces:

    • C:\Program Files\Arduino\hardware\arduino\RFduino\RFDLoader.exe

    https://openbci.com/forum/index.php?p=/discussion/269/unable-to-program-onboard-rfduino#latest

    Mentioning @romankt315.

    I'm unclear why this failure is happening. The Cyton's are being flashed at OpenBCI with no issues. But that may be because the flashing is being done with old non-updated MacOS Arduino IDEs. And newer Windows 10 / Linux builds need a newer RFDLoader(?)

    William

  • mjmcmahonmjmcmahon Dublin Ireland

    Hi William

    SUCCESS !

    I did not need to use the revised RDFLoader in the end. While I was prepping to do as you suggested I decided to swap out all the wires for new ones and use a fresh 0.1uF capacitor and rerun using the 1.5.8 version first. Worked perfectly - so either I had a dodgy capacitor or bad cable connection. I should have obviously checked that earlier. Here is photo of my setup in case it is of help to anyone else in the future who encounters a similar issue.

    I will setup the Dongle Radio and retest the data stream to confirm the original issue is resolved and report back on the thread.

    Thanks for all your patience and assistance in resolving this.

    Regards

    Michael

  • mjmcmahonmjmcmahon Dublin Ireland

    Hi William

    Looks like that did the job and signal data format is now correct.

    Thanks again for all the assistance.

    Regards

    Michael

Sign In or Register to comment.

© Vanilla Keystone Theme 2026