OpenBCI_GUI: ADS1299_gain (scale factor) always x24?

Comments

• wjcroft Mount Shasta, CA

  May 2015

  Mike, hi.
  
  Answering your first question, reference,
  
  http://docs.openbci.com/software/02-OpenBCI_Streaming_Data_Format
  
  At x24 scale factor, the low order bit of the 24 bit samples represents 0.02235 microVolts. That is already WAY small. You could say that the 4 or 5 lowest bits are essentially 'noise'.
  
  I have not checked the OpenBCI_GUI code in the way it sets the ADS1299_gain or hardware registers. Perhaps Conor @obci_conor or Joel @biomurph will comment here.
  
  William
  
• Mike

  May 2015

  Hi, 

  
  

  This document says that the scale factor is a function of the user's selected gain, however, in the code the "ADS1299_gain" doesn't change even if the ADS1299 gain was modified.  Would like to hear if there is some explanation for this behavior or is this a bug?

  
  

  Mike
• jfrey

  May 2015

  Hello,

  
  

  Just a little note about the amplification: the "x24" of the ADS1299  corresponds to 2^24, ie to "x16M+". So if you're talking raw numbers, OpenBCI wins compared to others doing "x100K"; but then, as William said, in real life scenarios you have to consider noise. It's a bit like the megapixels war with DSLRs I guess, quality != specs.
• Mike

  May 2015 edited May 2015

  Hi, 

  Can someone please answer my 2nd question. I suspect there is some serious bug there.
  

  Also, in the document below you claim that this value should be adjusted when amplification is changed. 
  

  http://docs.openbci.com/software/02-OpenBCI_Streaming_Data_Format

  
  

  Thanks.
• jfrey

  May 2015

  Hello,

  
  

  I suspect that the GUI is just not in sync with the ADS1299 state -- and even worse, the scale should be computed for each channel since the gain can be adjusted individually. I don't see this as a "serious bug", though, because typically should I record something with OpenBCI, I annotate the settings I used during the experiment and then I could correct afterwards the scale of the values if needed. I prefer to do that manually -- ie working with values as raw as possible -- rather than letting the software handle this. But on the other hand, if you use on-the-fly gain correction often, I understand how it could be easier to directly get the "right" values in the output.

  
  

  If you are using specifically the Processing GUI, maybe you could fill a bug report here in order to get more visibility: https://github.com/OpenBCI/OpenBCI_Processing/issues
• Mike

  May 2015 edited May 2015

  Well, when system's core data is being processed (e.g. scaled, filter etc) wrongly I suspect this is considered a serious bug. 

  As far as I understand, OpenBCI's UI is part of OpenBCI EEG solution and most people use it for analyzing and evaluating 

  OpenBCI output.

  
  

  My question is directed to the one who actually wrote the code. I wonder if he is aware to this? And if it is considered an issue or is there some intelligent reasoning for not changing the scale factor in the UI even though it is changed on the device? 

  
  

  
  
• jfrey

  May 2015

  If you make a bug report you will be sure that the people developing the software will acknowledge your concerns, and hopefully discuss / fix it

  
  

  The Processing GUI is only one part of the "OpenBCI EEG solution", and to me it is more a handy tool to get hands on the device -- or borrow piece of code -- than a software directly aimed at scientific experiments. For that you would rather integrate raw signals coming from OpenBCI to existing solutions, -- eg Matlab or OpenViBE -- or start with very simple scripts to have the upper hand on what is computed -- look at the python scripts for example (I have no shame at advertising stuff I contributed to ). Processing is not really a match when it comes to performance -- and accurate real-time signal processing can be demanding. Be careful for example that by default Processing runs only at 60Hz (FPS).

  
  

  Actually, what utilization do you have in mind for OpenBCI?
• Mike

  May 2015 edited May 2015

  Different EEG devices might require different pre-processing procedures for 

  the raw data and these procedures are greatly depend on the electronics that are used. So, that's why I believe that it is crucial to properly have some decent document/reference that could be used to understand these pre-processing procedure. What I'm trying to say is that it doesn't really matter if you use Matlab, Python, C/C++ or VB
  

  
  

  Anyhow, if someone from the OpenBCI team could comment on this it would be nice.

  
  

  
  
• jfrey

  May 2015

  Don't worry, you're not being rude, it's me, sometimes it's hard to know which kind of background users have and I may not respond accordingly

  
  

  (also, you may have noticed that English is not my mother tongue, so on a few occasions I may sound less friendly than what I meant )

  
  

  So if you already have knowledge in signal processing, definitely the Processing GUI is not what you will use, and as such the discrepancy in scales that you rightfully pointed out may not be relevant in your situation. One of the problem is that there is not *one* OpenBCI driver that could create an abstract and common layer on the computer so that other software will all behave the same. Since we just have to read the serial port to acquire data, few lines of code depending on the language, every OpenBCI implementation -- Processing GUI and python scripts in the official repositories, BrainBay or OpenViBE "drivers", and so on -- may convert differently the raw values.

  
  

  Maybe the conversion to the "right" scales should be made directly out of the box (ie within the OpenBCI firmware), so it would be easier to maintain things on the computer side, but I think it would be problematic at the moment because of the protocol used to transmit data wirelessly (integers are saving bandwidth).

  
  

  Now I'm curious; in my current use of EEG and BCI I've never really had to take into account the units of what I'm measuring. It could make sense if you compare, let's say, the ERPs measured by two different systems side by side. But when I seek statistical differences in ERP / band power measured by one EEG device in different condition or with different subjects, or when I let machine learning do its magic tricks, in the end I'm only interested in average differences and in classifiers performances.
  

  
  

  Note that it's in my todo-list to compare during a proper study OpenBCI against a "medical grade" EEG device, so at some point I will need those units, and maybe then we could help each other
