Unable to get data stream via GUI, V2 firmware

rfalpha · November 2016

I recently the 32-bit board and followed the instructions in the "Getting Started" guide. However, when I open a live session, and start the data stream, I get nothing in the GUI. I opened the GUI in Processing and noticed the following error when the data stream is started:

OpenBCI_ADS1299: interpretBinaryStream: Actbyte = -63

OpenBCI_ADS1299: interpretBinaryStream: expecteding end-of-packet byte is missing. Discarding packet. (28734)

Firmware version on the board is confirmed to be v2.0.0. Can anyone tell me why the end-of-packet byte is missing during the data stream session?

wjcroft · November 2016

RF, hi.

Can you try on another OS or laptop? What OS are you using? Install the FTDI driver?

If you know how to use a terminal emulator program, you can connect to that COM port and send a '?' to print some startup information from the firmware. It sounds like you already saw some of that output on the Processing terminal window, such as the firmware version. Any other output from the Processing debug output window?

https://en.wikipedia.org/wiki/Comparison_of_terminal_emulators

https://en.wikipedia.org/wiki/Terminal_emulator

Arduino IDE also has an emulator. Set baud to 115200. If you are in NYC, the OpenBCI lab is nearby in Brooklyn.

http://openbci.com/index.php/contact

William

rfalpha · November 2016

Here the logs from the terminal and the rest of the processing console:

https://www.dropbox.com/s/1xcbt517m26xy5h/processing_debug_log?dl=0

https://www.dropbox.com/s/uc7o0boowxw462o/terminal output?dl=0

I did install the FTDI drivers, and I am able to communicate with the openBCI board. I can use the terminal to issue commands (e.g. 0x0F 0x00 to return channel number).

wjcroft · November 2016

RF, thanks.

From the Processing debug log you provided, it looks pretty normal, up to the point at the end where it says the expected end-of-packet byte is missing. I'm going to mention AJ Keller @pushtheworld, the V2 firmware developer to see if he has any insights. What Windows OS are you running? Can you try using another laptop or OS?

I've appended the Processing debug log output (from your Dropbox) below for convenience,

----

Welcome to the Processing-based OpenBCI GUI!

Last update: 2/16/2016

For more information about how to work with this code base, please visit: http://docs.openbci.com/tutorials/01-GettingStarted

For specific questions, please post them to the Software section of the OpenBCI Forum: http://openbci.com/index.php/forum/#/categories/software

Graphics & GUI Library: ControlP5 2.2.6 infos, comments, questions at http://www.sojamo.de/libraries/controlP5

OpenBCI_ADS1299: prefered_datamode = 1, nValuesPerPacket = 8

OpenBCI_ADS1299: a

OpenBCI_ADS1299: b

OpenBCI_ADS1299: i

OpenBCI_ADS1299: openSerialPort: attempting to open serial port COM11

OpenBCI_ADS1299: openSerialPort: port is open (t)? ... true

OpenBCI_ADS1299: j

openBCI: openNewLogFile: opened output file: SavedData\OpenBCI-RAW-2016-11-29_09-51-16.txt

OpenBCI_ADS1299: systemUpdate: [0] Sending 'v' to OpenBCI to reset hardware in case of 32bit board...

OpenBCI V3 8-16 channel

On Board ADS1299 Device ID: 0x3E

LIS3DH Device ID: 0x33

Firmware: v2.0.0

$$$OpenBCI_ADS1299: syncWithHardware: [1] Sending channel count (8) to OpenBCI...

OpenBCI_ADS1299: syncWithHardware: [2] Reseting OpenBCI registers to default... writing 'd'...

updating channel settings to default

$$$OpenBCI_ADS1299: syncWithHardware: [3] Retrieving OpenBCI's channel settings to sync with GUI... writing 'D'... waiting for $$$...

060110$$$OpenBCI_ADS1299: read(): x

060110

OpenBCI_ADS1299: read(): y

0,6,0,1,1,0

OpenBCI_ADS1299: read(): z

OpenBCI_ADS1299: syncWithHardware: [4] Retrieving OpenBCI's full register map for verification... writing '?'... waiting for $$$...

Board ADS Registers

ADS_ID, 0x00, 0x3E, 0, 0, 1, 1, 1, 1, 1, 0

CONFIG1, 0x01, 0x96, 1, 0, 0, 1, 0, 1, 1, 0

