Ganglion testing with a function generator
I am trying to test the ganglion with a function generator. I am using a voltage divider with 12 kOhm and 100 Ohm resistor , which brings the signal from the function generator from 500 mV peak to peak down to a measured 4.5 mV or 4500 uV - I am just using a basic sinewave as input. All filtering is turned off. At 2hz, the ganglion records the signal just fine:
I can increase the freqency to 5 hz and then this happens:
Basically any frequency >4 Hz produces a garbage signal - Now I can confirm with the scope, that the actual signal is still good.
So what is going on here? Is there some low pass filter on the device or active in the software, that I am not aware of?
Comments
Hi Fdarvas,
4500 uV is NOT a normal EEG signal. Typical EEG is below 100 uV. You may be triggering dysfunctional operation of the compression algorithm that Ganglion uses to squeeze samples into the available radio bandwidth.
https://docs.openbci.com/Ganglion/GanglionDataFormat/#binary-format
My suggestion would be to adjust your voltage divider to get lower output voltage swings.
While Ganglion also works with ECG which has millivolt excursions, such ECG may be within the capability of the compression algorithm.
Regards, William
The reason the 2 Hz works, then fails at 5 Hz, is that the compression algorithm is based on rate of change of the signal.
ok, so switched to 68k to 100 ohm voltage divider - same sine output with 500 mV Vpp. So that should produce a 734 uV pp sine wave. Obviously, with this large voltage divider , the signal is kind of noisy - but here is what I get:
2 Hz - looks noisy - but ok
5 Hz - still ok
10 Hz - weird jumps in the voltage now?
20 Hz - all garbage
Either way, 700 uV should be a signal the device should have no trouble with - if the compression algorithm mangles it this badly, how then will this device work at all? It cannot be an amplitude thing?
Also, if it was an amplitude thing, why does the GUI have a range from -10 mV to + 10 mV - after all for the ADC, this shouldnt be a big deal ? So this still does not explain the issue fully.
Again, EEG is in the range below ~100uV. 700uV vastly exceeds that. Your graphs appear to be showing the compression algorithm being stressed.
re: "It cannot be an amplitude thing"
Did you READ the compression page link? The compression algorithm is using delta differentials. It was designed with EEG in mind, but also works for ECG, EMG. The faster and larger the sample to sample changes, the more the compression algorithm has to work.
It's remotely possible your Ganglion could have hardware malfunctions. Has it ever worked correctly for you on EEG tests?
I'm mentioning some other staff who may comment: @Shirley, @joeartuso, @evaesteban, @retiutut
Here is Dr. Felix Darvas' LinkedIn page,
https://www.linkedin.com/in/felix-darvas/
Mentioning @Shirley, @joeartuso. Can you get Scott to comment? I'm not seeing what username he has here.
ECG can be quite large, 500 uv - 5000 uv. So, ok, the device doesn't necessarily need to work for this, but then it is mentioned several times that you can measure ECG with it.
At this point its also wort mentioning that EMG, depending on muscle and electrode placement, can be several hundred uV.
So, ok, the ganglion doesn't work for this either, if I understand the limitations of the compression algorithm correctly?
Going further down with the resistive voltage divider will not work, because the noise in the resistor will become way too big, so I have to figure out a suitable circuit. But I think some testing there would be useful, to see if the device actually faithfully measures a signal below 100 uV.
Or has that been tested & confirmed?
OpenBCI staff will reply here Monday after some testing above and below 100 uV. Many users have had success with the board for ECG and EMG (as well as EEG) with output waveforms looking as expected. So it is possible that either:
Regards,
I dont think there is a hardware glitch - the device records data which looks like the output of the function generator at e.g 2hz.
But its performance at higher frequencies would appear questionable, even when reducing the signal to the 100 uV range.
I think the compression algorithm is the culprit here.
Hi Felix and William, thank you for bringing up this potential Ganglion board glitch.
We scheduled engineer time this week to replicate the issue shown in Felix's screencaps. We'll be in touch about our findings
Would like to add - we can send another Ganglion for you to see if the issue re-occurs. Let us know.
best,
Shirley
That would be great!
The unit I have is pretty old (at least pre-pandemic)...so maybe the firmware has changed?
So to be clear, the test setup with the voltage divider is sub-optimal, because of the noise on the resistor - however, I think, even a noisy test-signal should be replicable on the device and there are these issues - also - in the specs for the ganglion it says:
Resolution = Voltage level / 2^n where n is the bit-level of ADC, but n is never mentioned anywhere else - what is the resolution? Is this a 24 bit ADC? Or 16 bit? What is its input range?
To my knowledge, Ganglion firmware has not changed since 2018. See last Github release:
https://github.com/OpenBCI/OpenBCI_Ganglion_Library/releases/tag/v2.0.1
Resolution = Voltage level / 2^n
n= 24, per the A/D converter MCP3912 specs: http://www.microchip.com/wwwproducts/en/MCP3912
Dear Friends
1) We are also very interested in connecting Ganglion to a Signal Generator. By an amazing coincidence we are doing some experiments as we detected some anomalies that distort the input signal greatly.
First we show the output (after processing the Ganglion Data in IGOR-9 (wavemetrics) when we use a sine-wave of different peak-to-peak voltage. (2 to 6 mV). In this case the output signal is not distorted
if we continue (up to 11 mVolts Vpp) everything seems fine
We can continue until 20mV and everything is fine
But if we do a scan in frequency (from 2 to 7 Hz) we do detect a fierce distortion at 7Hz.
More interestingly if we also plot the INDEX variable (first column of data file from GANGLION) we see that the big saw-tooth like disruption on the signal correlated with the transitions of the INDEX variable (that, as far as we understand .. reflect the structure of data packets)
In the next graph we see the change in the INDEX variable
I hope that these graphs can help to solve this annoying problem.
Thanks
Dr. Juan-Carlos Letelier
According to the specs, the MCP3912 has wide dynamic range, 2.7 - 3 V and at 24 bits more than enough resolution - in any case, it should have no problem even sampling a millisecond signal - so I think this is all tied to the compression algorithm.
Bluetooth can apparently only send 100 packets/s and each packet is just 20 bytes of data?
Anyways, I think for the data quality it would be probably better to cut down on the sampling rate, because the compression sometimes doesnt transmit the data correctly - and in a way that is different from noise.
Is there an option to turn the compression off?
We are continuing the analysis of GANGLION boards when using simple sine waves (of different frequencies and amplitudes) as inputs.
Yesterday we reported some interesting data showing some large distortions when the input data was above 8Hz.
Today we report similar results USING ANOTHER GANGLION BOARD
If the signal is a 1 HZ sine wave the amplitude can go between 1 mV and 100 mV WITHOUT any noticeable distortion
But if the input signal is 2.3 Hz large distortions happen at 24 mV (!!!)
If the input is 5.3 Hz distortions happens at 7mV (!!)
Interestingly the link between distortions and the INDEX variable (that reflect data packets) is maintained. The output data shows some small non-lineal glitch, but the large (and FAST) distortions are always associated with the begining of a new data packet.
I have no explanation .. and, like fdarvas, we have NO FILTERING in our data stream
The OpenBCI engineering group is tracking all your posts, has confirmed the glitches you see, and is investigating further.
My personal hunch is that because there is the correlation with the packet index number, a firmware fix MAY be possible. But that is only my personal speculation and does not reflect the internal investigations. Please be patient as that work continues. Sincere apologies for any effects this is having on your current work.
After more investigative work, it is looking more likely that a revised Ganglion firmware addressing this issue, may be possible. The fix will also require updating internals of the Brainflow library and re-linking OpenBCI_GUI. (Thus involving more code changes and time.) End users / programmers utilizing the Brainflow library will see no changes and continue to call the API as normal. The library will make adjustments internally to talk to the new firmware.
OpenBCI intends to keep posting updates as this proceeds. Thanks so much for your patience and wonderful diagnostic contributions. Your posts have helped to pinpoint the location of the malfunction.
William
Excellent news! Looking forward to testing it ! Will you be notifying interested users when the FW is ready? How is it updated on the Ganglion? Via bluetooth? Or does this require some form of wired connection?
The Ganglion firmware update process is described here, it uses Bluetooth. OpenBCI will supply the new 'OTA' (Over The Air update) firmware file,
https://docs.openbci.com/Ganglion/GanglionProgram/#setup-mobile-device-for-ota-programming
This Forum thread will be updated when ready. Be patient as the mods entail multiple pieces: Brainflow, Ganglion, OpenBCI_GUI. Timeframe is still not nailed down yet.
Hey great news, Phillip Pitts, (OpenBCI head of software), has working new firmware that fixes your issues. It is undergoing final testing and validation, but I'm guessing may be available within a week or two. (Not official date, just guessing.)
Congratulations to the entire OpenBCI staff that made this fix possible and easy to upgrade. The new firmware is 'optional', in other words old boards without the upgrade will still work the way they did before. Brainflow detects which firmware it is talking to, and adjusts the decompression it uses.
Great News indeed ... I will try the new firmware as soon as you liberate it.
Hey everyone - the team at OpenBCI has developed a new Ganglion firmware release (v3.0.1) that should resolve the problems described in this thread. You can update your Ganglion devices by following the updated instructions in the Ganglion Programming Tutorial.
I really appreciate you bringing this issue to our attention and for detailed posts describing the problem. Those details made it much easier to diagnose and correct the problem.
We determined that the problem was related to the compression algorithm used to transmit data from the device to the host computer. Bluetooth has a limited bandwidth and in order to maintain the sampling rate of the device, compression must be applied to reduce the size of each transmitted sample. The old compression algorithm used delta compression. In general, instead of sending full samples, it sent the difference between the last sample and the current sample. The driver on the receiving end would keep track of the last sample and decode the compressed data using the delta.
This strategy worked well for most cases when the delta between two subsequent samples was small. However, it failed when the difference grew large. This difference grows in magnitude as the amplitude and frequency of the signal grows, and this is why the transmission would seem fine in the first examples @fdarvas provided, but would fail in the later examples. The delta grew so large at some points that the 18-bits or 19-bits available to store the sample were not sufficient.
To fix the problem we removed the delta compression strategy and returned to sending actual samples. However, these actual samples (24-bits as sampled by the ADC) are still subject to the same 18-bit and 19-bit transmission limitations. We elected to send the most significant bytes of the 24-bit sample and truncate the least significant bits. This means that some resolution is lost, but the loss is small (at worst 0.11967469688352 uV). The strategy is described in detail in the Ganglion Data Format documentation, and I invite you to view that page for more information.
If you have any related questions, I'm also happy to answer them in this thread!
Mentioning @letelier, @fdarvas.
I will get the new firmware at the end of next week and I will begin some tests
Thank you for your effort to solve this problem
Any updates on your testing, @letelier, @fdarvas ?
Nothing yet
I have been busy ... But I am EXTREMELY interested in the results........ I will do the necesarry experiments as soon as I understand how to upload the FIRMWARE ...I NEVER paid any attention to this topic to be honest....
Dr. Juan-Carlos Letelier, thanks.
This page describes how to download the firmware and install. Then you should be able to do your signal generator tests.
https://docs.openbci.com/Ganglion/GanglionProgram/
William
Any reports on your testing, @letelier, @fdarvas ? Were you able to upgrade the firmware?
I finally found the time to test this - but.... Its impossible to upload the firmware to the device - the android app just refuses to let me select the .zip file with the firmware. It shows it is there in my google drive, but I cannot select it ( I can select other zip-files though, which of course do not contain the firmware?) - there must be better way to this???
Felix, hi.
Did you first DOWNLOAD the zip so that it resides directly on your phone? Such as downloading to the default Downloads folder? Which phone app are you using, type of phone, etc. @philip_pitts may also have comments.
Regards, William
its an android phone - I tried both, drive & direct download - none of them work - I can see the file, but the nRF updater doesnt recognize it as a valid zip file. Ironically I have other, non-firmware related zip files there, that it will let me select. Originally I downloaded the file to my PC (windows) - so maybe windows is doing something with the zip ?