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 3
also.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.
@DashBarkHuss when you tested the PR, did you use native Bluetooth or the BLED112 dongle? I agree that it looks like the data is still being decoded using the v2 packet scheme rather than the v3 packet scheme. Thanks for testing.
In the meantime, you may be able to revert to the v2 firmware. The v3 firmware fixes a problem with decoding signals that have high variance (e.g. from sensitive ECG). If your project doesn't involve these types of signals, you may be able to revert to that firmware in order to continue your work while we resolve this Mac-related decoding problem.
This is expected, but I agree it's a bit confusing. In this case, the hardware is the Simblee BLE module on the Ganglion, the firmware is the code running that Simblee module, and the software is the code running on the Ganglion.
@philippitts This cycling "noise" happened with the native bluetooth on V3. I tested the PR because I wanted to use the native Bluetooth since I had issues with the Mac dongle. Both V2 and V3 work with the dongle if I add the special adapter people recommended, at least so far for EOG. However, since I am working with some other researchers who all use Macs and we will be using OpenBCI for many projects, we wanted to solve the issue entirely. We thought that the V3 firmware would enable us to use native Bluetooth.
@DashBarkHuss, hi. Philip has acknowledged the issue and is presumably looking into a fix. It may be more complex than initially thought, because Brainflow library is also involved. The PR you tried only patches the GUI.
For the time being, you should be able to use the BLED112 dongle with Macs having only USB-C ports, by using the USB-A to USB-C adapter. This adapter is extremely simple and just routes the 4 wires (2 power and 2 data) from USB-A to appropriate USB-C pins.
Regards,
@wjcroft for more context and for others reading, some USB-a to USB-c adapters didn't work and caused noise, see here. The specific USB-a to USB-c adapter I was recommended did work.
https://www.google.com/search?q=are+all+usb+c+to+usb+a+cables+the+same
The answer seems to be mixed, depending on the luck of the draw. As you found, going with a cable or hub that is not rock bottom priced (thus cheap) may be wise.