ETH Zurich clone of 8-bit OpenBCI, for wearable ECG

joe50joe50 Switzerland
edited November 2016 in Build-it-yourself
[original thread title: wearable ECG prototype - wireless connection?! ]

this project is based at ETH Zurich Laboratory of Bioelectronics and Biosensors,
http://www.lbb.ethz.ch/

Hello everybody,

For our project we want to develop a wearable ECG prototype to show the performance of our newly developed electrodes. Therefore we want to perform sports activities like running, cycling or even swimming with the device. Our goal would it be to perform a training session on the PCB (SD) for example a swimming training and after coming out of the water sending the data to the software (or any software) and analyze it. We can't have permanent contact to a openBCI software laptop since we will be moving away (cycling tour) therefore it would be optimal to just record data on the SD and upload it afterwards.

As up to right now, we have been using a 8bit BCI board (the deprecated version), and always had a laptop with us. So the board was connected to the dongle and the data was streamed to the openBCI software. Optionally also saved to the SD card.

We now have a customized PCB design based on the openBCI design. The thing is:

1. Can our board or a openBCI board in general connect to the software without the dongle? the communication chip of openBCI has RFDigital RFD22301 and a BLE connection. Is this sufficient to connect to a bluetooth capable system? Laptop, Smartphone. Idea: Perform sports task while wearing our prototype. Afterwards, when in range of laptop, upload data to the laptop and process it.

2. Since we have to mold our PCB into a polymer to make it waterproof we won't really be able to access the board afterwards. Is there any way to send the data which is saved on the SD card to the laptop after a training session, without physically interacting with the SD card/board? It would be awesome to start the board through the software (start recording) then move around for some time (maybe a cycling tour of 2hours) then come back to the laptop and upload the data from the stored SD card without having to put the SD card into a laptop.

Thank you guys so much for your help! Greetings Simon
«1

