BCI exploration thread with NBorgaGonzalez

edited April 2016 in General Discussion
Please note: This is a master/umbrella question that @wjcroft asked me to create. I am a new member to this community and have (in the last week or so) posted a large number of disparate questions. @wjcroft, who I assume is a community moderator of OpenBCI proper, asked me to just lump newbie questions into a thread moving forward. Hence, the questions under this thread will be all over the place, but are at least scoped to my specific application at hand.

I am vetting out using OpenBCI to feed EEG biodata into an application that would run on my laptop. This application would be a JVM application, and so the first thing I would need to do is build my own Java library that could read serial data from the RF/USB dongle. I'm a professional software engineer so I'm not worried too much about this part, although I do have a few questions regarding data protocols, etc. And although I will certain use the Processing code in the OpenBCI GUI as inspiration for my Java library, I still need to understand certain basics before I can put any of that good stuff to use! More importantly, before I do any of this, I must: (1) verify that OpenBCI is actually what I'm looking for (with a price tag of nearly $1000 for the whole R&D kit, this is very important to me - and my wife!). And (2) I must first understand the nature of EEG data itself, why the industry converts brain waveforms into component rhythm frequencies (alpha waves, beta waves, etc.), and what information we can extract from these rhythm frequencies. As such, all these questions will span OpenBCI, EEG readers and data at large, FFT and everything in between!

For each question I ask under this thread I will provide proof of upfront research (that is, search results from reading the documentation/tutorials as well as search results from questions previously asked on this forum).
«1