CONFIG2, 0x02, 0xC0, 1, 1, 0, 0, 0, 0, 0, 0

CONFIG3, 0x03, 0xEC, 1, 1, 1, 0, 1, 1, 0, 0

LOFF, 0x04, 0x02, 0, 0, 0, 0, 0, 0, 1, 0

CH1SET, 0x05, 0x68, 0, 1, 1, 0, 1, 0, 0, 0

CH2SET, 0x06, 0x68, 0, 1, 1, 0, 1, 0, 0, 0

CH3SET, 0x07, 0x68, 0, 1, 1, 0, 1, 0, 0, 0

CH4SET, 0x08, 0x68, 0, 1, 1, 0, 1, 0, 0, 0

CH5SET, 0x09, 0x68, 0, 1, 1, 0, 1, 0, 0, 0

CH6SET, 0x0A, 0x68, 0, 1, 1, 0, 1, 0, 0, 0

CH7SET, 0x0B, 0x68, 0, 1, 1, 0, 1, 0, 0, 0

CH8SET, 0x0C, 0x68, 0, 1, 1, 0, 1, 0, 0, 0

BIAS_SENSP, 0x0D, 0xFF, 1, 1, 1, 1, 1, 1, 1, 1

BIAS_SENSN, 0x0E, 0xFF, 1, 1, 1, 1, 1, 1, 1, 1

LOFF_SENSP, 0x0F, 0x00, 0, 0, 0, 0, 0, 0, 0, 0

LOFF_SENSN, 0x10, 0x00, 0, 0, 0, 0, 0, 0, 0, 0

LOFF_FLIP, 0x11, 0x00, 0, 0, 0, 0, 0, 0, 0, 0

LOFF_STATP, 0x12, 0x00, 0, 0, 0, 0, 0, 0, 0, 0

LOFF_STATN, 0x13, 0x00, 0, 0, 0, 0, 0, 0, 0, 0

GPIO, 0x14, 0x0F, 0, 0, 0, 0, 1, 1, 1, 1

MISC1, 0x15, 0x00, 0, 0, 0, 0, 0, 0, 0, 0

MISC2, 0x16, 0x00, 0, 0, 0, 0, 0, 0, 0, 0

CONFIG4, 0x17, 0x00, 0, 0, 0, 0, 0, 0, 0, 0

LIS3DH Registers

0x07 0

0x08 0

0x09 0

0x0A 0

0x0B 0

0x0C 0

0x0D 0

0x0E 0

0x0F 33

0x1F 0

0x20 8

0x21 0

0x22 0

0x23 18

0x24 0

0x25 0

0x26 0

0x27 0

0x28 0

0x29 0

0x2A 0

0x2B 0

0x2C 0

0x2D 0

0x2E 0

0x2F 20

0x30 0

0x31 0

0x32 0

0x33 0

0x38 0

0x39 0

0x3A 0

0x3B 0

0x3C 0

0x3D 0

$$$OpenBCI_ADS1299: syncWithHardware: [5] Writing selected SD setting (Do not write to SD) to OpenBCI...

OpenBCI_GUI: mousePressed: outside of CP clicked

OpenBCI_ADS1299: startDataTransfer(): writing 'b' to the serial port...

OpenBCI_ADS1299: interpretBinaryStream: Actbyte = -63

OpenBCI_ADS1299: interpretBinaryStream: expecteding end-of-packet byte is missing. Discarding packet. (1)

OpenBCI_ADS1299: interpretBinaryStream: Actbyte = -63

OpenBCI_ADS1299: interpretBinaryStream: expecteding end-of-packet byte is missing. Discarding packet. (2)

OpenBCI_ADS1299: interpretBinaryStream: Actbyte = -63

OpenBCI_ADS1299: interpretBinaryStream: expecteding end-of-packet byte is missing. Discarding packet. (3)

OpenBCI_ADS1299: interpretBinaryStream: Actbyte = -63

OpenBCI_ADS1299: interpretBinaryStream: expecteding end-of-packet byte is missing. Discarding packet. (4)

rfalpha · November 2016

Thanks. I tried it on both a laptop and a PC, but both are running Windows 10. I don't have immediate access to another OS or Mac, so it would take me more time to get results for those.

rfalpha · December 2016

Any updates on this issue? I tried to re-compile the latest BCI host radio in Arduino, but receive the following error:

'class RFduinoGZLLClass' has no member named 'channel'

wjcroft · December 2016

Mentioning AJ @pushtheworld again.

Since the Processing log shows you have communications with all three firmwares, and OpenBCI is responding to the '?' you sent from the terminal emulator -- my guess is that the hardware (and FTDI driver) is working ok. More likely is that you have something odd with your Processing setup. Did you install from the source located here,

https://github.com/OpenBCI/OpenBCI_Processing

Sometimes installing the GUI from the zip file does not work.

re: compiling or reflashing the host radio, I would hold off on that until you can try some other things.

re: the error message you got, are you sure you are using the V2 radio firmware host radio source at,

https://github.com/OpenBCI/OpenBCI_Radios/tree/master

re: next steps

I still suggest you find another laptop or OS such as Linux and install the GUI from the source. You could also try an alternate [GUI like] program such as neuromore or BrainBay or one of the other VPLs. Use the search box in the right column.

Regards,

pushtheworld · December 2016

The only micro controller I would try to upload is the Pic32 with DefaultBoard.ino. Your radios are working fine if your getting that output.

Sounds like your board is trying to change its packet ending which is not really possible so maybe your Pic32 firmware got corrupted??

Have you ever used NodeJS? There is a great debug tool there and we can see exactly what the problem is. Flying blind with processing output!

wjcroft · December 2016

AJ, can you mention the link for the NodeJS debugger and your Node OpenBCI? Is the process to do the OpenBCI debugging spelled out?

Thanks,

rfalpha · December 2016

First attempt at running the Processing app under a Linux VM return this:

VMware: vmw_ioctl_command error Invalid argument.
Could not run the sketch (Target VM failed to initialize).
For more information, read revisions.txt and Help → Troubleshooting.

I'll try a native (non-virtual machine version) Linux installation tomorrow.

@pushtheworld, can you elaborate how to use NodeJS to debug the firmware?

pushtheworld · December 2016

@wjcroft and @rfalpha just for you guys, and anyone else who comes along next haha i wrote an example, tested it, pushed it, merged it, and released a new version of the node just for you guys.

Here is the link for the debug example.

Instructions are at the top of the file.

I have solved many problems using the debug bytes haha, have fun and hack on!

wezzix · December 2016

Hi,

Now there's at least two of us with this problem. I'm getting the exact same error using OpenBCI GUI Processing on my brand new 32 bit board received two days ago:

OpenBCI_ADS1299: interpretBinaryStream: Actbyte = -63

OpenBCI_ADS1299: interpretBinaryStream: expecteding end-of-packet byte is missing. Discarding packet. (28734)

OpenVibe Acquisition Server also doesn't start "No response for 1000 ms".

A serial terminal surely outputs data when pressing '?' and 'b'. Looks to me like a firmware error?

I would try your node js debug but it won't start, see output below. I'm not familiar with node js and have no idea what to do about this.

I would really appreciate any help to get my new board running.

Thanks

C:\OpenBCI_NodeJS\examples\debug>npm install

(node:16692) fs: re-evaluating native module sources is not supported. If you are using the graceful-fs module, please update it to a more recent version.

[email protected] C:\OpenBCI_NodeJS\examples\debug

├── [email protected] extraneous

└── [email protected] extraneous

npm WARN EPACKAGEJSON [email protected] No repository field.

npm WARN EBUNDLEOVERRIDE Replacing bundled node_modules\serialport\node_modules\node-pre-gyp with new installed version

npm ERR! Windows_NT 10.0.10586

npm ERR! argv "C:\\Program Files\\nodejs\\node.exe" "C:\\Users\\Username\\AppData\\Roaming\\npm\\node_modules\\npm\\bin\\npm-cli.js" "install"

npm ERR! node v6.9.2

npm ERR! npm v3.4.1

npm ERR! path C:\OpenBCI_NodeJS\examples\debug\node_modules\serialport\node_modules\node-pre-gyp\node_modules\mkdirp\bin\cmd.js

npm ERR! code ENOENT

npm ERR! errno -4058

npm ERR! syscall chmod

npm ERR! enoent ENOENT: no such file or directory, chmod 'C:\OpenBCI_NodeJS\examples\debug\node_modules\serialport\node_modules\node-pre-gyp\node_modules\mkdirp\bin\cmd.js'

npm ERR! enoent This is most likely not a problem with npm itself

npm ERR! enoent and is related to npm not being able to find a file.

