1 Hz periodic noise peaks from Ganglion board [Mac with native bluetooth]
Hi! We're students making a final project with EMG signals for our university and we're using a Ganglion board that the university gave us to do it. Until now we were using only the channel1 for testing purposes and everything went ok but now we are trying to use all 4 channels to amplify our muscle signal but we discovered that channel 2 and 3 have periodic noise peaks with and without the electrode cables connected to it. Channel 1 and 4 seems to work fine for now. It seems that the noise peaks are time synched with some packets lost (we saw 2 packet loses for each noise peak involving channel 2 and 3). We searched in the OpenBCI page and forum for answers but we couldn't solve the problem. The only big issue that we think could be the problem is that we are using the native bluetooth option because we don't have the BLE dongle that is mentioned in the official page, could it be that the native bluetooth connection with the Ganglion board is causing these big periodic noises in channel 2 and 3? We also used different computers and operating systems, we updated the software version to the latest (3.0.2) and always used the last version of the GUI.
Here there is a video of the noises we're facing with, the board has no cables connected to ir, only the battery: https://drive.google.com/file/d/1I_bYgbaa_-fr26ljIqFEcgTEda7HCiZV/view?usp=sharing
The initial setup is this:
Comments
Hi Katuto,
I suggest you email (contact at openbci.com), which is customer support and ask if they have any insights.
Normally you cannot infer anything from channels that are free floating / unconnected. The EMF Electromagnetic Field noise in the room can couple into such floating channels and produce spurious results. However you say that the noise is also present when attached to your subject. So that is a valid point. One thing to try is to swap out the cables / connectors / electrodes to see if the situation changes.
Is this a new purchase or older? Has it EVER worked correctly?
The 'native Bluetooth' should normally work fine. But it's possible there could be issues with your specific model of Mac and macOS. State these on your customer support request.
You could actually obtain easily the BLED112 dongle there in Argentina,
https://ar.mouser.com/ProductDetail/Silicon-Labs/BLED112-V1C?qs=8HqIXBaaO6zjZ6K0tFUm5w==
So might be worth trying with that to see if any changes.
William
Thank you for the fast reply, we will reach OpenBCI by email to see if they have another guess on this. As far as we know, we think that these periodic noises is purely a board failure or a connection failure (guessing this by the packet loses sync with the noise peaks) because we tried with different cables and electrodes combinations and it's always channel 2 and 3 that have this issue (1 and 4 work just fine). The board it's not ours as I mentioned, it's from our university but they gave it to us closed and it seemed to be new and unused. We just bought the official OpenBCI dongle from the shop and we hope to get it soon via FedEx in Argentina to see if this could be the issue (we bought many dongles here months before but we always had compatibility errors with Mac so we're trying with the official one now). The thing is that now that you are telling us that the native bluetooth should work fine I guess the probability of the board being the problem is higher. Until now we were discovering the GUI features and just working with the first channel (everything was ok until this point) so we can't know for sure if the error is old or recent, the board from outside seems fine and it never had any hits or broken things. The macOS version that we are using theoretically doesn't have any trouble, and for the packet loss problems in Ganglion they only say this
In all OpenBCI API, troubleshooting and guides it says that the dongle is a MUST have and that there should be no problem with it, also everybody seems to use the dongle with the ganglion board so it's hard to find someone with the same problem that we're facing. We're hoping that the problem is only a connection problem and it will be solved with the dongle... Anyways, thank you very much and if you ever find something or someone that had a similar problem with ganglion please let us now.
If you are seeing packet loss with the native bluetooth, that is a clear red flag. One common strategy with the dongle is to put it on a usb extension cord to get it up off the table or bench you are working on. Some people drape the end of the extension cable (with dongle) over the top of a nearby monitor to get it higher in the air.
As you can see in the end of the video I shared (https://drive.google.com/file/d/1I_bYgbaa_-fr26ljIqFEcgTEda7HCiZV/view?usp=sharing ) there is a 1% packet loss detected that matches with the peaks in channels 2 and 3. The red flag is because there is something wrong with our Ganglion board or is it maybe that the native bluetooth connection is not working well? We will try that strategy that you're mentioning once we get the dongle, thanks for the advise. Just let me ask you why should we put the dongle higher in the air? Isn't it best to keep it the closer as possible to the board?
It's not necessary to position the dongle directly next to the Ganglion mainboard. Some tables or cabinets are metallic and tend to block radio signals. Especially if the dongle is close to the metallic surface. The suggestion of draping the cable over the monitor gets it off any metallic surfaces / objects, and more in a direct line of sight to the Ganglion.
The other tip I think already mentioned, is that other Bluetooh or wireless devices in the vicinity may be interfering / causing the packet loss. So you may experiment with trying other locations, rooms.
@katuto03 There is a similar problem with our Ganglion and periodic noise as seen here. We are using Linux with the BLED 112 Dongle and have tried all versions of OpenBCI GUI without success. Have you managed to solve your problem?
Hi Koutras,
What is the channel 4 electrode connected to, is this EEG? Where on the body? Where is the REF reference? What electrodes? Is it possible that you have a large 'DC offset' potential on that electrode for some reason, and this is confusing the Ganglion compression algorithm? What happens when you run the example / tutorials? Do any other modalities work: EMG, ECG, EEG?
https://docs.openbci.com/GettingStarted/Boards/GanglionGS/
Also, please email customer support, (contact at openbci.com) and mention the noise spikes you are seeing at 1 second (1 Hz) intervals. Are you running the new Ganglion firmware, or old? The spikes might imply that the GUI is confused with the firmware you currently have and the GUI is mis-interpreting the radio data packets from the Ganglion. BUT, if your channel 4 input signal is wonky, it could also cause this. The newer firmware handles larger amplitude inputs better.
https://openbci.com/forum/index.php?p=/discussion/3721/ganglion-firmware-upgrade
William
Hi William, thanks for the reply! In channel 4, I connected an electrode to Fp1. REF is A1 and D_G is A2 on both ears. I have used Ag electrodes with Ten20 and as it is seen by the video, the impedance is good. The exact same connection has been used prior and after with the OpenBCI Cyton, and it works perfectly. I remember that Ganglion used to record biosignals (EMG and EEG) without problems some time ago, but I can't remember if something has been altered since. My Ganglion is old, so no OTA update is possible. I was planning on upgrading to firmware 3 (from 2.0), but I keep postponing getting the FTDI breakout board! Why could I have a large DC offset? Any thoughts?
Koutras, hi. Hmm, I still recommend you email Customer Support for more insights. Have you tried any OS other than Linux? I am cc-ing Philip Pitts here, the developer of the new V3 Ganglion firmware. @philip_pitts and Richard @retiutut (GUI dev.)
This is just my speculation, but there may be some unusual bug in the Linux version of the GUI, that is mis-interpreting what version of firmware you have installed on the Ganglion. In other words it THINKS you have V3 installed but you are really just running the original V1. Thus when the GUI goes to decode the radio packets, it gets confused and they instead look like 1 Hz noise bursts.
To mention @katuto03 's post at the top of this thread, in his case that is a known issue: that a Mac using native Bluetooth has a related type of confusion when the new V3 firmware is used. The GUI in that case does not detect the V3 firmware and interprets the packets with V1 algorithm. A temporary solution is to just use the BLED112 dongle with the Mac. But in your case you are already using the dongle. Have you tried the GUI with Windows or Mac?
Best regards, William
Will do that in a couple of days when I return to the lab and get back to you. I'm also thinking about using a USB extender, test it in other PCs (with Linux) and of course, check it in a Windows machine, or/and in a different place in the lab (in case there are any interferences). Finally, I want to check the packages for any losses as well. All that until the FTDI breakoutboard arrives and install v3 of firmware.
Koutras, hi. The exact repetition of the 'noise' bursts at 1 Hz intervals, and their appearance, tends to rule out the 'local EMF interference' hypothesis.
After investigating the periodic noise in my OpenBCI Ganglion recordings, I've discovered the cause: electromagnetic interference from my WiFi-enabled (TP-Link Tapo L510) LED bulbs (which I had forgotten entirely about !!!).
These are my key findings:
1. When the Ganglion is placed near these smart bulbs, significant interference appears in the recordings
2. The interference persists even when the bulbs are turned off (because the WiFi circuitry remains active)
3. Simply moving the Ganglion away from the light fixtures dramatically improves recording quality (no noise)
For those experiencing similar issues, I'm planning to build a selective "Faraday cage" to house both the Ganglion and BLED112 dongle, with a USB extension cable running to the computer. I'll use 3D printing for the structure and add conductive material like copper tape for shielding. Well, I could just replace the bulbs, but, why not?
This appears to be a different issue from what @wjcroft suggested about firmware confusion (my Ganglion uses version 2, but I'm still planning to upgrade to v3), as the problem clearly correlates with physical proximity to the WiFi LED fixtures.
Has anyone else experienced EMI issues with smart home devices that are affecting their OpenBCI recordings?