This isn't an issue, just a question. Not sure if this is the place to post it but anyway ---
Does anybody know - was there any particular rationale for using 'A' (0x41) as the packet header for streaming from PIC32 to RFDuino, but 0xA0 for streaming from RFDuino to PC?
The OpenBCI_Radios repo seems to cater for this difference of headers when relaying packets to the computer. However, if one connects a USB-serial bridge directly to the PIC microcontroller's serial lines, communication with the OpenBCI GUI or Python libraries is no longer possible, because the headers sent by the PIC are not what the computer expects.
In OpenBCI_32bit_Library_Definitions.h both PCKT_START (0xA0) and OPENBCI_BOP ('A') are defined, although PCKT_START is never actually used in the library.
My question is: is this usage just a carry-over from some miscommunication between PIC firmware contributors and Radio firmware contributors (maybe confusing "A" with "0xA0"?), or is there some special purpose?
This isn't an issue, just a question. Not sure if this is the place to post it but anyway ---
Does anybody know - was there any particular rationale for using 'A' (
0x41) as the packet header for streaming from PIC32 to RFDuino, but0xA0for streaming from RFDuino to PC? The OpenBCI_Radios repo seems to cater for this difference of headers when relaying packets to the computer. However, if one connects a USB-serial bridge directly to the PIC microcontroller's serial lines, communication with the OpenBCI GUI or Python libraries is no longer possible, because the headers sent by the PIC are not what the computer expects.In
OpenBCI_32bit_Library_Definitions.hbothPCKT_START (0xA0)andOPENBCI_BOP ('A')are defined, althoughPCKT_STARTis never actually used in the library.My question is: is this usage just a carry-over from some miscommunication between PIC firmware contributors and Radio firmware contributors (maybe confusing "A" with "0xA0"?), or is there some special purpose?