Using Native Bluetooth causes 1 second pulses on Ganglion
DashBarkHuss
Chicago
Using the dongle Bluetooth, I got an expected signal
However, when I use the Ganglion native Bluetooth, I get a weird, consistent pulsing signal noise every second.
Before this, I followed the directions for the firmware update which afterward showed my new device info:
Hardware Revision: 1.0.1
Firmware revision: 1.1.0
Software revision: 3.0.1
The images are from my Macbook Pro 2021. However, the issue happens on Dr. Konkoly's 2019 Macbook Pro as well, and she is in a different state, so I don't believe it's related to the environment.
Macbook Pro 2021
Apple M1 Max
OS: 14.6.1 (23G93)
Macbook Pro 16-inch 2019
Intel
Sonoma 14.5
Comments
Mentioning Richard @retiutut, @Andrey1994 Parfenov.
Is it possible the firmware update to V3 firmware failed?
https://github.com/OpenBCI/OpenBCI_Ganglion_Library/releases
https://docs.openbci.com/Ganglion/GanglionProgram/
Suggest emailing Customer Service at (contact at openbci.com). That way a Zendesk ticket tracker will be assigned and an engineer will be assigned to give an answer.
Did you in fact upgrade the firmware on these Ganglions?
I followed the instructions for updating the firmware via bluetooth: https://docs.openbci.com/Ganglion/GanglionProgram/#ganglion-ota-firmware-programming
The nRF Connect App said it was a success. The Software revision string moved from 2 something to 3.0.1. So, I think it worked.
Another possibility is that there is a bug in the Brainflow native-Ganglion device support library routine. And that this routine does not properly adapt to the new packet format. After the firmware was developed by Philip Pitts, he also had to mod the device interface routines to dynamically adapt depending on whether it is talking to old or new firmware.
New info:
I noticed there's a lot of packet loss with the native blue tooth as well.
Please email Customer Service. If the Brainflow native Ganglion driver is misinterpreting the packets (firmware mismatch), then loss will occur.
Ok thanks. I emailed them on Friday. Waiting to hear back.
I’ll keep posting updates here.
Philip Pitts @philippitts might have some insights. I'm pretty sure he modded both the BLED dongle and native Brainflow device code to adapt dynamically to the firmware revision level. The fact that you are using the new firmware with the dongle successfully means that at least for the BLED dongle, that is working fine.
What seems odd to me is that you report:
Which I guess might just be an artifact of the phone app you used to upgrade.
Yea I was a little confused why only the software revision string changed to 3.0.1. I thought the firmware revision string would change to 3.0.1 or something.
Another weird thing is in my console on OpenBCI GUI I'm seeing this:
I would think this should show
version 3also.When I use the BLED112 Dongle the firmware version changes to 3
This is what I'd expect. But I would expect the logs when using native BLE to log version 3 as well, but it's logging version 2.
OK !! Well that pretty much explains the issue. The Brainflow native Ganglion library is miss-interpreting what the firmware revision level is. Once it does that, the data stream will certainly appear like garbage. Which is what you see. Mentioning @philippitts and @Andrey1994 .
Repeating the previous comment, you need to log a ticket with Customer Support so that they can assign an engineer to take a look. Point them at this Forum thread. It sounds like a relatively simple fix to the Brainflow native Ganglion device routine.
https://github.com/brainflow-dev/brainflow/blob/master/src/board_controller/openbci/ganglion_native.cpp
The logic to access the firmware version is clearly present there in the code. So there might be some kind of case that glitches on your particular computer setup.
@retiutut is taking a look and said @wjcroft is on the right track. There is a PR for this fix that's about one year old since OpenBCI has been focusing on Galea. I'm going to test out that PR and see if it fixes things.
@retiutut
Tested the version issue PR on Sonoma 14.6.1 Mac M1
In the PR, the firmware is correctly detected in the logs as version 3; however, it does not fix the cyclical noise.
There's noise every second, and it looks like the 1-second noise coincides with packets being lost.
video demo
Be sure to update your Zendesk ticket.
You're likely packets due to the position of the computer and the device. That's a low enough amount of packet loss for this to be the root cause.
Richard @retiutut, did you watch the full video link she posted? It appears with the PR, the log shows V3 firmware detected, but the time series is still totally wonky. Indicating the V3 Brainflow native Ganglion code is not getting control. @DashBarkHuss labels this as 'noise', but it is not packet loss noise, it is misinterpretation of the V3 packet data values.
Yes, I can see in the video demo that this is definitely software misinterpretation.
Clarified the PR comments noting above observations and tagging @philippitts.
https://github.com/OpenBCI/OpenBCI_GUI/pull/1194
This sounds like a very simple fix, since Phil already did the hard work. Thanks again Phil.
If most of the packet values are being interpreted correctly, why would one every second be misinterpreted?
(I don't know much on this topic and probably don't know what I'm talking about; I'm just curious)
re: packet formats. These changed drastically between V2 and V3 firmware. The decoding function in Brainflow is entirely different between V2 and V3. What appears to be happening is that your V3 firmware packets are being interpreted (incorrectly) by V2 Brainflow function. Even though some part of the stack is correctly seeing the V3 firmware, this fact is not being communicated to the decoding function. Thus data stream looks like complete garbage.