Fix ganglion firmware v2 packet ordering

[philippitts]

There was a problem with the packet ordering for the Ganglion firmware v2 decompression. In this firmware, a raw packet is sent every 100Hz to "reset" the delta compression. The previous implementation wrote this raw packet in the wrong order and left the sample package where it should have been unchanged. This didn't change the data stream much (it just wrote the same sample twice), but it would cause the same package index to be written twice. This is an issue for downstream clients that use the package index to check if samples have been lost over the bluetooth connection.

[philippitts]

Firmware v3 with native BLE running a 12Hz 4mV sine wave

Firmware v3 with native BLE running impedance check (hooked up to signal generator)

Firmware v3 with dongle running a 12Hz 4mV sine wave

Firmware v3 with dongle running impedance check (hooked up to signal generator)

Firmware v2 with native BLE running a 3Hz 1mV sine wave

Firmware v2 with native BLE running impedance check (hooked up to signal generator)

Firmware v2 with dongle running a 3Hz 1mV sine wave

Firmware v2 with dongle running impedance check (hooked up to signal generator)

Firmware v2 with dongle running a 3Hz 1mV sine wave on the OpenBCI GUI v5.2.1 (for comparison)

[Andrey1994]

actually, in openbci gui if I remember correctly we took into account that package ids are duplicated. At least it was the case for old fw, is it changed now?

[philippitts]

actually, in openbci gui if I remember correctly we took into account that package ids are duplicated. At least it was the case for old fw, is it changed now?

I noticed that the GUI would report 200 lost packets about every second (which corresponds with the frequency of sending the raw packet). I assumed that it was missing an index and calculating that it had lost full trip around the buffer (200 samples) because of an indexing problem.