Comments

  • edited April 2016
    My first question is with respect to Fast Fourier Transform and the EEG data read by OpenBCI. My understanding of FFT (and Fourier Transform/Analysis in general) is that it is a nifty mathematical trick that can be used to convert linear differential equations with non-sinusoidal source terms (that is, diff eq's that are very difficult to solve) and decomposes them into component functions, where each component function is itself a linear differential equationwith sinusoidal source terms (that is, multiple diff eq's that are very easy to solve).

    FFT is useful in many applications in science and engineering: basically anything with a waveform can be decomposed down into constituent waveforms, where each of those constituents can be studied and analyzed.

    But none of this mathematical gobblety-gook answers the fundamental questions:
    • Why do we care about doing this for raw EEG data (that is, raw brain waves)?
    • Performing FFT on raw EEG data gives us a graph of amplitude over frequency, where frequency is on the x-axis, and certain bands on this x-axis represent the various so-called "brain waves" (or rhythms) such as Alpha Waves, Beta Waves, Delta Waves, etc.  But why do we care about these component frequencies? What data do they convey to the EEG interpretation that is masked when viewing the original waveform?
    Proof of research:
  • wjcroftwjcroft Mount Shasta, CA
    edited April 2016
    NBorga, hi.

    Chip Audette's blog gives a great background on EEG and BCI topics.

    http://eeghacker.blogspot.com/

    The EEG is decomposed into component bands because those bands correlate with various functions and processing happening within the brain. EEG signal processing is a huge field, and FFT is a primary tool, but not the only one.

    I suggest you look over this neurofeedback tutorial using BrainBay. It will give you some ideas about how the filters are used and measured. The EEG bands can be derived either from an FFT or from a digital filter. Filters are usually a bit faster and hence preferred in some applications like neurofeedback. Anything you can see in BrainBay can also be done in neuromore, OpenViBE, etc. The OpenBCI_GUI is a good introduction for seeing your alpha with eyes closed. And can be used for recording, playback, etc.

    https://sites.google.com/site/biofeedbackpages/brainbay-openbci

    I'm wondering if you might be formulating some goals that you would like to do with the OpenBCI. Chip's blog is a great resource for BCI DIY experiments. I'm primarily interested in neurofeedback. Other threads on the forum here talk about SSVEP Steady State Evoked Potentials or P300 event related potentials used in BCI spellers and Motor Imagery applications.

    While you mention the R&D kit, a whole lot can be accomplished with just a few channels, 1 to 4. You get 8 with the current mainboard. 4 with Ganglion. The 16 channels would not be a requirement for many EEGHacker type applications.

    More good blogs and reading,

    http://openbci.com/forum/index.php?p=/discussion/185/list-of-blogs-about-openbci-neuroscience-and-related-topics

    William

  • Awesome, awesome answer @wjcroft - I will definitely have a look at the BrainBay tutorials as well as that blog.

    Regarding the R&D kit, this may be good news for me! But let me back up a bit first!  My understanding of traditional EEG readers is that 2 electrodes make up a single "channel". That is, one takes the voltage difference between two specific electrodes, and that difference is a single channel's "voltage value" for any given point in time. For instance, on a standard 10-20 system, T3 and T5 are two locations where electrodes go. So there might be a T3-T5 Channel, and the voltage difference between T3 and T5 at any given point in time will be the voltage value for the T3-T5 Channel at that time.  Is what I've explained here correct, or am I misled?

    Assuming I'm correct, then you mentioned that the current mainboard gives me 8 "channels". When you say "channels" here, do you mean the same thing as what I described above? Meaning, 8 channels actually gives one the ability to read voltage differences across 16 electrodes?
  • wjcroftwjcroft Mount Shasta, CA
    Most EEG hardware specifications list the "number of channels" as relative to a "reference electrode". That is, a common reference for all the "active" electrodes. Typically the reference is on the ear lobe and the actives on the head. The 32 bit board gives you 8 channels. Usually setup as the ear reference and 1-8 cup electrodes on the head.

    However the OpenBCI is flexible enough in that you could optionally have all 8 channels operating in a "bipolar" or "differential" fashion, with separate plus and minus leads. This is rarely used however.

  • Makes sense @wjcroft, thanks for the clarification on the channels/electrodes stuff.

    Specifically, I'm looking to detect specific events based on raw EEG waveforms, and believe Event-Related Potentials (ERP) are what I'm looking for. My understanding of EEG signal processing is:
    1. Capture the raw EEG data
    2. Pass this data through a Signal Processing Network, where each processor (such as FFT) does something to the data to unlock more (hidden/encoded) information than what was previously available on the original waveform
    3. Analyze this unlocked data
    So what I'm really trying to figure out is: what does my "Signal Processing Network" need to look like, in order to implement these "ERPs" so that I can correlate specific waveforms to specific events?

    I found this white paper and will digest it over the course of the next week, but welcome any other suggested reading!

    I gave the BrainBay user manual a readover, but found it glosses over a lot of concepts that might make sense to an EEG-veteran, but that are completely lost to a newbie like myself. Also, I can't seem to find its source code anywhere. Ideas?

    Thank you!!!
  • wjcroftwjcroft Mount Shasta, CA
    If you are looking for examples of P300 (ERP) spellers or Motor Imagery, Jeremy did two great tutorials on this,


    Both using OpenViBE. The reason I mentioned BrainBay and neuromore (both free, as is OpenViBE), is that they will be easier to start with and understand than jumping right into ERPs. If you look through that BrainBay tutorial, don't read the entire BrainBay manual, but perhaps just look up each element block that you are unfamiliar with. For example there are element blocks that filter the raw EEG into component bands, compute the magnitude of those bands, display graphs on the screen, compute expressions based on magnitudes, control the volume of an mp3 audio, etc. The tutorial link I gave explains what each element block does in terms of signal processing.

    The paper you found is a good one! If I were you, I'd start out looking through Chip's blog for interesting posts. Your paper is a good tutorial on BCI signal processing. But it's also assuming much more background than either Chip's blog or the BrainBay example. Start with some moderate level stuff first before you tackle ERPs. Look through some of the examples on the Community page.

    BrainBay source link is available from the main site,


  • Thanks again @wjcroft.

    I've been doing some reading on active vs reference electrodes and I believe I understand the gist of it. However, something is now becoming clearer to me, which makes me think of more questions to ask!

    The Mark III is a 10-20 headset, and I believe the (coming soon) Mark IV is a 10-10. My understanding is that on a 10-20 setup, there are 21 electrodes, and that on a 10-10 there are roughly ~75 (I was too lazy to count them all on the diagram I found!).

    However, the OpenBCI mainboard only gives you access to 8 channels. Even when coupled with the "Daisy Module", this only gives us access to 16 channels, still 5 short of the 21 required for (what I believe is) a "proper" 10-20 EEG reading.

    What am I missing here? Where is my math going awry?!?

    Is it that you can still have a perfectly good EEG reading with only 4- or 8 or 16-channels? Either way, why would Mark III be designed to handle a 21-electrode 10-20 system, but then have its hardware only support 8-electrodes at a time?!?

    Thanks for any clarification! And BTW - this is not me being critical of OpenBCI in *any* way, shape or form! I'm just trying to make sense of things.
  • wjcroftwjcroft Mount Shasta, CA
    Take a look at Jeremy's blog link I mentioned previously. It shows the 10-20 layout with BCI on 8 or 16 channels. 10-20 is just the map of all possibilities. You choose which sites you want to monitor from that map and what kind of brain areas you are wanting to receive from.

    Certain types of EEG work, called QEEG or source localization, do require a full set of electrodes. These systems utilize more expensive amplifiers that have 19 or more channels. Even 32, 64, 128, etc.

  • As always, makes sense @wjcroft!

    Here's an interesting question that I'm pretty sure is a rabbit hole...

    Given the 8-channel limit with the OpenBCI mainboard, are there any recommendations as to which location (on a standard 10-20 or 10-10) would yield the "best readings"? I put that in quotes because I'm not entirely sure "best readings" even means!

    Or is the location of the electrodes entirely dependent on the application/objective of the reading? In that case, can you (or anyone!) point me in the direction of "EEG electrode placement strategies"? Blogs/books/white papers/etc.? Thanks a bunch!
  • wjcroftwjcroft Mount Shasta, CA
    Hi NBorga, it depends entirely on what type of neurofeedback or BCI you are trying to accomplish. So best strategy is to research the type of experiment / situation you want to run, then see what others are using.

    Motor imagery and SMR / Mu are obviously done on the motor strip. SSVEP generally in the occipital area. Frontal asymmetry at F3 F4. QEEG mapping based neurofeedback sees which areas are excess or deficient compared to a normative database of 10-20 sites. Then does reward / inhibit protocols to bring those sites back into normative range.

    Here's a simplified site map used by some neurofeedback protocols,

    https://sites.google.com/site/biofeedbackpages/function-map

    Also see the Brodmann atlas links on that same page.

    This other recent post has some BCI montages,

    http://openbci.com/forum/index.php?p=/discussion/674/openvibe-acquisition-server-motor-imagery-montage-configuration
  • Thanks @wjcroft, I was starting to figure as much. Thanks for those links! I also found this article and am giving it a read:

    Quick question concerning voltage amplitudes. I have read from a few sources that average EEG reading voltage is ~100 uV. But what's the range of amplitude there? Meaning, on average, what values will EEG channel data bounce back and forth between (in volts)?

    From a previous question, @wjcroft had stated:

    EEG data ranges typically +- 100 microvolts

    But if +/- 100uV is typical, then what are the actual reasonable bounds? +/- 200uV?

    Basically, I want to plot my own graph of channel readings over time, with voltage on the y-axis and time on the x-axis, and I need to figure out what the y-axis range should be, expressed as micro-volts. Any ideas?
  • wjcroftwjcroft Mount Shasta, CA
    There are a couple ways of handling this. Most GUI's, including OpenBCI_GUI, have a pull down menu that allows you to select a range of microvolts for the graphs. 

    If you look at the BrainBay neurofeedback tutorial example I've mentioned previously, it shows several graph subwindows, each with their own graph scale. The RAW EEG is plotted on a large scale, say +- 80 uV max. The alpha band amplitude is plotted on a smaller scale, say 20 uV, etc. This is all easy to setup with a VPL, with no programming needed.

    Yet another way to go is have a graph that "auto-scales". A downside of this approach is that it jumps around a lot if your signal has bursts of large activity.


    Best,
  • Hi all,

    I'm reading through the v3 Data Format Specs and was wondering what specific serial port I need to connect to (on the client-side) in order to speak with the mainboard.

    For instance, on my Mac, I have the following serial ports:
    • cu.Bluetooth-Incoming-Port (Bluetooth-Incoming-Port)
    • tty.Bluetooth-Incoming-Port (Bluetooth-Incoming-Port Dial-In)
    • cu.Bluetooth-Modem (Bluetooth-Modem)
    • tty.Bluetooth-Modem (Bluetooth-Modem Dial-In)
    Any idea which one would be used for connecting to the OpenBCI via the USB/RF dongle?
  • Ahhh, that makes sense, thanks @wjcroft. Do I want the D2XX or D3XX drivers (so I guess, what's the difference between 'em)?
  • wjcroftwjcroft Mount Shasta, CA
    If you install the FTDI drivers I think you get all of it, might be mistaken. In any event, your code does not need to talk with D2XX. It's just a plain serial port, the /dev/xxx that it exposes. The D2XX API calls are documented on the FTDI site. They are more useful if you are interfacing in Android.

    http://openbci.com/forum/index.php?p=/search&Search=d2xx

  • Thanks @wjcroft

    A few questions regarding OpenBCI config.
    1. According to the Channel Count docs ("Select your channel count (8 or 16)"), one can specify the CHANNEL COUNT based on the appropriate board being used (mainboard or mainboard+daisy). Where does this configuration happen, inside OpenBCI_GUI or right there on the mainboard? Depending on this answer, I will have some other followup questions!
    2. Can I assume that when the Ganglion is available, that selecting a CHANNEL COUNT of 4 will become an option?
    3. If you search these forums and the docs for "data compression", I see a lot of disparate references to the subject, but nothing in the docs that definitely explains what this OpenBCI data compression feature is, how it works, and how it can be configured. Any ideas?
    Thanks!
  • wjcroftwjcroft Mount Shasta, CA
    1. it happens in both places; mainboard recognizes that daisy is plugged in; GUI needs to be made aware also. A potential future solution for this on the GUI side would modify the serial stream to contain a channel count.

    2. yes

    3. no compression is used currently. That's why sample rate drops from 250 sps to 125 sps when using the daisy. You're welcome to try some firmware mods.
  • Thanks @wjcroft, does this mean the Ganglion sampling rate will be 500 sps?
  • wjcroftwjcroft Mount Shasta, CA
    No, Ganglion is listed on the Kickstarter site as running at 256 sps. A more common sample rate. And that same rate is shared by OpenEEG. Thus Ganglion could potentially have Bioexplorer compatibility, given the proper firmware.

  • Thanks @wjcroft, when you say "GUI needs to be made aware [of sampling rate] also", what is OpenBCI_GUI doing that needs to be aware of the channel count (just curious)?

    Also, in a different thread you mentioned that the GUI can set the scale factor in the firmware, yet, in the v3 Data Format specs, I don't see anything that allows me to set the scale factor by writing it to, say, the USB/RF dongle serial port, etc. Do you have any insight as to how this scale factor setting works inside the GUI? Thanks!
  • wjcroftwjcroft Mount Shasta, CA
    The GUI needs the channel count to show how many graphs on the voltage vs. time plots. It needs to know the sample rate to plot the X axis on that graph, and also compute the FFT.

    The Chan Set tab in the GUI controls the scale factors on each channel by sending ascii command characters to the mainboard. It's labeled "Gain Set" on this page, not "scale factor",




  • Thanks again @wjcroft.

    Regarding the OpenBCI Firmware SDK, I guess I'm a bit confused regarding its relation to the OpenBCI v3 Data Format specs that I've been referring to above.

    In the data format specs, they make reading EEG data seem as simple as:
    1. Send an ASCII b to the OpenBCI (via over-air protocol, USB/RF dongle, etc.)
    2. OpenBCI will now start streaming, all channels
    3. When you're done, send OpenBCI an ASCII s
    But the link you sent (for the firmware SDK) seems to add another layer of (good!) complexity to the API. Can you confirm my understanding here, that if I wrote the following characters to the serial port that the USB/RF dongle was using, that the respective behavior would be observed?
    • I write an ASCII b and all channels (1 - 8) start streaming data
    • Next, I send the following bytes: x 3 0 0 0 0 0 0 X, this turns Channel 3 off, and so now only channels 1, 2 and 4 - 8 are sending data
    • Next I write an ASCII s which turns all channels off
    Can you (or anyone!) just confirm I am understanding the firmware protocol correctly? Thanks again!
  • wjcroftwjcroft Mount Shasta, CA
    I think you have most of that right, but not the x3000000X command. To turn off channel 3 just send a '3'. '#' would turn ch 3 back on again.

    Look at the example given for x 3 0 2 0 0 0 0 X . It turns 3 on, with certain parameters, such as gain 2 etc.
  • Thanks @wjcroft!

    I'm now trying to understand the 24- to 32-bit conversion method noted in the docs.
    1. This method accepts a byte[] as input, but then assumes that byte[0], byte[1] and byte[2] exist. Why does it make this assumption?
    2. Looking at the Binary Format docs, it appears that OpenBCI will blast 33 bytes of data at a time. That is:
      1. 2-byte Header; then
      2. 24 bytes of Channel Data; then
      3. 6 bytes of Accelerometer Data; then
      4. 1-byte Footer
      5. (Total of 33 bytes in all) --> can someone please confirm this?
    Thanks!
  • wjcroftwjcroft Mount Shasta, CA
    Have you looked at the Processing code in OpenBCI_GUI? It has a complete parser for the serial format.

  • wjcroftwjcroft Mount Shasta, CA
    There are different ways to implement the stream parser. Here's a "state machine" approach, see parse_byte_OPENBCI() function ~ line 750 in,
  • Hi all,

    I'm trying to get a better understanding for how the PC/USB dongle works. I know it has an FTDI chip on it for handling USB communication.

    My understanding is that:
    1. The dongle also has an RF receiver on it
    2. This RF receiver takes biodata (sent by the mainboard) and forwards it on to the FTDI chip
    3. The FTDI chip then forwards the data onto the FTDI drivers (which must be installed on the user's machine)
    4. The drivers then pump this data onto a named serial port
    5. Applications can then read the data from the named serial port
    Is my understanding correct, or am I misled in some way? Thanks!
  • wjcroftwjcroft Mount Shasta, CA
    Yes, that's correct. The FTDI chip handles the conversion to USB / serial from the data stream provided by the RFduino on the dongle. There is a similar RFduino on the back of the mainboard. On the dongle, the RFduino is in control as the processor, the FTDI is a peripheral.

    The dongle is a combination of TWO boards from RF Digital into a single board,

    http://openbci.com/forum/index.php?p=/discussion/148/specs-of-the-esd-components-on-the-usb-dongle-board

    William

  • Thanks @wjcroft

    Today is an exciting day! Today I will purchase a 32-bit board and some "gold cup" electrodes (finally)! It took some wife-convincing but I now have the proper security clearance ;-)

    Quick question - since I am not buying the Mark III, I will need to jury rig my own contraption for keeping the electrodes in place. Does anybody know of any good DIY projects that might have already solved this for me?

    Also, will I need electrode gel? If so, any recommendations? Thanks again!
Sign In or Register to comment.