You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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, but0xA0
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
bothPCKT_START (0xA0)
andOPENBCI_BOP ('A')
are defined, althoughPCKT_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?
The text was updated successfully, but these errors were encountered: