Huge gain applied to visualized source signals

This forum deals with BCI2000 configuration issues.
Locked
rflint
Posts: 7
Joined: 11 Mar 2013, 19:16

Huge gain applied to visualized source signals

Post by rflint » 21 Jan 2015, 14:43

I have a problem where the values of the data displayed in the "visualize raw brain signals" window have an enormous gain applied to them. I am using BCI2000 with a Blackrock Neuroport system. I have contacted the module's author as well as posting here.

The core of my issue is that the values that are displayed in BCI2000 in the "visualize brain signals" window are unreasonably huge. These values also appear to be what gets propagated through the signalProcessing module and to the application module. The values that get stored on disk are fine, only the visualized/real-time processed values have this extra gain factor that I cannot account for.

Okay, the story:
For testing, I am using a sensor that I will want to acquire its data (in an experiment) along with the neural signals. In my testing setup I am only acquiring the sensor, no neural signals. According to the channel properties dialog in Central (Blackrock's configuration utility), this channel should have an input dynamic range of +/- 5000 mV (obviously that's +/- 5V, but Central displays it in mV). The input digital range of the quantizer is 16 bit, or +/- 32767. My sensor has a baseline offset of about 75 mV. I've confirmed that with an oscilloscope, and that's what the display in Central indicates as well. If I record a short BCI2000 data file and then load it up in MATLAB, the baseline occurs at around a value of 500. The SourchChGain for that channel is 0.1526 mV/(AD unit), which is 10000mV/(65535 AD units). Then, 500*0.1526 is about 75. So that all checks, and therefore the gain factors for recorded data are perfectly reasonable.

The problem occurs when I bring up the BCI2000 window for visualizing the raw signal. At the default scale (the one that comes up before I make any changes), the trace is off the top of the window. If I right-click in the window and click on "show Unit", it comes up as 200 nV. If I make the necessary manipulations to actually see the signal, either by manually adjusting the SourceMin and SourceMax parameters in the Visualize tab, or by right-clicking in the visualization window and clicking 'auto-scale', I find that the baseline value of the sensor trace is reading as just under 500,000,000. Since I know the actual value (in AD units) is around 500, I figure this means that the visualizer is just assuming this is in Volts rather than AD units, and displaying the signal in units of uV (microVolts). So my question is, how do I get the visualizer to see the real value, and understand it correctly? The signal source module is correctly recording the data to disk, as I mentioned above. The problem is (I think) occurring in the messages being sent between the signal source module and the operator. At least, from what I've read in the documentation, it is the operator that is responsible for displaying the real-time signals.

One possible clue is the data types. I've used BCI2000 before with 2 other source modules, and neither of them had this problem of unreasonable gain in the visualized signals. When I went back and checked the code for those modules, I notice that they acquired the data in float32, which seems to be the default precision with which messages are exchanged back and forth between the different modules in BCI2000. Whereas the Blackrock module works with int16. That's actually appropriate, since central records in int16, and there is code in the signal source module that seems to my eye to account for the signal type correctly:

Code: Select all

int numberOfChannels = Parameter( "SourceCh" );
int samplesPerBlock = Parameter( "SampleBlockSize" );
SignalType sigType = SignalType::int16;
Output = SignalProperties( numberOfChannels, samplesPerBlock, sigType );

These are the final 4 lines of the Preflight function. The BCI2000 documentation makes it seem like int16 is a valid data type to use, but maybe it's somehow messing things up here?

If I only had to record data for offline analysis, this issue wouldn't matter that much to me. Unfortunately, the version of the signal with this huge gain is what gets propagated through the signal processing module and to the application module. I want to do closed-loop control with this system, so the online version of the signal is important.

I've gone through the code for the Blackrock module, but any modifications I make only seem to affect the data that gets recorded, not the data that gets processed online. I imagine that I might need to investigate CoreModule.cpp or something similar, but I'm not sure where to begin. Can anyone offer any advice?

Thanks

pbrunner
Posts: 344
Joined: 17 Sep 2010, 12:43

Re: Huge gain applied to visualized source signals

Post by pbrunner » 27 Jan 2015, 21:05

rflint,

to isolate the problem I need to know if you are using the pre-build executables or if you have compiled the code, and for the latter which revision of the code you are using. Also if you have complied on your own, can you try to compile and test the latest version from SVN?

Please let me know.

Regards, Peter

rflint
Posts: 7
Joined: 11 Mar 2013, 19:16

Re: Huge gain applied to visualized source signals

Post by rflint » 28 Jan 2015, 13:35

Hi Peter, thanks for responding.

For the experiments we do in the lab, we have compiled the source code ourselves. I don't remember how to check which revision of the code it is, but we checked it out in October 2014 I think. Your post raises a good point, though, so I tried the following to make a suitable test environment that should do a better job of isolating the problem. I downloaded new copies of the pre-built executables this morning. I copied into the prog folder of this test setup, a copy of our signal acquisition module that we use for our experiments (Blackrock.exe). I then made a batch file that uses our acquisition module executable, then DummySignalProcessing, then DummyApplication. I launched that, Set Config, and looked a the trace from my sensor. It is reporting the same values as in our experimental setup, though it expresses the units slightly differently. If I auto-scale the display, it labels the unit as 4e+008muV, which works out to about the same number as I was seeing in our experimental setup. I recorded a short file, and the recorded data is scaled properly (as was happening in our experimental setup).

Since I posted on this topic originally, I have heard back via email from the author of the Blackrock module. He said that he had run into this problem before, and expressed the opinion that it might be a "bug in the visualization code." That's what I have been assuming, since the signals that get recorded to disk are scaled appropriately.

pbrunner
Posts: 344
Joined: 17 Sep 2010, 12:43

Re: Huge gain applied to visualized source signals

Post by pbrunner » 28 Jan 2015, 14:35

rflint,

can you please checkout the very last revision of the code. If it is related to the "units" in BCI2000, then I believe that the problem in the visualization should be fixed in the very latest revision. If you still see the issue, I will dig deeper. We are preparing new binaries, so it is important to us to fix this issue. I appreciate your help with this.

Regards, Peter

pbrunner
Posts: 344
Joined: 17 Sep 2010, 12:43

Re: Huge gain applied to visualized source signals

Post by pbrunner » 02 Feb 2015, 13:32

Robert,

the issue has been identified and a ticket has been created. This described issue will be fixed with release 3.6 of BCI2000.

Please see the ticket for the details, status and the affected BCI2000 modules:

http://www.bci2000.org/tracproj/ticket/158

Regards, Peter

rflint
Posts: 7
Joined: 11 Mar 2013, 19:16

Re: Huge gain applied to visualized source signals

Post by rflint » 02 Feb 2015, 16:08

To any board members browsing this subject:

Peter's low-key response above follows after an extensive conversation he and I had back and forth via email, and quite a bit of troubleshooting over several days before the problem was narrowed down. I just wanted to post on this topic and let everyone know that he has been extremely responsive and diligent about following up.

Thanks Peter! I will be happy to test out the new version when it is released.

Locked

Who is online

Users browsing this forum: No registered users and 30 guests