Using Wired USB Connection with Firmware 2.x.x

dancingdarwindancingdarwin
in Cyton
Hi there,
Inspired by Winslow's Wired USB tutorial, I'm now trying to make a similar modification to the Firmware 2.x.x for using D11/D12 as UART2. I noticed that you already use Serial 0 for transmitting data and Serial 1 for transmitting debug information, and that there was a comment in there saying that you could set _SER0_TX_PIN and _SER0_RX_PIN to Pins 11 and 12 respectively to just have it use the appropriate GPIO pins. However, when I make that modification to Board_Defs.h then after reflashing it appears the OBCI board is bricked. The D1 LED doesn't light up anymore and I get no response via serial connection (after checking baud rate). So then I tried swapping out references to Serial0 and Serial1 in the code, while setting _SER1_TX_PIN and _SER1_RX_PIN to Pins 11/12 (similar approach that Winslow takes). However, it appears that so far also does not work out, with a similar error. I was just wondering if there's something missing that I should be considering?

Thanks so much!
Jeff

Comments

  • wjcroftwjcroft Mount Shasta, CA
    Jeff, thanks.

    Be cautious with your use of the word 'bricked'. That usually implies a fatal firmware loader bug that permanently destroys the hardware. In your case you can still reload new firmware.

    With the wired usb mods for V1, the PIC sends the EEG data stream on Serial1, which has RX TX wired over to the FTDI breakout board. Serial0 is reserved for the link between the PIC and the RFduino. Which is still needed for bootloading.

    In V1 this required some fiddling with the pin definitions to avoid conflicts with the Serial1 port. So @Winslow_Strong details those steps in his Github page. However with V2, I believe AJ Keller @pushtheworld, the V2 dev, has made the use of Serial1 much easier, in that those new pin definitions are already the defaults. So really the bottom line is that Serial1 should work on V2 with no redefinitions required.

    https://github.com/WinslowStrong/OpenBCI_Wired_USB

    http://openbci.com/forum/index.php?p=/discussion/712/prospects-for-higher-sample-rates#latest

    William
  • dancingdarwindancingdarwin
    Hi William,
    Ohhh I see. Sorry about the misuse of terminology!

    Yea I've been working through implementing similar changes that Winslow made. That makes sense that Serial 0 should not be touched with the RFDuino. Here's the docstring from the V2 function OpenBCI_32bit_Library::beginDebug()

    ------------------
    The function the OpenBCI board will call in setup. Turns sniff mode on and allows you to tap into the serial port that is broken out on the OpenBCI 32bit board. You must alter this file:
    On Mac:
         `/Users/username/Documents/Arduino/hardware/chipkit-core/pic32/variants/openbci/Board_Defs.h`
    On Windows:
        `C:\Users\username\Documents\Arduino\hardware\chipkit-core\pic32\variants\openbci\Board_Defs.h`

    Specifically lines `311` and `313` from `7` and `10` to `11` and `12` for  `_SER1_TX_PIN` and `_SER1_RX_PIN` respectively. Check out this sweet gif if you are a visual person http://g.recordit.co/3jH01sMD6Y.gif. You will need to reflash your board! But now you can connect to pins `11` and  `12` via a FTDI serial port driver, really any serial to USB driver would work. Remember to use 3V3, 115200 baud, and have a common ground! In this scenario, we set SER0 to 11 and 12 respectively, and set SER1 to 14 and 6. This way we can use the wired connection for higher speed data streaming and wireless for debugging @author: AJ Keller (@pushtheworldllc)
    ------------------

    By changing the board_defs file such that SER1 points to pins 11/12, and then switching Serial0 and Serial 1, I can get data to stream over the FTDI stream. The weird part is that it only works when I call the board in debug mode. Then LED D1 lights up and I get responses over UART2. If I call just begin (not beginDebug) then D1 doesn't light up and I have no responses over the serial connection. Is there something important about the RFDuino serial connection that I'm missing?

    Thanks!
    Jeff
  • wjcroftwjcroft Mount Shasta, CA
    Jeff,

    Hmm, interesting. I guess I was mistaken about the defs file being fixed in V2. I still don't understand why using Serial1 requires extra work. Seems like it should be enabled by default so any OpenBCI user can be free to use Serial1 port for their projects. Perhaps AJ @pushtheworld will add some comments.

    William

  • wjcroftwjcroft Mount Shasta, CA
    I guess it might be because we are inheriting the 'standard' chipKIT definitions. And this is a conflict with chipKIT defaults.
  • dancingdarwindancingdarwin
    Yea I think it's because we have to download the chipKIT definitions from their website instead of using our own custom definitions. The fact that we have to also activate Serial0 for data to be streamed through Serial1 is also a bit strange.

    Also, I noticed that the OBCI_Python code doesn't seem to support custom stop codes from v2. Is there any dev on that front? I'm planning on modifying it a bit anyways for our application, so I can fork and file a pull request down the road to fix that and also adjust it so that it works with Python 3 as well.
  • wjcroftwjcroft Mount Shasta, CA
    Jeff, sounds great thanks.

    Pull request for Python 3 appreciated. (Assuming that can be done so as not to break previous Pythons).

    re: Python, Jeremy Frey @jfrey is the original dev. AJ Keller @pushtheworld is the originator of the new stop code feature.
  • dancingdarwindancingdarwin
    OK sounds like a plan. If AJ @pushtheworld could chime in about the debug board issue, that would be wonderful! Otherwise it's just a minor inconvenience. Thanks so much for your help!
  • wjcroftwjcroft Mount Shasta, CA
    You said earlier, "I can get data to stream over the FTDI [serial port] stream", so your wired USB is working? Be sure to use an appropriate USB isolator. There are some models now that meet medical 5KV ISO 60601 standards, although 3KV is quite decent and what Adafruit offers.

    Can you say a bit more on your application, sample rates, etc. Post a link here to your Github with the running V2 wired usb. @Winslow_Strong I'm sure would be interested.

    Regards,
  • pushtheworldpushtheworld
    You still need to remap the pins in the file to get debug to work! If you're trying to get data into python you should take a look at the node to python example https://github.com/OpenBCI/OpenBCI_NodeJS/blob/master/examples/python/readme.md

    The Node SDK takes full advantage of the different stop bytes.

    The external D1 LED will NOT work once the pins are remapped and you activate Serial1 because Serial1 then uses the same digital I/O as the LED. So you are farther away from bricked and closer to what you actually want!
  • dancingdarwindancingdarwin
    @WJCroft Yep I'm using the Adafruit USB Isolator that @WinslowStrong recommended. I'll try to organize the code and post it up on Github. I actually already spoke with him over Github too. We're working with rats and trying to get high frequency oscillations around the ~120-150 Hz range. So we're gunning for around a 500 Hz stream with some real time output. 

    @pushtheworld thanks for the link! I'm not super familiar with JS but it looks like I can get most of what I want to do by just passing JSON files? And to clarify I should modify index.js to implement responses to certain commands? Also, where do I call npm install/npm start? Do I call them in the same directory and do I have to call npm install after modifying index.js?

    Also, that's interesting about the LED. Is there another LED/alternative pin that I can use to at least confirm power is running through the board? Also, it doesn't quite explain why the Serial 1 is unresponsive if Serial 0 is not activated as well. I swapped all occurrences of Serial 1 for Serial 0 and remapped Serial 1 to pins 11/12 and the port only works when I use beginDebug instead of begin (also when I use beginDebug D1 lights up perfectly). I guess it doesn't really matter, since it seems like all it does is just cause some extra stuff to be printed out. I haven't tried actually just activating Serial0 in begin without actually using it. That might be a bit curious.

    Thanks so much for your help! You guys are the best.
  • pushtheworldpushtheworld
    @dancingdarwin you should check out the 3.0.0 codebase I've been working on, had to put down temporarily. but i want to give external serial port control out of the box on the default board.


    "I can get most of what I want to do by just passing JSON files" that's right! I have built a pretty sick app using this type of framework. splitting analytics and data acquisition relieves the python process of time-consuming byte stream parsing so python can focus on analytics. I would recommend putting the whole example into it's own directory, your project directory. In terminal, "cd" over to your project dir. Do "npm install" after installing node. Then you can run "npm start" anytime you want to run the app. You only call npm install once, npm start is what you call every time.

    Modifying the index.js you will want to add commands and simply add to the "processInterfaceObject" function https://github.com/OpenBCI/OpenBCI_NodeJS/blob/master/examples/python/index.js#L142

    Say you want to stop streaming once you get enough data from python. You could make a new command such as "stream" with action "stop". You would add a new case "stream" to "processInterfaceObject" and create and call a function called  "processStream" from that "stream" case. Then in that new "processStream" function, you could have switch statement with a case of "stop" which would call the function "ourBoard.streamStop()". 
  • dancingdarwindancingdarwin
    @pushtheworld Ahh that would be pretty nice re the 3.0.0 upgrade! I'll take a look after at least getting our system to work with the current software tools.

    Thanks for the info on how to use the javascript file. Sorry if this is a dumb question, but I'm just trying to figure out how to make this work for our purposes (different sample rate):

    1) It looks like from source code of the library that you set the sample rate as either 125 or 250 based on whether it's based on daisy. Is it ok if I don't touch that and just use my own numbers for the resync period? Also, if I modify the source code, how do I reinstall the library into npm? I assume npm install openbci just installs it directly from your repos
    2) Since synchronization is good only up to +/- 4 ms, at 500 Hz smapling frequency would you recommend just forgoing the time sync?
  • dancingdarwindancingdarwin
    edited January 2017
    @pushtheworld @wjcroft I finished making the modifications to the code and also updated @Winslow_Strong 's tutorial with the updated information! Here's the repos: https://github.com/Airan-Lab/OpenBCI_32bit_Library_Wired. Thanks so much for both of your help; none of this would have been possible without you!
  • pushtheworldpushtheworld
    @dancingdarwin thanks so much for the code! I am going to implement this in my dev-3o branch tomorrow. 
  • wjcroftwjcroft Mount Shasta, CA
    Great work guys, and thanks again to @Winslow_Strong for spearheading / trailblazing this capability. Open source rocks. 

    AJ, I suggest linking back to these forum threads in any docs you generate on the wired USB. For those looking for the history and for example how to achieve even higher bit rates with FTDI related tweaks. (Aligning the baud rates on PIC and FTDI so they exactly match vs. 'approximately' match.)

    William

  • pushtheworldpushtheworld
    All

    This has been fixed in new 3.0.0-rc5

  • dancingdarwindancingdarwin
    @pushtheworld Brilliant! Thanks so much for your help! I've been having some issues with dropped packets at 1 kHz but the board's been performing beautifully at 500 Hz. Glad to see the new release out.

    On a related note, I saw the news about the wifi shield in the release notes. Is the beta still going on? Either way, looking forward to seeing those come out!
  • pushtheworldpushtheworld
    @dancingdarwin

    What baud rate are you using? Beta is over and boards are on sale very soon!
  • dancingdarwindancingdarwin
    @pushtheworld Right now we're using 460800 baud. Looking forward to the rollout!
  • pushtheworldpushtheworld
    Wow that's so cool! And you were able to use boardBeginDebug()?
  • dancingdarwindancingdarwin
    @pushtheworld Yep! boardBeginDebug() works for the 2.x.x firmware. I haven't pushed the 3.0 firmware update because I don't want to break anything while we're working on a wave of experiments. I'll let you know when I get around to it and get a good idea of how well it's working!
  • pushtheworldpushtheworld
    @dancingdarwin i think waiting is a great idea, the 3.0 firmware is getting more stable by the day, but not 100% yet

    keep up the great work
  • togumetogume United States
    @dancingdarwin - thanks for your work on https://github.com/Airan-Lab/OpenBCI_32bit_Library_Wired. Now that the 3.0 firmware is out in the wild, do you have any recommendations for anyone looking to do a wired USB connection to the PC? Do you feel that the tutorial on the repo is still relevant today?
  • dancingdarwindancingdarwin
    edited March 2019
    Hi @togume, I highly recommend switching to the WiFi shield now. I've been getting <0.5% dropped packets at 1 kHz sampling rates with very little configuration. The problem is that the USB breakout has a relatively small ring buffer and because it's a serial connection, single dropped packets are more likely to be devastating. At 1 kHz sampling I can only record for like maybe 3 minutes before packets start dropping and at 500 Hz I can only record for about 15 minutes reliably.

    In case you still want to do a wired USB connection, the tutorial should be the exact same on the hardware front, and the principles should still be the same. I'd recommend git diffing my repos against the 2.0 firmware and looking at the changes to use the debug channel and reroute it through the serial pins. Please feel free to let me know if you have any questions!
  • wjcroftwjcroft Mount Shasta, CA
    Jeff, hi. Thanks for the update.

    One user on another thread, mentions he needs wired USB to avoid radio congestion in large venues such as conventions,


    So I pointed him over here.

    re: small buffering in the FT232H that you used.

    There are a range of usb serial chips on the market, many with breakout boards. It's possible there is one that has more buffering.

    re: packet lossage in general with usb serial

    One issue that I covered when Winslow and I were working on this, is the mismatch between UART speeds at higher rates. (Between the PIC32 UART and the breakout UART.) Winslow and I discussed some workarounds for that using info from the FTDI app notes. Not sure if you saw that material, but it might explain some of your lossage.

    re: .5% dropped packets with Wifi Shield and 1 kHz sample rate.

    Are you using the UDPx3 transmission method. This seems to solve the issues with TCP mode.

    Regards,

    William

  • wjcroftwjcroft Mount Shasta, CA
    This comment and the one following contain the info about custom baud rates on the FTDI chip. And explain why the PIC32 has a clock that doesnt quite meet standards for async communications at high baud rates. The app note may provide a workaround.

  • togumetogume United States
    edited March 2019
    Thanks, @dancingdarwin! Great data points. The issues you mention will definitely be problematic for our work.

    @wjcroft - I sent this along via the contact us to OpenBCI, but worth noting here: making a wishlist request for a future OpenBCI plug & play USB solution (USB-C ?!) :).
  • dancingdarwindancingdarwin
    @wjcroft Thanks for the explanation for why USB was needed!

    Re: USB packet loss- Yea we considered adding an additional breakout board but we saw the WiFI shield and decided to switch to that. I indeed didn't that thread that you sent me. Definitely will keep that in mind if we decide to go back to the wired solution. Thanks so much! @togume you might be able to get some better performance if you follow those instructions!

    Re: Wifi packet loss- Thanks for the advice! Indeed I've been having much better performance with UDP on the OpenBCI GUI before and should have changed our custom software accordingly...
  • StrikerootStrikeroot

    @dancingdarwin said:
    I highly recommend switching to the WiFi shield now. I've been getting <0.5% dropped packets at 1 kHz sampling rates with very little configuration.

    Please tell me @dancingdarwin, is this paired with Cyton or Ganglion?

  • dancingdarwindancingdarwin

    @Strikeroot said:
    Please tell me @dancingdarwin, is this paired with Cyton or Ganglion?

    Works with both!

Sign In or Register to comment.

© Vanilla Keystone Theme 2026