v2 firmware and GUI stability

Comments

• wjcroft Mount Shasta, CA

  October 2016

  Including AJ Keller @pushtheworld

  
  

  My understanding is that the data stream output from the V2 firmware is the same as V1 firmware. Thus works with both V1 and V2 GUIs. The V2 firmware is shipping on all new boards sent out from fulfillment. 

  
  

  William

  
  
• pushtheworld

  November 2016

  Hey @tek (thanks for mention @wjcroft)

  
  But I'm a bit unsure, is this code reasonably stable? 

  Yes it seems to be pretty stable. I've been using it and am getting good data and such.
  

  
  

  My biggest worry is bricking the board, as that would be a rather expensive mistake...

  This is impossible and you can always install the older versions of the firmware if any problem arises.

  
  

  Furthermore, is the GUI usable with this version since, as I understand it, the protocol has changed. I guess OpenBCI_GUI_2.0 is used for this?

  The old GUI is totally usable. Don't use OpenBCI_GUI_2.0 yet, it's still in beta.

  
  I'm also assuming the repo OpenBCI_32bit will be deprecated and shouldn't be used if I'm going with the new firmware, is this correct?

  It should be deprecated, see https://github.com/OpenBCI/OpenBCI_32bit_Library/tree/master/examples for examples of different configurations. 
  
  On a related note, has anyone had any success with setting up an (maybe an QEMU based) emulator for the chipKIT system?

  No! If you figure it out, please please tell me how!

  
  

  It would be really nice to develop against that firsthand, but it is probably a lot of work to configure it to emulate the OpenBCI system.

  I use https://github.com/PushTheWorld/PTW-Arduino-Assert to do my automated tests for the system.

  
  

  @tek please check out the upgrade guide located here: https://github.com/OpenBCI/OpenBCI_32bit_Library/blob/master/UPGRADE_GUIDE.md

  Be sure to check out the section called References which has a bunch of useful links and learning resources.
• tek Sweden

  November 2016

  Alright, I'm making some progress!
  I have succesfully changed the firmware now to v2, and written a small python script to collect data.
  But sometimes I get corrupted packets, which might be due to me not upgrading the radios.
  Before I try to reprogram them, I just want to check if someone here knows more...
  
  The
  streaming format is supposed to be the same, but for example, on the
  master branch, in OpenBCI_32bit_Library.cpp:824 it begins all packets
  with an 'A' instead of 0xA0:
  

  Serial0.write('A'); // 0x41
  

  This
  obviously breaks backward compatibility, but if I remove it, I can get
  things to work again. Then it also only writes 32 bytes which seems to
  be good for radio packet alignment. But for some magical reason, the
  streaming packet header '0xA0' is appended too, which I assume must be
  done by the RFduino firmware somehow. This also makes me believe that
  the RFduino firmware might have a misunderstanding with my v2 OpenBCI
  firmware, which causes my packets being corrupted, but I am still
  investigating.
  
  For example, here are one packet that is valid, then directly after follows an invalid packet:
  VALID     id: 86 raw: [86 83 c0 f5 85 2a b0 84 68 25 84 ce 25 83 94 b6 84 2f 50 85 21 ca 84 ba bf 00 00 00 00 00 00 c0]
  INVALID id: c0 raw: [c0 87 84 1e eb 83 fe b1 83 6e a5 84 8a 61 83 b9 40 84 a4 69 82 ed 59 83 8e bd 00 00 00 00 00 c0], expected id:87)
  
  As can be seen, the end marker is read again in the beginning of the following message.
  
  My question is, do the radios know stuff about what's being sent, and do they modify the data being sent?
  
• pushtheworld

  November 2016

  In short, yes, it matters very much with firmware v2. All three micro controllers should be updated.
  
  Please read the tutorial below:
  http://docs.openbci.com/tutorials/04-Updating_Custom_Firmware_to_2.0#updating-and-using-v200-32bit-firmware-sending-data-packets-from-the-pic32-to-the-pc