Comments

  • wjcroftwjcroft Mount Shasta, CA
    Simon or Joe, hi.

    For #1, see,

    http://openbci.com/forum/index.php?p=/discussion/691/openbci-alphawave-bluetooth-le-enabled-no-dongle

    As far as both #2 and #1 goes, you'll be making changes to the firmware. So you can basically do whatever you want. Note however that the BLE link speed is much less than through the dongle. That is why Hassan only sends some derived measurements (alpha band power) through the BLE link, rather than the raw data.

    With your polymer coating, are you making that flexible so that the buttons can be pressed on your mainboard? If so then some kind of multiple button press sequence could drive your different modes.

    Regards,

    William

  • joe50joe50 Switzerland
    Hi @wjcroft ! the forum deleted my whole comment since I wasn't logged in before entering. Awesome feature!

    Anyway once again: thanks so much for your answer. As I understood it is possible to change the firmware on the board, in our case we even have to, since there is nothing on it yet. but based on the openBCI firmware we can make changes. There was a talk of a Bluetooth "Gazelle" mode for fastest possible raw data transmission. Can you elaborate what that is? http://docs.openbci.com/software/02-OpenBCI_Streaming_Data_Format here I found information on how to change the data format, so this might be useful.

    My question is more: Is it possible to put a SD card in the board, mold it into our polymer and start it through the software (when we were able to connect the hardware to the software through the firmware) and record a training session on the SD. Then afterwards we sit down and send the data from the SD card to the laptop and process it there. If this is possible it would be perfect for us since we didn't have to access to board everytime. and if this is possible it also doesn't matter if we still need a dongle since we can then do the transmission afterwards. Do you have any idea about that? I thinks it's time to look for a guy who can do the firmware programming for us!

    I uploaded our board design and some additional information here:
    http://www.file-upload.net/download-12059204/OpenBCI_8bit.pdf.html
    http://www.file-upload.net/download-12059205/OpenBCI_8bit_3D.pdf.html

    Here you can see how our coating looks like: http://www.file-upload.net/download-12059207/photo_2016-11-01_09-43-23.jpg.html

    it is minimally flexible, but as you can see on our PCB design the button is quite accessable. we can make the layer thin so it is still pressable. Thanks for the suggestion for the different modes. Any input on what these might be?

    Thanks so much William

    Simon
  • joe50joe50 Switzerland
    Hi William @wjcroft!

    Another thing: How do I get the openBCI firmware on our board? And how can I change it?

    I am Medical Technology major so I don't really have a background in any of that. But always willing to learn! I am doing the prototyping of the device currently.

    Thanks so much

    Simon
  • wjcroftwjcroft Mount Shasta, CA
    Simon, hi.

    re: Gazelle (GZLL) vs BLE (Bluetooth Low Energy). These are two completely different modes the RFduinos can communicate in. The OpenBCI firmware uses GZLL to achieve maximum possible data transmission rate. In addition, the RFduino devs made a custom firmware library for OpenBCI that avoids the delays of channel switching. This is why the firmware requires / uses a channel selection. Either specified in a #define with the V1 firmware; or dynamically via control commands in the V2 firmware. BLE is much slower, as Hassan's AlphaWave example makes clear.

    re: your custom SD card firmware. You can make this operate as you describe, since you have total control of the firmware you upload.

    re: your links to designs / photos. Sorry, those did not work for me. Whenever I tried downloading, it sent me an 'exe' file, which I would advise never executing from a download site. Too much potential for viruses and such. Consider Google Drive or some other sharing site that does not use exe's.  Anyway nice going on your project.

    re: I'm not sure how the initial firmware is loaded. It's done with some type of USB arduino / upload card. This might be covered in some of the online documents. Once the OpenBCI firmware loader is in place on the board, then uploads occur using the dongle and radio upload procedure described in docs.openbci.com .

    Regards,

    William

  • ogtoadyogtoady
    @joe50
    In regards to loading the firmware, you'll need to burn the atmega bootloader using another Arduino. This sort of a guide should get you started: https://www.arduino.cc/en/Tutorial/ArduinoToBreadboard
    If you have any experience with arduino/microprocessors - the upload process is very similar to that.

    Once you get a bootloader on the Atmega, follow this tutorial on how to get the code on there. 
    In all honesty, if both those guides are over your head, you might need to take a step back and learn some basic microcontroller programming/breadboarding first. 
    You seem to be diving into a very deep end quite quickly, which is fine when you have a step by step guide, though when something goes wrong you'll want to have a strong foundation to be able to debug it, especially if this is a product you're trying to sell.  

    Not sure how much experience you have with PCB design though there's a lot more to it than 'make sure it fits on the board' sort of designing. There's carful consideration with how rails and components interact with each other, as well as ground planes decoupling power supplies etc. 

    My last suggestion is if you're building a prototype with little hardware/software knowledge, base it on a current revision. The 8bit board, as you said is deprecated. There's a lot more support and software being developed for the 32bit board, and no downsides to it as apposed to the 8bit. The design is more refined, and you'll have a lot less trouble with modifying the updated firmware to do custom tasks (such as save data to SD card, then upload as a batch once connected to the computer) 

    Goodluck

  • joe50joe50 Switzerland
    https://drive.google.com/drive/folders/0B_mjfJaj7fvvR3pzVlo0b09VSjg

    @wjcroft does this link help you more? The problem I have right now is that I have a board where I want to get firmware on it, but I need to do it physically since the wireless communication on the board doesn't work yet, since there is no firmware on it (kind of a chicken egg problem). Our PCB designer can load the firmware physically on the board with an arduino board, but he needs the firmware (also in final format and not compiled) to load it onto the board. I cannot find the firmware to give it to him however.

    @ogtoady, thanks for your input! We have a PCB designer who designed the board for us based on the old 8bit version (since that was the one we were using before). You can find the plans on the google drive link I posted above. I do actually have little to no knowledge in the field, this is why all of that is very frustrating for me. All I want is that the board can communicate via BLE with the laptop. But therefore I need the 8bit firmware on the board but I can't find it anywhere.

    Greetings
  • ogtoadyogtoady
    @joe50 The firmware that decides whether its BLE or Gazelle is the RFDuino radio firmware, not the Microcontroller. 

  • joe50joe50 Switzerland
    Okay thanks @ogtoady! The RFDuino firmware is also available on the github-openBCI as I have seen. Can I just upload the firmware on the board to connect to it?
  • ogtoadyogtoady
    @joe50
  • joe50joe50 Switzerland
    @ogtoady
    Thanks. I've read through that. this leads me to the github https://github.com/OpenBCI/OpenBCI_8bit page from openBCI. This firmware is apparently in a compiled format which I cannot physically load on the microprocessor through a programming board. I would need a decompiled version (the board designer says preferably .hex).

    The tutorial works with the dongle (which we don't have yet) and a board which already has a activated RFDuino module. I hope I can somehow explain the situation I am in. Anyway, thanks so much for the help!
  • wjcroftwjcroft Mount Shasta, CA
    Mentioning Joel @biomurph, he might have some tips. Joel, Simon (Joe50) has built a clone of the 8 bit board, to be used in a custom ECG application. He desires to load (without the radio link or dongle) the device RFduino and mainboard uC firmware. I believe he said the dongle will be ready in a couple weeks. My impression is that he's going to have to wait until then. And then follow the procedure outlined in docs.openbci.com, to upload the dongle RFduino, then the mainboard RFduino using the wires and caps with the dongle RFduino.

    But he also needs to get the bootloader onto the mainboard uC. Once the 2 RFduinos and uC are ready he should be able to upload over the radio link as documented.

  • joe50joe50 Switzerland
    @wjcroft @biomurph, thanks for assisting me! Yes wjcroft you got the situation right

    The dongle will be here in 5 days (I ordered it from the openBCI shop). All the tutorials work with the dongle and it is probably going to be way easier to do it.

    then upload the dongle radio RFDuino firmware, then through that the mainboard RFDuino?

    What is confusing me is: How can I connect the soon-coming dongle(which already has firmware on it) with the clone board's RFDuino when there is no firmware on the board yet? Don't I physically HAVE to upload firmware to the clone board anyway?

    thanks so much for helping me out, I'm getting more and more desperate!
  • wjcroftwjcroft Mount Shasta, CA
    As @ogtoady mentioned previously, the mainboard RFduino firmware upload is covered on this page. Scroll down until you see it.


    Your dongle will already have it's firmware installed, so you are set. Note that the channel numbers for the dongle and mainboard RFduinos must match.

    I'm still unclear on how the 8-bit uC bootloader firmware gets installed on the mainboard. Joel may comment here. Also note that Joel is super way way busy with the Kickstarter fulfillment so doesnt get on the forum here every day.

  • joe50joe50 Switzerland
    Hello Guys, I hope I am not too late to the party:

    I am not able to change the RFduinoGZLL.channel = 6 (IN THE 8BIT RFDUINO DEVICE CODE) since when compiling the same error message shows up every time:

    Arduino: 1.6.13 (Windows 10), Board: "RFduino"

    Warning: platform.txt from core 'RFduino Boards' contains deprecated recipe.c.combine.pattern="{compiler.path}{compiler.c.elf.cmd}" {compiler.c.elf.flags} -mcpu={build.mcu} {build.extra_flags} "-T{build.variant.path}/{build.ldscript}" "-Wl,-Map,{build.path}/{build.project_name}.map" -Wl,--cref -o "{build.path}/{build.project_name}.elf" "-L{build.path}" -Wl,--warn-common -Wl,--warn-section-align -Wl,--start-group "{build.path}/syscalls.c.o" {object_files} "{build.variant.path}/{build.variant_system_lib}" "{build.variant.path}/libRFduino.a" "{build.variant.path}/libRFduinoBLE.a" "{build.variant.path}/libRFduinoGZLL.a" "{build.path}/{archive_file}" -Wl,--end-group, automatically converted to recipe.c.combine.pattern="{compiler.path}{compiler.c.elf.cmd}" {compiler.c.elf.flags} -mcpu={build.mcu} {build.extra_flags} "-T{build.variant.path}/{build.ldscript}" "-Wl,-Map,{build.path}/{build.project_name}.map" -Wl,--cref -o "{build.path}/{build.project_name}.elf" "-L{build.path}" -Wl,--warn-common -Wl,--warn-section-align -Wl,--start-group "{build.path}/core/syscalls.c.o" {object_files} "{build.variant.path}/{build.variant_system_lib}" "{build.variant.path}/libRFduino.a" "{build.variant.path}/libRFduinoBLE.a" "{build.variant.path}/libRFduinoGZLL.a" "{build.path}/{archive_file}" -Wl,--end-group. Consider upgrading this core.
    Warning: platform.txt from core 'RFduino Boards' contains deprecated recipe.ar.pattern="{compiler.path}{compiler.ar.cmd}" {compiler.ar.flags} "{build.path}/{archive_file}" "{object_file}", automatically converted to recipe.ar.pattern="{compiler.path}{compiler.ar.cmd}" {compiler.ar.flags} "{archive_file_path}" "{object_file}". Consider upgrading this core.
    C:\Users\Simon\AppData\Local\Temp\arduino_modified_sketch_974319\RadioDevice8bit.ino: In function 'void setup()':

    RadioDevice8bit:77: error: 'class RFduinoGZLLClass' has no member named 'channel'

       RFduinoGZLL.channel = 6;     // use channels 2-25. 1 is same as 0 and 0-8 in normal GZLL library

                   ^

    exit status 1
    'class RFduinoGZLLClass' has no member named 'channel'

    This report would have more information with
    "Show verbose output during compilation"
    option enabled in File -> Preferences.

    I tried all the channels on the dongle, but I am not able to connect the two. The RFDuino DEVICE cannot be programmed with a specific channel. I would really appreciate any help, because I am not able to connect my board to the dongle. I also tried the radio.flashNonVolatileMemory()
    didn't work either unfortunately.

    @pushtheworld @wjcroft
  • pushtheworldpushtheworld
    edited November 2016
    @joe50 this [original thread on V2 firmware] is not for 8bit boards. Please flash the original firmware back onto the boards.
  • pushtheworldpushtheworld
    @joe50 also you are using the wrong arduino version, please follow the tutorials and use the correct arduino version to flash RFduino.
  • joe50joe50 Switzerland
    Hi @pushtheworld . Indeed it worked all perfectly with the 1.5.4 version. We had a total mess with the libraries and additionally with the compiler, but with the 1.5.4 it all worked perfectly.

    I am able to program the channels for both the board and the dongle (we are using a 8bit clone, not the original board because of size reasons) ---- http://i.imgur.com/Axg72tR.png

    Unfortunately I am still not able to connect the board to the dongle in the openBCI_GUI. I also tried to troubleshoot with the tutorial steps of the "how to get started w/ openBCI" but it didn't work. Next step will be to test the current with an oscilloscop. Do you have any idea why we might have trouble to connect? After the:

    Initializing communication w/ your OpenBCI board

    there always comes the error message no connection..

    Thanks for your answer!


  • pushtheworldpushtheworld
    @joe50 Could you please specify exactly what firmware you have uploaded by providing links to their source code?

    V1 Radio does NOT work with V2 Pic because of the removal of the burger protocol. 
  • joe50joe50 Switzerland
    @pushtheworld

    https://github.com/OpenBCI/OpenBCI_Radios/blob/master/examples/RadioDevice8bit/RadioDevice8bit.ino this is the RFDuino DEVICE code we uploaded to our clone

    https://github.com/OpenBCI/OpenBCI_RFduino/tree/master/RFduino this is the file we used as "RFDuino Boards" in the Arduino IDE

    The dongle we use is about 4 weeks old and is updated with the newest software and comes on channel 3 out of the lab they told me at openBCI customer care.

    https://www.dropbox.com/sh/4o8tsd2yegp8fu9/AAAwgYCoKNkG_zvBtni-pvXVa?dl=0 these are the schematics of our clone board if you are interested.
  • wjcroftwjcroft Mount Shasta, CA
    edited November 2016
    @joe50, hi.

    I moved your comments about your 8 bit clone board uploading, back to your original thread on questions regarding setup of your one-of-a-kind hardware. Please post any future comments regarding bootstrapping your unique hardware on this thread. So as to avoid confusion with the users of the stock OpenBCI hardware.

    Best regards,

    William

  • wjcroftwjcroft Mount Shasta, CA
    It sounds to me that you will need to reload your dongle with the original V1 dongle code designed to work with the 8 bit mainboard. Likewise for the 'device' RFduino on your clone mainboard.

  • joe50joe50 Switzerland
    Hi @wjcroft @pushtheworld First of all thanks for all the support you guys are showing me !

     It seems that the firmwares don't really match. But I got both versions from here https://github.com/OpenBCI/OpenBCI_Radios/tree/master/examples

    Dongle: I followed the tutorial on http://docs.openbci.com/tutorials/03-Upload_Code_to_OpenBCI_Dongle and overwrote it according to the Firmware 2.x.x. BUT if I follow the tutorial for firmware Version 1.x.x. it tells me I should use HOST 8bit Code from the RFDuino libraries, what I am actually doing. So didn't I overwrite the Dongle with 1.x.x. Firmware already? If I am getting confused, could you link me to the V1 firmware code for the dongle? Much appreciated! RadioHost8bit.ino file from

    Board: I am again following the procedure on http://docs.openbci.com/tutorials/03-Upload_Code_to_OpenBCI_Dongle under Firmware 2.x.x. but since I cannot use a 32bit file I end up with the "original" OpenBCI_8bit_Device.ino file which is linked in the 1.x.x. Firmware..

    summary: Didn't I already upload both the V1 to the dongle (with the channel setting) and to the board? Host8bit firmware and openBCI_8bit_Device.ino should match right? I am using the same 8bitHost/Device Version from the same openBCI_Radios package of github.

    Thanks for helping me clarifying my chaos!
  • joe50joe50 Switzerland
    So I just checked the 8bitHost firmware I am using and it DOES indeed use the burger protocol!

    ......
    if(serialIndex[0] == 2){ // single byte messages from uC are special we need to burgerize them

    testSerialByte(serialBuffer[0][1]); // could be command to streamData, go sniff it

    serialBuffer[0][2] = serialBuffer[0][1]; // move the command byte into patty position

    serialBuffer[0][1] = serialBuffer[0][3] = '+'; // put the buns around the patty
    serialIndex[0] = 4; // now we're sending the burger protocol
    ......

    The question then will be: Where do I find a unburgerized firmware for my dongle? Or vice versa: How does the burger protocol look like in the device code? Can I update my device code with the burger protocol?
  • joe50joe50 Switzerland
    Hi again:

    I found this line in the 8bit_DEVICE code: 
      Single byte commands sent from the PC are prepared by the Host with '+' before and after.
      This is to avoid letting the uC get a 'ghost' command during streamData mode

    This means, the burger protocol is accepted right? So both the dongle and the board should communicate with burger protocol?
  • joe50joe50 Switzerland
    Hi again.. sorry for spaming.. @wjcroft @pushtheworld

    you can ignore all messages before that one here!!!

    I was able to downgrade to version 1.0.0 according to this link: https://github.com/OpenBCI/OpenBCI_Radios/tree/maint/1.0.0 I installed both the device and the host firmware from this repo to my dongle and my board. The upload was successful for both. I was using the https://github.com/OpenBCI/OpenBCI_RFduino/tree/master/RFduino repo for the board information.

    http://i.imgur.com/OEPVsrL.png - arduino status

    however I still get the same error message when trying to connect to openBCI_GUI: http://i.imgur.com/ryu0bEw.png

    I don't know what else to try.. I will sit together with a electrical engineer this afternoon with an oscilloscop to check if the current on the board is right. Any advice welcome!!
  • pushtheworldpushtheworld
    What firmware are you running on the PIC 32?
  • wjcroftwjcroft Mount Shasta, CA
    AJ, hi. Simon's clone board is using the Atmega processor, not PIC. Since he intended to clone the 8 bit board.

    http://openbci.com/forum/index.php?p=/discussion/comment/4790/#Comment_4790

    I assume he followed the suggestions on the comment above to do his initial firmware load.

  • joe50joe50 Switzerland
     @pushtheworld we are using an ATmega since we use the 8bit board. libraries and .ino files used from this github repo: https://github.com/OpenBCI/OpenBCI_8bit
  • joe50joe50 Switzerland
    @pushtheworld @wjcroft I am currently re-uploading the ATmega firmware (based on the link above). will report back how it works! thanks for tuning in.
  • joe50joe50 Switzerland
    @pushtheworld @wjcroft we re-uploaded the firmware to the ATmega with avrdude and a avr dragon. Upload worked, still no connection between the RFDuino modules.. we checked between GND and DVDD pin on the RFduino and it has 2.99V like it's supposed (I guess). If we have the right firmware now it should be working. Any idea on your side?
Sign In or Register to comment.

© Vanilla Keystone Theme 2025