Stream reads different from data format in the specs (Byte2 is always 0x41)
dmontezano
USA
in Cyton
Hi,
I have written a simple C code for reading the serial port which my OpenBCI Dongle is attached to.
I can successfully send commands to the Cyton board and read the response. For example, I have no problem sending a reset command (' v ') and reading back the 4-line initialization string the Cyton replies, even with the $$$ terminator string. All is good here.
Other commands also work fine, like turning channels on and off (using 12345678 and !@#$%^&;*), reading the sample rate (~), checking the version (capital V), and even starting and stopping the stream ('b' and 's').
Now here is the issue I am facing:
After I start the streaming (sending the 'b' command), I am getting packets that look slightly different than the specs of the data format (I got a v3 board and I understand that I can actually change this format at will, but I am first trying to see if it would read correctly the default data format).
Each packet in the stream that I get looks like this (here all channels are disable and board is in default mode and values are hex):
BYTE 1: A0 (correct start of packet)
BYTE 2: 41 (should be a sample number, but it is always 0x41)
BYTE 3: 03 (this increases by one with every packet, and it looks like it is the sample number offset by one)
BYTE 4: 00 (ch1 data)
BYTE 5: 00
BYTE 6: 00
BYTE 7: 00 (ch2 data)
BYTE 8: 00
BYTE 9: 00
BYTE 10: 00 (ch3 data)
BYTE 11: 00
BYTE 12: 00
BYTE 13: 00 (ch4 data)
BYTE 14: 00
BYTE 15: 00
BYTE 16: 00 (ch5 data)
BYTE 17: 00
BYTE 18: 00
BYTE 19: 00 (ch6 data)
BYTE 20: 00
BYTE 21: 00
BYTE 22: 00 (ch7 data)
BYTE 23: 00
BYTE 24: 00
BYTE 25: 00 (ch8 data)
BYTE 26: 00
BYTE 27: 00
BYTE 28: AC (accx1)
BYTE 29: AC (accx0)
BYTE 30: AC (accy1)
BYTE 31: AC (accy0)
BYTE 32: AC (accz1)
BYTE 33: 0xC0 (footer)
The problem is that there appears to be an extra byte with value 0x41 right after the header that comes in every packet and that it should not be there. Anybody seen anything similar to this before?
Note that between the header (0xA0) and the footer (0xC0) I have the correct number of bytes, but the second byte that should be the sample number is actually a fixed 0x41 that comes in every packet. By observing the stream, the third byte actually looks just like it would be the sample number, because it increases by 1 with every new packet.
So, the issue is that there is one byte of data that is missing from the stream. From my experiments here it looks like it would be the last accelerometer byte, but I am not a 100% sure. What I did was I tried turning each of the 8 EMG channels on and off one at a time and they seem to be correct, although offset by one due to the extra byte 0x41 at the beginning of the packet.
I appreciate any pointers of where I should look to understand what's happening and how to go about fixing it. Thanks!
PS: Even though I report the problem in my C++ code, the exact same problem happens in a MATLAB script that I also wrote to read the OpenBCI. Everything works fine but I get the extraneous 0x41 byte in every packet that I read.
I have written a simple C code for reading the serial port which my OpenBCI Dongle is attached to.
I can successfully send commands to the Cyton board and read the response. For example, I have no problem sending a reset command (' v ') and reading back the 4-line initialization string the Cyton replies, even with the $$$ terminator string. All is good here.
Other commands also work fine, like turning channels on and off (using 12345678 and !@#$%^&;*), reading the sample rate (~), checking the version (capital V), and even starting and stopping the stream ('b' and 's').
Now here is the issue I am facing:
After I start the streaming (sending the 'b' command), I am getting packets that look slightly different than the specs of the data format (I got a v3 board and I understand that I can actually change this format at will, but I am first trying to see if it would read correctly the default data format).
Each packet in the stream that I get looks like this (here all channels are disable and board is in default mode and values are hex):
BYTE 1: A0 (correct start of packet)
BYTE 2: 41 (should be a sample number, but it is always 0x41)
BYTE 3: 03 (this increases by one with every packet, and it looks like it is the sample number offset by one)
BYTE 4: 00 (ch1 data)
BYTE 5: 00
BYTE 6: 00
BYTE 7: 00 (ch2 data)
BYTE 8: 00
BYTE 9: 00
BYTE 10: 00 (ch3 data)
BYTE 11: 00
BYTE 12: 00
BYTE 13: 00 (ch4 data)
BYTE 14: 00
BYTE 15: 00
BYTE 16: 00 (ch5 data)
BYTE 17: 00
BYTE 18: 00
BYTE 19: 00 (ch6 data)
BYTE 20: 00
BYTE 21: 00
BYTE 22: 00 (ch7 data)
BYTE 23: 00
BYTE 24: 00
BYTE 25: 00 (ch8 data)
BYTE 26: 00
BYTE 27: 00
BYTE 28: AC (accx1)
BYTE 29: AC (accx0)
BYTE 30: AC (accy1)
BYTE 31: AC (accy0)
BYTE 32: AC (accz1)
BYTE 33: 0xC0 (footer)
The problem is that there appears to be an extra byte with value 0x41 right after the header that comes in every packet and that it should not be there. Anybody seen anything similar to this before?
Note that between the header (0xA0) and the footer (0xC0) I have the correct number of bytes, but the second byte that should be the sample number is actually a fixed 0x41 that comes in every packet. By observing the stream, the third byte actually looks just like it would be the sample number, because it increases by 1 with every new packet.
So, the issue is that there is one byte of data that is missing from the stream. From my experiments here it looks like it would be the last accelerometer byte, but I am not a 100% sure. What I did was I tried turning each of the 8 EMG channels on and off one at a time and they seem to be correct, although offset by one due to the extra byte 0x41 at the beginning of the packet.
I appreciate any pointers of where I should look to understand what's happening and how to go about fixing it. Thanks!
PS: Even though I report the problem in my C++ code, the exact same problem happens in a MATLAB script that I also wrote to read the OpenBCI. Everything works fine but I get the extraneous 0x41 byte in every packet that I read.
Comments
No, I did not test the board with the GUI. That is something I can try as well.
Do you know if there is a way I can check for these different firmwares, or should I just go ahead and update all of them? I am not even sure I know how to do that.
I can get the version from the Cyton board (I assume it is the PIC), but I do not know how to check firmware versions of the other processors.
I'll have to look for the docs on how to do it.
I installed the OpenBCI_RFduino and OpenBCI_Radios library according to the tutorial you linked above but when I open the Arduino IDE I face two issues:
1) cannot find the RFduino board for selection;
2) OpenBCI_Radios library appears under the INCOMPATIBLE submenu in the examples, which does not seem correct.
I'll keep on working to see if I can figure out what I am doing wrong.
Also the numbers are very easy to get mixed up (1.8.5 vs. 1.5.8). Maybe a call out would help there.
I downloaded the 1.5.8 BETA and copied the RFduino into the \hardware\arduino folder. I can now select the RFduino board and the RadioHost32bit example shows up correctly.
I will keep working on the update now. Thanks!
Instead of rushing up I'll just ask here first. I am not sure how to handle the flashing correctly:
To reprogram the HOST we should first program the dongle using this setup():
void setup() {
radio.flashNonVolatileMemory();
radio.begin(OPENBCI_MODE_HOST,20);
}
And then program again using this other setup():
void setup() {
//radio.flashNonVolatileMemory();
radio.begin(OPENBCI_MODE_HOST,20);
}
Is that the correct way to do it?
Hopefully when I update the DEVICE the parties will start communicating and working again.
Working on that now.
I ran the C code, and it read the board correctly once (I got the initialization string back after sending 'v'). However, after that first success it stopped responding, no matter which command I send. Board became completely silent.
The board has come back to reading the version, and accepting commands and replying correctly both in my C and MATLAB codes.
Now when I start the stream it looks like I am getting the correct packets with correct sample number and correct data. I will check on everything in more detail over the next week, but it looks like it is working as it should.
Thanks for your help and patience. I guess this closes the issue. The problem was indeed a mismatch of the firmware versions.