packets are 31 bytes over the air, then dongle adds header/footer
Shouldn't this be 33 bytes instead? or the header and footer are implicit?
streamingData
Device radio expects to get 31 bytes in each data packet from the uC
After 1 second of no transmission, or not getting 31 bytes in time, Device and Host will revert to!streamingData mode
Command characters can be sent from PC following timing protocol above
Comments
Joel, so what you are saying is that our OpenBCI packets are ALWAYS split across two radio packets. Didn't realize that. That likely accounts for the jittery-ness of the plots that @P300_MAN made of the arrival times,
http://openbci.com/forum/index.php?p=/discussion/comment/915/#Comment_915
William
Specifically, after initiating the binary stream I see some header bytes that do not belong to the header of a packet. Thus far I have implemented a pretty dumb serial stream decoder that finds the header byte, reads 32, and then checks the sequence number and footer. This works well enough except for a couple hiccups during initialization of the binary stream.
What sort of noise might be coming over the line after writing a stop-start or reset sequence to the device? Could it be that the uC sends it's last 31 byte packet to the dongle, and the dongle does not add the header/footer bytes before sending the packet to the serial port?
Given this
packet stream, where "s" is written to the uC while P3 is mid-assembly,
should we expect a partial p3, no p3 or a full p3 to show up in the
serial device? If partial or full, then before or after writing "b"?
https://github.com/ChrisVeigl/BrainBay/blob/master/src/ob_eeg.cpp
For instance:
96
97
98
99
"s"
"b"
100
105
Joel @biomurph might comment further, but my guess is that this is just evidence of a partial packet (100) being in the pipeline as the stream is stopped. Then that pops out when restarted.
The skip of 4 packets, again, could be considered normal if there are some internal buffers being cleared or reinitialized somewhere in the pipeline in that s/b transition. Also, the state machine looks for an END / START sequence (0xC0 followed by 0xA0) if it ever loses sync. So that may account for an extra packet loss.
I would say this kind of minor packet loss at transitions is to be expected. In your code you may want to make available to the user interface some indication of how many sync loss events have occurred (as Brainbay and the ob_eeg.cpp code does.) As long as this is constant, or rarely changing, you are fine.
William
Kevin, one additional step you could do just as you are about to send the 'b', is to clear the state machine 'readstate' variable (or set it to '1' if we assume the new serial stream will immediately begin with a START code.) The BrainBay state machine function is at line 750 here.
With the state cleared or initialized, then any previous partial packet that had been assembled will be discarded. I still do not think this explains the packet number 100 you saw. Since the restarted serial flow would not have matched up precisely with the END byte expected. Anyway, it's one more tweek you could apply.
I would also agree with Joel as far as the number of packets lost on stop/start transitions, when I do this with Brainbay I see the sync loss counter increment by 2 usually. Occasionally by 1. This corresponds with the way the state machine re-syncs if sync is lost. And I don't currently reset the state before sending 'b'. I should give that a try.
Joel, on a 'b', does the packet counter always start off with known sequence number? If so then an additional tweek to the state machine (initializing expected sequence # before 'b' sent) would eliminate that first packet not matching what is 'expected'.
William