npm ERR! enoent

npm ERR! Please include the following file with any support request:

npm ERR! C:\OpenBCI_NodeJS\examples\debug\npm-debug.log

pushtheworld · December 2016

This is very strange. I wonder how the boards are being tested before shipping, this seems like it should be caught.

I would recommend uploading the Default Board code following this tutorial.

Also, please make sure your dongle switch is in the GPIO6 position and not RESET.

wjcroft · December 2016

AJ, Wezzix did state above, "A serial terminal surely outputs data when pressing '?' and 'b'. Looks to me like a firmware error?". So he is saying he does see the firmware startup output text. Thus dongle must be working and not in RESET position.

Curious if @rfalpha is still seeing the end-of-packet byte missing errors.

Is it possible the new firmware might accidentally get into a state where it is sending the new end-of-packet codes, instead of the original end-packet code? Wouldnt a power up condition go back to defaults? Is there some state that would persist beyond power off / on?

pushtheworld · December 2016

@wjcroft that's going to be my regular disclaimer. Mainly because when you open the serial connection to the device with the switch in RESET, it will enter bootloader briefly and then go into regular boot up. If there is sufficient delay, as there is when you hit connect in a coolterm like program to when you actually write your first char, it is possible to miss the opportunity to bootload and hit a regularly booted system. However, when you are using a program that handles the opening of the serial port and immediately writes to the port, the board will still be in bootloader mode, and since you are not sending proper code you get a brick situation not resolved till power cycle. A key sign of this issue is the blue light will be off on the dongle.

@wezzix In your terminal program, please send a 'b', let the board stream, press 's' to stop stream, take a screen shot of the hex output and let's see it! I should be able to see the exact problem when i see the raw output. We are looking for every 33rd byte to be 0xC0.

wezzix · December 2016

Solution: Reprogramming the board fixes this issue.

Thanks to @pushtheworld I got it working after reprogramming the DefaultBoard code following the tutorial you mentioned. So the factory firmware was defect...!

Thanks for the help!

pushtheworld · December 2016

Happy to help will talk to team and provide this input

wjcroft · December 2016

Wezzix, AJ, that's great.

If we are seeing more PIC flash memory corruption / alterations, would it make sense to have the firmware on bootup, checksum the flash? And either print out that checksum or compare to a known good value and give an error message if flash has been corrupted?

wezzix · December 2016

I have read the OpenBCI library source as well as the GUI source in Processing and discovered the core of the issue.

-63 corresponds to end byte 0xC1

you should change the code in OpenBCI_ADS1299.pde to this to see it more clearly in the future:

println("OpenBCI_ADS1299: interpretBinaryStream: Actbyte = " + String.format("0x%02X", actbyte));

0xC0 is sent by board.sendChannelDataWithAccel();

0xC1 is sent by board.sendChannelDataWithRawAux();

GUI is only equipped to parse 0xC0 (accel) and classifies anything else including 0xC1 as error, which it really shouldn't. Yes it's not accel data, but neither is it an error and you get much less headache by being tolerant here and clear with any error text.

A fix is instead to use this code, which corresponds with the allowed stop bytes. Possibly you want 0xC2 there instead of 0xCF, not sure:

