Amplitude stays when eye blinks (eeg-pipes using JS)
gerardkleelab
San Diego
Hi,
First of all, thank you guys very much for help. My project is going very well because of your help.
I am stuck with another problem. I created my own GUI using JS. My real time plotting (fft values) is corresponding to my brain signals. However, the amplitude stays for a while when I blink my eyes. I think this is weird behavior and I can't seem to figure out what the data means. I will attach the screenshots and the block of eeg-pipes code I am using below. As the pictures show, there is one spike in the beginning of the eye blink, stays up there quite a while, and another spike, then goes back down. The block of code I am using is also below.
wifi.stream.pipe(
voltsToMicrovolts(),
epoch({ duration: 1024, interval: 25, samplingRate: 256 }),
fft({ bins: 1024 }),
sliceFFT([3, 8])
).subscribe(data =>
{
io.emit("fft_data", data);
}
);
I think it has to do with the duration and the number of bins I am using, but I need to have 0.25 frequency resolution. I would appreciate any advice.
Comments
I am sorry about attaching the screenshots this way. I don't know how to make it show in this post.
One thing I wanted to mention is that the plotting is consistent. It's just that when I blink my eyes, the amplitude stays up there for a while and then comes back down.
FFT always has some lag. How does your JS FFT compare to the OpenBCI_GUI FFT? I assume everything is good in the GUI.
To avoid confusion, I moved this thread from Software/OpenBCI_GUI to just Software. Perhaps give your program another name besides 'GUI', to avoid confusion. Maybe JS-GUI. I edited the thread title to include 'eeg-pipes' and remove the GUI reference.
Regards, William
@wjcroft While the raw data plotting on eye blinks is instantaneous, OpenBCI_GUI FFT plotting is not so instantaneous which means that it slowly goes up and slowly goes down. JS FFT shows similar behavior, but not the same as OpenBCI-GUI FFT; it slowly goes up, stays up there for a little bit, and goes quickly. Could it be the way FFT is being calculated?
@wjcroft Thanks for moving the post by the way.
Gerard, hi.
What you are referring to, sounds to me like the 'windowing' algorithm chosen for the FFT.
https://www.google.com/search?q=fft+windowing
You could possibly change the windowing function used by the FFT routine you are calling.
Regards, William
Moving from the time domain to the frequency domain as FFT does is going to make your data less precise in time because the time data becomes averaged into the frequency data over your interval. Windowing as wjcroft suggests should help by cutting down smearing of the effects of the eye blinks at the edge of each time interval. However if you really want quick detection of changes in the time domain you might want to apply some kind of thresholding or wavelet detection to the pre-FFT, voltage versus time data you collected instead.
Bill, thanks.
Gerard, as Bill mentioned de-artifacting, the pdf referenced in this other thread, shows a heuristic algorithm called SARA, that de-artifacts eye blinks and other noise.
https://openbci.com/forum/index.php?p=/discussion/1258/artifact-detection-thresholds-algorithms
https://qeeg.pro/wp-content/uploads/2014/10/qEEG-pro-Manual.pdf [appendix 1]
Regards, William
The SARA algorithm is a thresholding algorithm. It removes portions of the data that have voltages above a certain threshhold. This works when eye blinks are significantly higher in amplitude than the EEG that is wanted.
Thank you so much, Bill and William. I will definitely look into those you suggested (windowing and SARA). However, I am not necessarily trying to remove artifacts/eye blinks. It's just that when I call that eeg-pipes function above, the values are not instantaneous when I blink my eyes. For example, let's suppose I run the eeg-pipes function above and blink eye once quickly. Then, what I am expecting is below:
[0.34, 0. 23, 0.35, 0.36, 2.32, 3.13, 4.12, 4.68, 4.28, 3.03, 2.13, 0.41, 0.42, 0.38]
As you can see here, there is one peak, and the values slowly go up and slowly go back down. This is what OpenBCI-GUI FFT plot shows and I am expecting this as well in the plotting of my program! However, it rather shows below:
[0.34, 0. 23, 0.35, 0.36, 4.15, 4.13, 4.12, 4.27, 4.28, 4.31, 0.32, 0.41, 0.42, 0.38]
As you can see, the values suddenly go up, stay up there for a bit, and goes back down. Good news is that this is consistently happening, so at least my program is kind of corresponding to my brain signals.
I am trying to implement real time neurofeedback using sound. So, if the values are still high even if my eyes are open, that means feedback will be slightly off. Sounds like windowing could fix this issue and wanted to make sure you guys would agree. Thanks again!
Gerald, hi.
It still sounds to me like a glitch in the FFT window function. It is the window function that is responsible for the gradual rise and gradual decrease. The window function used by the eeg-pipes apparently rises more rapidly than normal, then just quits instead of gradual taper off. Look into the code of the FFT used by eeg-pipes and see if it specifies a window function as an argument. And which window function that is.
https://www.google.com/search?q=fft+window+functions+tutorial
EEG-pipes author, Alex Castillo @alexcastillo is here on the forum and might have comments. He and AJ are now the founders and engineers at https://neurosity.co/ . So may take some time for a response.
Regards, William
Thanks, William. I will take a look!
Just one other thought: since the name of the package you are using is 'eeg-pipes', that implies a buffering of information from one processing block to another. There may be something screwing up in the buffering operation of the FFT. Such that the output is not delivered at a constant rate. Thus a type of stuttering.
Hi William,
I am sorry I don't understand what it really means. Does that mean I need to change the name of the package to something else? Why would it block information being processed?
My last comment was trying to convey that there may be possible bugs in the way eeg-pipes actually 'buffers' information flow (through the 'pipes'). Such that there could be loss of data or erratic latency. Suggest you contact Alex for advice.