• chipaudette

  July 2015

  To the original question, the last time that I looked at the OpenBCI GUI code, it was indeed incorrect in that it always assumed a gain of 24x, even if the user selected a smaller value.  That is a bug.

  
  

  There was a branch of the OpenBCI_GUI that was created to fix this issue, but I'm not sure if it was completed or not.  If you want, you can check it out here:

  
  

  https://github.com/OpenBCI/OpenBCI_Processing/tree/fix_perChannelGain/OpenBCI_GUI

  
  

  Chip
• Mike

  July 2015 edited July 2015

  Hi Chip, 

  
  

  Just wonder, wouldn't there be an issue with "VertScale" if gain is changed per channel yet the scaling for the display data is performed for all channels?

  
  

  Mike
• chipaudette

  July 2015

  When I wrote the initial GUI, all of the plots were intended to be showing microvolts.  More specifically, it was intended to be "microvolts as seen at the overall input to OpenBCI".  Or, said another way, the GUI should be showing the voltages produced by your head.  Since the gain setting on OpenBCI doesn't change the voltages produced by your head, changing the gain should not affect the amplitude of the displayed signals.  The GUI should know that the gain changed and should account for it.  A 10uV Alpha wave should always show up as a 10uV Alpha wave in the GUI, regardless of the gain setting.

  
  

  Unfortunately, that's not what happens right now.  If you lower the gain from 24x down to 12x, the GUI makes it look like the amplitude of the Alpha wave dropped in half.  Wrong.  The GitHub branch that I linked about, was an attempt to correct this behavior so that the GUI (and the log file!) always indicate the voltage as produced by the head, properly accounting for the gain of the OpenBCI hardware.

  
  

  Now, to address your question about "VertScale", the VertScale button is intended to allow the user to tell the GUI to zoom out (or zoom in) on the data.  If you've got a really strong signal (like ECG), you'll need to zoom out.  My intention was that the best way to zoom out would be via the VertScale button, not via changing the gain.

  
  Unfortunately, because the per-channel gain was not correctly tracked by the GUI, some people have started to use the channel gain settings as a way to see their ECG within the GUI.  While that will work to qualitatively see the signal...all of the microvolt readings will be incorrect, so *quantitatively, it's wrong.

  
  

  If the per-channel gains were to be correctly handled by the GUI (as they might be in the GitHub branch linked above), all of the data will be internally represented by the correct microvolt values.  The VertScale button (which is indicated as microvolts) will continue to work as expected to zoom out the display to allow one to see bigger signals.

  
  

  
  

  The problem with my intended approach is that if you want to see both big (ECG) and small (EEG) signals in the GUI at the same time.  In this case, if you zoom out enough (via VertScale) to see the ECG, the EEG signals will now be too small.  Bummer.  In this case, the GUI's current "incorrect" behavior might actually be better because, by changing the gain of the ECG channels, only those channels will be reduced in size on the GUI.  That way, you can see both big and small signals at the same time.  So, for this user, the current "incorrect" GUI behavior might be better.

  
  

  Chip
• Mike

  July 2015 edited July 2015

  Hi Chip. Thanks for the detailed response. I actually tested this fix. I might have misunderstood, but the thing is that once I change the gain, you can see how the signal is zoomed and looks much bigger, which as far as I understand should not happen.  

  But isn't it expected if we multiply it by a certain scale factor which gets bigger as it is a function of gain?

  
  

  Here is the line where the signal is being multiplied and "scale_fac_uVolts_per_count" is a function of gain level.(the below line is taken from the corrected branch)

  yLittleBuff_uV[Ichan][pointCounter] = dataPacketBuff[lastReadDataPacketInd].values[Ichan]* openBCI.get_scale_fac_uVolts_per_count(Ichan); 
• chipaudette

  July 2015

  Hi Mike,

  
  

  I've not been able to try the fix in quite some time, so I'm not sure what the software does at the moment.

  
  

  Based on my memory of what I was hoping to implement, I think that your expectation is correct...if you change the gain of a channel, it's amplitude should stay the same on the display.  If the amplitude on the display does change, then the modifications to the GUI code must not have been completed.

  
  

  The line of code that you found looks to be correct.  If the GUI is not doing what we expect, then I guess the question is whether the term "openBCI.get_scale_fac_uVolts_per_count(Ichan)" is correctly updated whenever the channel gain is altered.  Briefly looking through the code on GitHub (especially "OpenBCI_ADS1299.pde"), it looks like all the parts are there.  If the GUI isn't responding correctly, it's not obvious to me what the problem is.

  
  

  
  

  Chip