if (actbyte >= byte(0xC0) && actbyte <= byte(0xCF)) { // if correct end delimiter found:

So the factory firmware likely used the aux instead of accel end byte. I would recommend you make changes similar to the above to avoid further confusion.

Hope that helps.

For reference:

#define OPENBCI_EOP_STND_ACCEL 0xC0 // End of standard stream packet

#define OPENBCI_EOP_STND_RAW_AUX 0xC1 // End of stream packet with raw packet

#define OPENBCI_EOP_USER_DEFINED 0xC2 // End of stream packet, user defined

#define OPENBCI_EOP_ACCEL_TIME_SET 0xC3 // End of time sync up with accel stream packet

#define OPENBCI_EOP_ACCEL_TIME_SYNCED 0xC4 // End of time synced stream packet

#define OPENBCI_EOP_RAW_AUX_TIME_SET 0xC5 // End of time sync up stream packet

#define OPENBCI_EOP_RAW_AUX_TIME_SYNCED 0xC6 // End of time synced stream packet

wjcroft · December 2016

Wezzix, thanks. My question for AJ @pushtheworld would be, how could a newly shipped board get into a state where it sends the 0xC1 end byte? That state seems to persist over power cycles.

pushtheworld · December 2016

Somehow the wrong function must be getting fired. I can only assume from some OTA issue? The board can for sure send packets with many different endings, that's thanks for the complete rewrite of the radios, where you can now pass an extra four bits with each packet. However the DefaultBoard.ino should not be sending the raw aux packets. Very strange, it's like the wrong code was uploaded. The board still totally works. For example, if the basic board firmware was uploaded, you would get that packet ending. See source code.. https://github.com/OpenBCI/OpenBCI_32bit_Library/blob/master/examples/BasicBoard/BasicBoard.ino You could also checkout the readme for the OpenBCI 32bit library https://github.com/OpenBCI/OpenBCI_32bit_Library#sendchanneldata and look into the various functions.

wjcroft · December 2016

AJ, thanks. So are you saying it's possible that the OpenBCI staff that does the uploading of the V2 firmware, might have uploaded BasicBoard by mistake instead of DefaultBoard? Can you investigate that with Joel @biomurph or @Conor ? Perhaps the staff doing the uploading were confused by the 'Basic' vs 'Default' nomenclature.

This has happened for two customers, I wonder how many others may end up seeing this?

pushtheworld · December 2016

@wjcroft "I wonder how many others may end up seeing this" same....

I just pitched the idea to @biomurph for a project that would flash the board and verify the board streams properly and what have you. Would be a simple GUI.

akpc806a · December 2016

Hi guys,

It seems from discussion here and also source code, that the data packet format from 32-bit board is no longer compatible between V1 and V2 versions of GUI and firmware.

For example, the starting byte is no more 0xA0 (as expected here), but became 'A' (here in firmware code).

Can someone confirm that fact, or point that i'm wrong.

If there is no more compatibility, where I can find pre-compiled binary version of V2 GUI for Windows to test with V2 firmware.

Thanks!

wjcroft · December 2016

@akpc806a, hi.

So I think you may be at least the THIRD V2 firmware user who is reporting this. From the posts above, it seems the resolution would be to just reload your V2 firmware. Somehow it appears the wrong base package (BasicBoard) was loaded instead of DefaultBoard. AJ @pushtheworld, can you comment?

William

pushtheworld · December 2016

@wjcroft no, this is not related to this thread, @akpc806a is referring to the Pic32 code and that is the start byte from the Pic to the Device RFDuino. Because the radios are now stateless there is a start and stop byte to ensure those packets are immediately sent from Device to Host instead Rd of waiting 3ms like we must do for OTA programming.

It's still completely compatible. As has been written over and over, it does not lead to breaking changes under normal V1 operation.

akpc806a · December 2016

hi @pushtheworld. thanks a lot for your clarification, got it!

wjcroft · December 2016

AJ, ok sorry, I misunderstood @akpc806a 's post and thought he already had a newer board with V2 and was having trouble talking to the V1 GUI. "If there is no more compatibility, where I can find pre-compiled binary version of V2 GUI for Windows to test with V2 firmware."

Hopefully other people posting on this thread will be clear if they are getting error messages from V1 GUI.

biomurph · January 2017

The tutorial for uploading code to the Cyton (formerly 32bit) board has been updated.

http://docs.openbci.com/Hardware/05-Cyton_Board_Programming_Tutorial

This issue came from our uploading the 'BasicBoard' sketch instead of the 'DefaultBoard' sketch.

When you upload code to your Cyton, please use the 'DefaultBoard' sketch.

The issue has to do with the 'stopByte' in our data stream. In the new firmware, the value of 'stopByte' changes based on the type of data included in the packet.

The GUI will be updated in the next week or so to accomodate the different 'stopBytes'

aalireza · February 2017

@wjcroft

I have version 2.0 firmware running and have received this error as well.

I've tried to follow the tutorial (http://docs.openbci.com/Hardware/05-Cyton_Board_Programming_Tutorial) which resulted in an compilation error saying "Board_Defs.h" doesn't exist. I've downgraded chipkitCore and used what has been suggested here (http://openbci.com/forum/index.php?p=/discussion/comment/4239/#Comment_4239) however the error remains the same.

Could you help me fix this?

P.S. Since apparently this problem has happened before and would be immediately detectable by anyone trying to get data, I'm curious to know whether these boards have been tested even once before being sold to people or not.

Unable to get data stream via GUI, V2 firmware

Comments