Cyton wired USB connection, for V3.1.x firmware

salsal
edited June 2019 in Cyton
I wonder if anyone can chime in, I spent some time trying to get wired connection to work (I saw messages how it's not recommended etc., but I want to get this to work, and I see that some people got it to work).
I changed pin definitions in Board_Defs.h, changed board.begin() to board.beginDebug() in DefaultBoard.ino and flashed the firmware. So, when starting stream via user.py, I sometimes see exception, sometimes stream gets stuck, sometimes (quite rarely) see data (not as nicely as with bluetooth). I tried changing baud rate to 9600, and I see the same thing as at 115200. I also tried it without USB isolator (Adafruit 100mA USB Isolator), without noticeable improvement. I use Adafruit FT232H breakout board.
Would appreciate any kind of guidance with this.

Examples of output that I see:

Warning: ID:<219> <Unexpected END_BYTE found <230> instead of <192>
Warning: Skipped 405 bytes before start found
Warning: ID:<51> <Unexpected END_BYTE found <229> instead of <192>
Warning: Reconnecting
Stopping streaming...
Wait for buffer to flush...
Warning: Skipped 2096 bytes before start found
Warning: ID:<152> <Unexpected END_BYTE found <220> instead of <192>
Warning: Skipped 2589 bytes before start found
Warning: ID:<45> <Unexpected END_BYTE found <233> instead of <192>
Warning: Skipped 2930 bytes before start found
Warning: ID:<219> <Unexpected END_BYTE found <24> instead of <192>
Warning: Skipped 2999 bytes before start found
Exception in thread Thread-1:
Traceback (most recent call last):
  File "C:\Python27\lib\threading.py", line 801, in __bootstrap_inner
    self.run()
  File "C:\Python27\lib\threading.py", line 754, in run
    self.__target(*self.__args, **self.__kwargs)
  File "D:\Users\sal\Downloads\OpenBCI_Python-master\OpenBCI_Python-master\openbci\cyton.py", line 186, in start_streaming
    sample = self._read_serial_binary()
  File "D:\Users\sal\Downloads\OpenBCI_Python-master\OpenBCI_Python-master\openbci\cyton.py", line 263, in _read_serial_binary
    log_bytes_in = log_bytes_in + '|' + str(literal_read)
UnboundLocalError: local variable 'log_bytes_in' referenced before assignment

****Another example:

Warning: ID:<54> <Unexpected END_BYTE found <225> instead of <192>
Warning: Skipped 1072 bytes before start found
Warning: ID:<44> <Unexpected END_BYTE found <251> instead of <192>
Warning: Skipped 1251 bytes before start found
---------------------------------
ID: 226.000000
8089.878629431561, -187295.2580207894, 3082.909057487137, 173606.89325414816, 0.0, 4.291534935418956, 96296.18779375408, -7513.1589189957285
0.16975, -0.15962500000000002, -1.79275
---------------------------------
Warning: Skipped 1006 bytes before start found
Warning: ID:<31> <Unexpected END_BYTE found <0> instead of <192>
Warning: Skipped 1305 bytes before start found
Warning: ID:<1> <Unexpected END_BYTE found <0> instead of <192>

Comments

  • wjcroftwjcroft Mount Shasta, CA
    The "wired usb" firmware examples shown on these threads, were for 2.x firmware.


    Current firmware is 3.1.2. And the GUI and Python apps that interface with Cyton are also firmware 3.x based.
  • salsal
    Thanks for the answer, and pardon my ignorance, but I am using the latest firmware, and just changing serial wiring pins and switching begin to beginDebug (part of newest firmware, which seems like to be designed specifically for this purpose). The only thing that I am using from those old threads is how to connect wires. So, if Python apps are also 3.x based, I am confused as to why things don't quite work.
  • wjcroftwjcroft Mount Shasta, CA
    There might have been other changes involved. I have not looked closely. As you know a Github was setup with the 2.x changes.



    From your above output, it looks like you are missing the start byte. Take a look at the RFduino code, both dongle (host) and mainboard (device). The radios insert one or more bytes on each packet. As this was not needed for sending over the air, since packet boundaries are well defined. However with a serial stream, you need a sync mechanism.


    The start byte issue is also likely mentioned in the 2.x repo from Airan above.

    William

  • salsal
    Thank you very much William, yes, it turned out to be a different start byte.
  • wjcroftwjcroft Mount Shasta, CA
    The PIC32 and RFduino on the mainboard have their own serial port link, which operates with a different start byte. The instructions on the Airan-Lab repo explain how to workaround this.

    So I assume you got everything working ok with the V3 firmware. Can you post a summary of the steps you took?
  • salsal
    I am not near that computer at the moment, and didn't test everything so some things may still be off, but at least things displayed with user.py started to look normal.
    Anyway, as mentioned above, I changed pin definitions, changed begin to beginDebug. Then I made cyton.py to print every number that was coming in and took a look, which numbers showed up most frequently. One of the numbers was 65 (if I remember correctly). By trying to change start byte to 65 in cyton.py, user.py started to display things properly. So, it was a bit roundabout way to find that start byte but it seems to have worked.
  • wjcroftwjcroft Mount Shasta, CA
    edited June 2019
    Umm, the best way to find the start byte is to look at the data stream specification,


    The start byte is 0xA0, (160 decimal unsigned). The 65 you found is the 'internal' start byte just used between PIC and RFduino serial port. Did you look at the Airan-Lab repo instructions?? You need to INSERT the external (real) start byte in the Cyton firmware, changing the start byte that was used to communicate with the mainboard RFduino, into the start byte used by the this data stream spec.

    Let me know when you have a working usb serial link, using the actual data format spec.

    The reason I am asking FOR A LIST of what you had to change, all in one post, is that this will make it easier for any future users to achieve the wired usb, without having to look through various threads or repos. You might start with the list on the Airan-Lab Github and just edit, then post here. Alternately, post here a diff list of what you altered or eliminated in the Airan-Lab instructions. Because a significant portion of those instructions were handled by default in V3 firmware.

    Here is the section on that repo README relating to the start byte, did you see this?

    * Changed sendChannelData() and its cousins to write start byte 0xA0 first instead of A. I assume this was originally because the RFDuino does some packet changing, which no longer takes place since we go through the wired USB connection.

    Thanks,
  • wjcroftwjcroft Mount Shasta, CA
    The consequence of modifying the Python instead of the firmware, is that your wired usb will not work in the GUI or any other program expecting the standard data stream.
  • salsal
    edited June 2019
    Just writing 0xA0 instead of A in firmware didn't quite work, user.py prints a few lines of data and then gets stuck. I will spend some time later to see if I can get things fixed (the thing is, I am new to this). By the way, in one of the other threads you said regarding wired connection working with GUI: "The situation is also more complicated because you would have to mod two packages: GUI and Hub, which have complex interlinkage". Did you mean that even if wired connection starts working with Python libraries (the proper way, with 0xA0), it will still require more work to make it display in GUI? Thanks!
  • wjcroftwjcroft Mount Shasta, CA
    Sal, hi.

    re: python stuck

    DId you change ALL the places that the 'a' was used in the firmware. There is apparently more than one. I assume you changed your python also.

    re: using wired usb with GUI / Hub

    No, with the proper start byte, the GUI should work.

    Regards,

    William
  • wjcroftwjcroft Mount Shasta, CA
    The quote you gave was from a thread on Ganglion,


    "The situation is also more complicated because you would have to mod two packages: GUI and Hub, which have complex interlinkage"

    No relation to Cyton firmware.
  • salsal
    Thanks for clarifying on that.
    I found 'A' being written in 2 places, sendChannelDataSerialBLE and sendChannelDataSerial, so I tried changing it in sendChannelDataSerial first, then in both. I may try redoing it later in case I messed up. And yes, I changed python back to original.
  • wjcroftwjcroft Mount Shasta, CA
    Sal, hi.

    So everything is working now, GUI and Python?

    Thanks for going through these steps

    Regards,

  • salsal
    Sorry, no, the proper way is still not working. I rarely post on forums, so I need to become more clear. "Thanks for clarifying that" was referring to the post about Ganglion, and the rest referring to "Did you change ALL the places that the 'a' was used in the firmware." Admittedly, I didn't spend enough time on trying to figure it out yet, but I'll post here if I manage to get it to work. Thanks!
Sign In or Register to comment.

© Vanilla Keystone Theme 2026