Recorded File different from the GUI screen
laerciosilvajunior
Brazil
Hi everyone.
I have just performed my first experiment and the result is not what I expected.
First of all, let me describe my equiment: The board is the OpenBCI 32bit Board and there is the option to use it together with the Daisy Module, but I did not use, hence, the teste was made with 8 channels . I also used the gold cup electrodes and the paste.
When the test was running I was whatching the EEG signals on the OpenBCI_GUI and they were OK. After that I opened the recorded file to see the data and the values were different, all the values were in a crescent order and when I opened the file with OpenBCI_GUI the EEG signals were not the same that I saw when I was performing the teste. The channels 1 and 3 were repeated, the same thing happened with channels 2 and 4.
Does someone know what is wrong? How can I solve this problem?
Thank you in advance.
Comments
I will try to remove the DC offset from my data.
> the values were different, all the values were in a crescent order
Here I tried to say that the values had a range from -14000 to 35000, always increasing.
I would like to ask something that is simple that I have seen in other topics but its not clear for me:
Which are the sample rate? 250Hz or 256Hz? In the header of the data file is written 250Hz, but the first column starts with 0 and ends with 255, making 256Hz.
Another question is: If I use the Daisy Module to use 16 channels together, will the sample rate be the half of the sample rate with 8 channels?
Thank you again.
Laercio
Thank for you answer
One last doubt, at least hope so, rs.
A good test to do is to short all your leads together (channels and SRB2 plus Bias). This can be done with a glob of paste or clips, etc. Result should be a signal close to 0 uV.
Use the search box at right to lookup: neuromore, BrainBay and OpenViBE. These are all VPL, visual programming languages that allow you to do signal processing without programming.
So with this recording you made with all the channels and SRB2, Bias connected together. Does your file look like all the "close to 0 uV" values are recorded correctly? Or do you see the even channels as having large variation? It sounds like the GUI is getting the correct data stream from the dongle and displaying correctly when running live.
But the creation of the recording file is distorting the even channels saved onto the file, so when you play that back, you see the even channels messed up. Does that sound like what you are seeing?
You could also try a test with 'neuromore'. Use the search box at right for a tutorial.
Please try the first suggestion to see if the Processing binary or source might be corrupt.
Thanks,
I have 3 different OS installed in 3 different machines and I will tell what is happening
re: your remark on pre-compiled vs build from source and libraries.
The zip files on the download page, are "ready to run" without needing the steps to build from source as shown on,
https://github.com/OpenBCI/OpenBCI_Processing
It's possible that if you use the steps shown on the github page above, the result may be correct vs. what you are finding with the zips. That is what I would suggest trying next on your Windows 10 and Linux. The instructions on the Github page say to use the latest stable Processing, which is 3.0.2, not 2.2.1.
I'm going to mention @Conor and Joel @biomurph here, as it appears that the zip files are having issues on Windows 10 and your particular Linux. (But the zip runs ok on Windows 7.) By rebuilding directly from the Github instructions, let us know how that works for you.
William
I tried to install the version 3.0.2 but it did not work. The same problems that I had before keep appearing.
So I installed the version 2.2.1 with all folder that I have when I downloaded it in Oct, 2015 and its fine. So far my problem is solved.
I did not understand what is happening in the map on the right side of the OpenBCI_GUI, My signal is stronger in channels 1 and 2 but the color red and blue do not make sense. What is the right way to analyze this map?
Thank you again.
Laercio
That's great you found a workaround. I guess you are right, Processing 2.2.1 is required to agree with the external library setup. So you say that it is now working on your Windows 10 and Linux machines?
The head map contour algorithm is here,
https://github.com/OpenBCI/OpenBCI_Processing/blob/master/OpenBCI_GUI/HeadPlot.pde
This is Chip @chipaudette 's code. I believe dark red is indicating RAILED or out of range. And the working electrodes are "averaged" into a kind of "heat map" using a color scale ranging in shades from blue to white to red. So depending on the overall range of your channel amplitudes, you could see any shade in that range.
Chip might comment here. I think it would be helpful to have a sentence on how the colors are interpreted on the docs site.
William
First of all thank you for all your answers.
Now I have Processing 2.2.1 installed in Win10 and Linux as you said.
I have been asking a lot a question in the same topic that I opened, but the subject changed, is it OK?
Now I have a different doubt. I changed a little bit the code just to save the TimeStamp of the data and I saw something different. I have a line with 18:40:19.365 and my next line has 18:40:19.802, hence, I have 437ms without data. what is happening?
And another question, my first line of data (I am not considering the header) the Timestamp is 18:40:17.405 and after one second my Timestamp is 18:40:18.405, but I have 353 line between them, if my frequency is 250Hz, Shoudn't I have 250 lines between them?
Once again, thank you a lot. Its working just fine, maybe 1ms of delay but the world is not perfect, hahaha
The only doubt that I have now is related to HeadPlot.pde file that I tried to read but I did not understand what happens with the map in the OpenBCI_GUI
I have one doubt that is related to this old topic.
I have permorfed an experiment with Daisy Module and I saved the timestamp for each line of data. I saw that the difference bewwen the lines is 4ms, the same difference when I do not use Daisy Module, hence, in this case my frequency is 250Hz. I was expecting 8ms of difference
But when talked few months ago, you told me that the frequency would be 125Hz, half of the frequency using just 8 channels. What is the real frequency using Daisy Module?
Another question, I was looking at the website and its written that the frequency is 250Hz, but because of the 16 channels the file saves the data per module, which means, it saves the first 8 channels and after some time 8 more channels. Am I right to have this thought?
Thank you,
Laercio
I have just seen that some lines are repeated, 2 lines in a row have the same values for the 8 first channels for examples. So I think that we have something like this: Its necessary to get to 8 first values of one line and the 8 last values of he next line to have the original signal, because of that the frequency is the half of the frequency without Daisy Module
I had the same problems as you have now and I solved this using the following code in python:
#2 x (fc/wc), fc = freq de corte desejada e wc = freq do sinal#
bp_stop_Hz = np.array([59.0, 61.0]) #filtro rejeita faixa que será usado posteriormente
###Canal 1###
#número ¨2¨ é referente a ordem do filtro, 0.008 é referente a frequencia de corte que é 0.5Hz
b, a = scipy.signal.butter(2, 0.008, btype='highpass')
output_signal = scipy.signal.filtfilt(b, a, chan1)
#número ¨2¨ é referente a ordem do filtro, 0.8 é referente a frequencia de corte que é 50Hz
b, a = scipy.signal.butter(2, 0.8, btype='lowpass')
output_signal2 = scipy.signal.filtfilt(b, a, output_signal)
# create the 60 Hz filter
Some of the comments are in Portuguese, if you need any help can help. In this case I used the OpenBCI board + Daisy Module.
My friend used the EEGLAB toolbox for Matlab and she told me that it worked for her.
Best Regards,
Laercio