OpenBCI Channel Gain specification

[parguello]

Swapped out the passive for the active electrodes this morning and connected to the OpenBCI app. Set the channel gains there to 1x and everything appears to be in order:

openBCICap.PNG (213.48 KiB) Viewed 36356 times

However, when I went to BCI2000, setting the channel gains to 1x, I'm seeing the following:

bci2000cap.PNG (92.14 KiB) Viewed 36356 times

It doesn't seem as if the gains are still being set properly, though I am not sure why I'm getting fV when I'd expect the gain to be set to the default 24x, which should result in an increase in order of magnitude, not decrease. Strangely enough, when I set the gain back to 24x, I still receive the same readings.

[mellinger]

Channel 7 shows a reasonable signal, so there doesn't seem to be a fundamental problem. The large range (mV) could be due to the amplification of the active electrodes (which BCI2000 does not know about).

The remaining signals could actually be very small and contain only line noise (the time series looks like it).

Regarding the scale of the remaining signals, I suspect that you have AutoScale on. Right-click the signal display to switch it off in the context menu. Then you should get the default scale corresponding to the channel gains that you specified.

[parguello]

Testing this morning revealed that a number of channels needed additional time to settle. Oddly enough, however, channels 1 and 2 remained seemingly dead, reporting values in the fV range and the rest reporting values in mV. Those are my Fp1 and Fp2 electrodes, so they should be among the most robust.

I tried your suggestion of toggling AutoScale, and that helps w/ visualization, but that doesn't address the core issues of these two channels appearing dead and the rest reporting these large values. There is something still amiss w/ how BCI2000 is settings the gains, since I get completely normal readings in the OpenBCI GUI after setting the channel gains to 1x there.

Corroborating this belief is that, when I tweak the following line in my parameter file to read 8 1 1 1 1 1 1 1 1:

Code: Select all

Source:Signal%20Properties:DataIOFilter list SourceChGain= 1 auto // gain for each channel (A/D units per physical unit)

I get the following error:

Code: Select all

2024-08-21T10:06:33.907 - SignalSource error, DataIOFilter::AutoConfig: OpenBCIADC::AutoConfig:
source channel gain will be automatically calculated. This value can be change by changing ChannelsGain.

To circumvent this, I'd been omitting any lines in my parameter file that have Source:Signal%20Properties:DataIOFilter, but perhaps this is leading to the anomalous signals I'm receiving?

[mellinger]

For unknown reasons, the original developer of the OpenBCI source module decided to introduce another parameter, ChannelsGain, for specifying the gain of OpenBCI channels, and required that SourceChGain be set to "auto". That's where the error message comes from.

SourceChGain is then populated through the values specified in ChannelsGain. The resulting values in SourceChGain are rescaled, though. Anyway, all channels are treated by the same code in loops, so there is very little room for what could go wrong for individual channels but not for all channels.

If you have the source code for the OpenBCI EEG viewer tool, I could check for low-level settings that may be applied by BCI2000 differently from that tool. E.g., if the hardware would allow to choose input impedance, and that were set differently, a possible input saturation would decay at a different rate, which might explain differences between the two programs.

[parguello]

Here's the GitHub repo for the OpenBCI GUI:
https://github.com/OpenBCI/OpenBCI_GUI/ ... penBCI_GUI

I'm poking around the code that mentions ADS1299 right there in that root directory (the .pde files), since the ADS1299 ADC is what the Cyton board (the OpenBCI board) is based on.

As for everything else...apparently JAR files need to be unzipped and the attendant .class files decompiled.

[parguello]

Looking at the source code for OpenBCIADC, I found where the gain factor is ultimately calculated:

Code: Select all

//convert the channel gains 
	for (int ch = 0; ch < mNumChannels; ch++)
	{
	double gainFactor = CONVERSION_FACTOR*(24.0/mChannel_Gain[mSourceChList[ch]]);
        Parameter( "SourceChGain" )(ch)<<gainFactor<<"V";
	}

Here, mChannel_Gain is essentially the ChannelsGain, which is specified by the user in the parameter file.
CONVERSION_FACTOR is 0.000000061362, according to the header file.
If I specify a ChannelsGain that looks like 8 1 1 1 1 1 1 1 1, I'm gonna get a 1x8 vector of 0.000001472688
Is that typical...?

Also, I'm not sure if this helps or not, but according to some of the people at OpenBCI's forums, the gain is hard-coded as 24x. May explain the gainFactor calculation here.

[mellinger]

I'm gonna get a 1x8 vector of 0.000001472688

That sounds reasonable, it means 1.47 Microvolts per A/D unit.

Here's the GitHub repo for the OpenBCI GUI:
https://github.com/OpenBCI/OpenBCI_GUI/ ... penBCI_GUI

Thanks for the link, I've looked through the code but could not find any setting that is not applied in BCI2000's OpenBCI source module.

Even if there were, nothing explains why you have two channels behaving differently from the others.

[parguello]

Thinking about it a bit more, it seems that the user-specified ChannelsGain parameter is misleading. You're not really specifying the gain the channel sees, but what the immutable 24x board gain is divided by. Taking this into consideration, 8 1 1 1 1 1 1 1 1 does not result in 1x gain across 8 channels. To achieve that, I'd have to enter 8 24 24 24 24 24 24 24 24 so that the gain factor calculation shakes out to 1x. Lo and behold, I now get readings in the tens of uV range.

Even if there were, nothing explains why you have two channels behaving differently from the others.

To this point, I'm still getting those flat-lined channels 1 and 2. I don't mind terribly, since they're my Fp1 and Fp2 electrodes that I don't really need for SMR work. If anything, they're reducing the influence of eye blink artifacts, so that's a plus.

At any rate, thank you for helping me out w/ this issue, Dr. Mellinger, and for taking the time to look at some source code w/ me!