/muse/eeg single pasing on to FFT to get a Frequency how and what to do


#1

Dear all,

I still have a question on how to process the /muse/eeg single I get from the muse.
I need to get the Frequency from every time it is given.

Any one know the SamplingWindowsStep, Bitrate and the buffersize to use for a FFT calculation on the /muse/eeg?

I was using the MuseIO v3.4.0 and it worked fine with the /muse/dsp/bandpower/raw_fft0 to 3, but after it changed in version 3.6.0 to the /muse/elements/raw_fft0 to fft3 it had a overlap of 90% and it my FFT calculation gave me not any more the correct frequencies. So I like to work now on the /muse/eeg singel to get the Frequencies by FFT.

Still I don’ d see how to calculated them correct.

Any help?

Hans


#2

Hi HvM,

​The sample rate is 220 samples per second. The FFT window is a sliding 256 sample Hamming window with 90% overlap. The overlap is in time, it shouldn’t affect which bins correspond to which frequencies.

What do you mean when you say you can’t get the correct frequencies any more? If you are wondering you to calculate the frequencies that the bins in the raw_fft arrays correspond to, it works like this (to quote from a previous post of mine):

The FFTs are calculated using a 256 sample window, which gives a transform that has 256 components and is symmetric (i.e. mirrored) around an additional component at 0Hz. In other words, you have 128 components, followed by one for 0Hz, and then the mirror image of the same components. This means you need only consider half of them (because the other half are the same, only reflected) plus the one for 0Hz at the centre, which gives you 129 in total.

To get the frequency resolution for the bins, you can divide the sampling rate by the FFT length, so in the case of Muse: 220/256 ~ 0.86Hz/bin

So, the zeroth index of the FFT array represents 0Hz, the next index represents 0-0.86Hz, and so on up to 128*0.86 = 110Hz, which is the maximum frequency that our FFT with its 220Hz sampling rate can detect.

Hopefully this info is helpful, and I didn’t misunderstand your question!


#3

Dear Tom,

I like to set the Muse-IO so I have only the following:
/muse/eeg single
/muse/elements/horseshoe single
/muse/eeg/quantization integer
/muse/batt integer

I use this commant:
muse-io.exe --device Muse --no-dsp --50hz --osc osc.udp://localhost:5000, osc.udp://localhost:5000/muse/elements/horseshoe
But there is no /muse/elements/horseshoe single

I can only use:
muse-io.exe --device Muse --dsp --50hz --osc osc.udp://localhost:5000
But then I get all other data, and my buffers are quickly overloaded.

Hope there is a solution for this.

All the best,
Hans


#4

Hi HvM,

The --osc flag specifies which IP and port to send all messages that muse-io produces to. By providing an address path with “osc.udp://localhost:5000/muse/elements/horseshoe” you are actually saying that all messages should be sent under the custom address path /muse/elements/horseshoe to port 5000.

MuseIO considers this to be invalid, and in fact, if you provide that as the only argument to the --osc flag, MuseIO will throw an error. Looks like when you provide multiple arguments to the --osc flag and one of them is invalid, MuseIO doesn’t catch it and exit properly. We’ll include a fix for that in the future.

There are several different flags for sending different data types to different OSC URLs. From the MuseIO help menu (accessible by typing “muse-io.exe --help”):

  --osc-acc-urls arg     Output accelerometer to OSC. Multiple URLs can be
                           specified, comma delimited, with a path.
                           e.g. 'osc.tcp://localhost:4444/dsp/ac,...'
                          
    --osc-status-urls arg  Output status messages to OSC. Multiple URLs can be
                           specified, comma delimited, with a path.
                           e.g. 'osc.tcp://localhost:4444/stat/muse1,...'
                          
    --osc-config-urls arg  Output configuration state messages to OSC. Multiple
                           URLs can be specified, comma delimited, with a path.
                           e.g. 'osc.tcp://localhost:4444/cfg/muse1,...'
                          
    --osc-battery-urls arg Output battery messages to OSC. Multiple URLs can be
                           specified, comma delimited, with a path.
                           e.g. 'osc.tcp://localhost:4444/batt/muse1,...'
                          
    --osc-drlref-urls arg  Output drlref messages to OSC. Multiple URLs can be
                           specified, comma delimited, with a path.
                           e.g. 'osc.tcp://localhost:4444/drlref/muse1,...'
                          
    --osc-quant-urls arg   Output compression quantization messages to OSC.
                           Multiple URLs can be specified, comma delimited, with
                           a path.
                           e.g. 'osc.tcp://localhost:4444/dsp/eeg,...'
                          
    --osc-eeg-urls arg     Output EEG messages to OSC. Multiple URLs can be
                           specified, comma delimited, with a path.
                           e.g. 'osc.tcp://localhost:4444/dsp/eeg,...'
                          
    --no-dsp               Disable DSP algorithms.
                          
    --dsp                  Enable DSP algorithms (default).
                          
    --osc-bp-urls arg      Output MuseElements DSP messages to OSC. Multiple URLs
                           can be specified, comma delimited, with a path.
                           e.g. 'osc.tcp://localhost:4444/dsp/bp,...'

So you can specifically control where raw EEG, quantization, and battery data get sent. As for the horseshoe, it doesn’t have any such flag available for it.

There are a few options for filtering specific messages. Both MusePlayer and MuseLab have that functionality.

To filter by path in MusePlayer use the -i option:

    -i FILTER_DATA [FILTER_DATA ...], --filter FILTER_DATA [FILTER_DATA ...]
                          Filter data by path. e.g. -i /muse/elements/alpha
                          /muse/eeg

To filter by path in MuseLab, check out the “Outgoing” tab in the OSC menu.

​Finally, you can also just choose in your own software not to consider messages that don’t match the address paths you’re interested in. For example, in the Python example on the Getting Started page of developer.choosemuse.com, you could just make the “fallback” function do nothing. Then all irrelevant paths would be effectively ignored. This is probably the simplest way to handle this, IMO.

(EDIT: Although be warned that getting pyliblo to work on Windows is often difficult. I mentioned that example only to illustrate the point that you can ignore messages in your own code)


#5

Dear Tom,

After many month testing the Muse system, we fount the way how to use the Muse EEG system so it returns the same information we are getting from the EEG Scanners we ware use to work with.
The settings we use is as follow.

muse-io.exe --device Muse --dsp --50hz --no-scale --osc osc.udp://localhost:5000

I hope only your company will never remove the --no-scale option, this we found out is the best way we can handle the signals from the muse.
Now after many month testing the muse on patient’s we can role out the application for a field test on the modification we have made to use the muse as a alternative to the expensive other EEG devices we advice to use with the software.
I hope to be as positive as we are now after the field test we are starting now.

Thanks for all your help and support you and your team have given us.