Pairing the MUSE With Your Laptop
The MUSE must be "paired" via Bluetooth with your laptop before experiments can be run.
Open System Preferences, and click on Bluetooth to get to the following screen.
Open System Preferences, and click on Bluetooth to get to the following screen.
Press and hold the power button on the MUSE for about 5 seconds, until all five of the LEDs on the right ear piece are flashing in unison.
The Muse should now appear in the Bluetooth pairing screen (above left) with an option to Pair. Click the Pair button for your Muse. It should then say "Connected" as in the above right image.
Pairing usually only needs to be done the first time a Muse is used with a specific laptop. Thereafter, simply turning the Muse on by pressing and releasing the power button will cause it to automatically connect with the previously-paired computer.
More help on Bluetooth and MUSE can be found on InterAxon's developer site.
The Muse should now appear in the Bluetooth pairing screen (above left) with an option to Pair. Click the Pair button for your Muse. It should then say "Connected" as in the above right image.
Pairing usually only needs to be done the first time a Muse is used with a specific laptop. Thereafter, simply turning the Muse on by pressing and releasing the power button will cause it to automatically connect with the previously-paired computer.
More help on Bluetooth and MUSE can be found on InterAxon's developer site.
Connecting to the MUSE from the Terminal Application
For more information on muse-io and other research programs provided by InterAxon, see their documentation here.
Direct links: Go here for more detail on muse-io and here for a full list of muse-io commands.
First, open the Terminal app on your laptop. Terminal ships with Mac OS X and can be found in the Applications folder, or in Launchpad, or by typing "terminal" into Spotlight.
Next, type the following command at the Terminal prompt to begin communicating with MUSE.
muse-io --no-dsp --preset AD --osc osc.udp://localhost:5555 --device Muse-XXXX
This commands tells muse-io to pair with the MUSE with the name Muse-XXXX (--device Muse-XXXX). Replace XXXX with the ID number of your MUSE which can be found on your Bluetooth connections page.
The command also specifies --no-dsp. This command disables the onboard signal processing. We recommend this because we want to run the MUSE at 500Hz and the algorithms on the MUSE cannot process at 500Hz.
The next part of the command, --preset AD, specifies the settings for MUSE that we recommend. You can see a full set of the preset options here (dev.choosemuse.com/hardware-firmware/headband-configuration-presets). Note, our code is currently designed to work with a 2014 MUSE hence the AD preset. We use this preset to get the higher sampling rate and to turn off any onboard signal processing.
The other part of the command, --osc osc.udp://localhost:5555 opens up a port on the local machine (port 5555). muse-io will send the incoming data from the MUSE to port 5555 where listening programs can access the data.
Once you enter the above command, you should see a message saying the connection with MUSE is open and you should see a screen that looks like this:
Next, type the following command at the Terminal prompt to begin communicating with MUSE.
muse-io --no-dsp --preset AD --osc osc.udp://localhost:5555 --device Muse-XXXX
This commands tells muse-io to pair with the MUSE with the name Muse-XXXX (--device Muse-XXXX). Replace XXXX with the ID number of your MUSE which can be found on your Bluetooth connections page.
The command also specifies --no-dsp. This command disables the onboard signal processing. We recommend this because we want to run the MUSE at 500Hz and the algorithms on the MUSE cannot process at 500Hz.
The next part of the command, --preset AD, specifies the settings for MUSE that we recommend. You can see a full set of the preset options here (dev.choosemuse.com/hardware-firmware/headband-configuration-presets). Note, our code is currently designed to work with a 2014 MUSE hence the AD preset. We use this preset to get the higher sampling rate and to turn off any onboard signal processing.
The other part of the command, --osc osc.udp://localhost:5555 opens up a port on the local machine (port 5555). muse-io will send the incoming data from the MUSE to port 5555 where listening programs can access the data.
Once you enter the above command, you should see a message saying the connection with MUSE is open and you should see a screen that looks like this:
A simple check that you have a working connection is two part. One, the text at the bottom of the terminal screen should be in green and two, the number after "bits/second" should be changing every second, but be above 40,000.
If you see red text instead of green, or see the number of dropped samples continuously increasing, something is wrong with the connection and must be fixed before you continue this tutorial. Please consult InterAxon's documentation on muse-io here.
If you see red text instead of green, or see the number of dropped samples continuously increasing, something is wrong with the connection and must be fixed before you continue this tutorial. Please consult InterAxon's documentation on muse-io here.
Collecting MUSE data with MATLAB
Once the connection with MUSE is open, it is relatively easy to get MUSE data into MATLAB. However, before we review the process let's have a quick discussion on methods. In an ERP study, one wants to get data time-locked to an event, typically from a brief period of time before the event (the baseline: ~200 ms) and from a longer period of time after the event (~ 800 ms). The way this is done is quite simple, the EEG amplifier samples the data and passes it along to recording software on one computer. A second computer runs an experimental task which is what the participant is there to do. The key to making it all work, is to send a signal from the participants computer to the recording computer to mark exactly when events occur--in the ERP world these are called event markers. However, the markers need to be extremely precise; most laboratories want a timing accuracy of less than 0.5 ms with a similar standard deviation (< 0.5 ms). The reason for precision is simple, if there is "jitter" (noise) in the markers then there will be noise in the signal, and once averaged, the jitter will lead to a reduction in the amplitude of observable ERP components. In some cases, if the jitter is very bad, one may not even see ERP components at all. If the reader is interested in this issue, I would strongly recommend purchasing and reading Steve Luck's book, An Introduction to the Event Related Brain Potential Technique.
With MUSE, it is not easy to "mark" the data. With the OSC code we use, it actually is in principle possible to mark the data by writing an OSC message to the data stream. However, we chose to not use this approach and all we do is record MUSE data before and after an event. In other words, we record some data (200 ms), then we do something interesting--draw a circle for instance, then we collect 800 ms of data after the event from MUSE. Up front, we are well aware that this inserts jitter into the data; there is a gap in time between the baseline, when the image is drawn, and when we start getting data.
A further issue is related to Bluetooth itself as the timing of messages sent over Bluetooth is not constant. Bluetooth technologies break continuous data into "packets" which are then set out over the communication protocol. You can learn the basics of Bluetooth technology here (electronics.howstuffworks.com/bluetooth.htm) and a lot more about Bluetooth data streaming here (developer.choosemuse.com/protocols/data-streaming-protocol) and Bluetooth data protocols here (developer.choosemuse.com/protocols/bluetooth-packet-structure). However, the problem that we face is that the timing of the data packets is not consistent - specifically, a packet is not transferred at the same exact point in time each time. Thus, there is jitter in the timing of the packets.
Here, we are aware of the issue and are just going to ignore it just as we ignored the marker issue. The logic is simple: if the jitter in both of these elements is indeed random--and it is--then the timing jitter should simply average out, assuming it is not uniformly distributed. What we do then, is after our event of interest occurs, we read in 100 data samples before and 400 data samples (1 second of data with a 500MHz sampling rate) and assume that on average this reflects an accurate representation of the EEG response to stimuli. So, on to collecting data.
To read MUSE data into MATLAB is quite simple and requires three steps:
1. Open a connection with MUSE via the OSC software.
2. Read in data.
3. Close the OSC connection.
Here is a simple bit of MATLAB code to do these three steps and read in one second's worth of data. You can find an m-file of this code including comments here (muse_test.m).
With MUSE, it is not easy to "mark" the data. With the OSC code we use, it actually is in principle possible to mark the data by writing an OSC message to the data stream. However, we chose to not use this approach and all we do is record MUSE data before and after an event. In other words, we record some data (200 ms), then we do something interesting--draw a circle for instance, then we collect 800 ms of data after the event from MUSE. Up front, we are well aware that this inserts jitter into the data; there is a gap in time between the baseline, when the image is drawn, and when we start getting data.
A further issue is related to Bluetooth itself as the timing of messages sent over Bluetooth is not constant. Bluetooth technologies break continuous data into "packets" which are then set out over the communication protocol. You can learn the basics of Bluetooth technology here (electronics.howstuffworks.com/bluetooth.htm) and a lot more about Bluetooth data streaming here (developer.choosemuse.com/protocols/data-streaming-protocol) and Bluetooth data protocols here (developer.choosemuse.com/protocols/bluetooth-packet-structure). However, the problem that we face is that the timing of the data packets is not consistent - specifically, a packet is not transferred at the same exact point in time each time. Thus, there is jitter in the timing of the packets.
Here, we are aware of the issue and are just going to ignore it just as we ignored the marker issue. The logic is simple: if the jitter in both of these elements is indeed random--and it is--then the timing jitter should simply average out, assuming it is not uniformly distributed. What we do then, is after our event of interest occurs, we read in 100 data samples before and 400 data samples (1 second of data with a 500MHz sampling rate) and assume that on average this reflects an accurate representation of the EEG response to stimuli. So, on to collecting data.
To read MUSE data into MATLAB is quite simple and requires three steps:
1. Open a connection with MUSE via the OSC software.
2. Read in data.
3. Close the OSC connection.
Here is a simple bit of MATLAB code to do these three steps and read in one second's worth of data. You can find an m-file of this code including comments here (muse_test.m).
When you run the code above, when it is done, you will have a variable 'eeg' that has 4 rows (channels) and 500 columns (500 samples of data). Note, the numerical values you see are in MUSE units and have no real meaning. To quickly convert them to microvolts you need to subtract the mean of each channel from the data for the channel (~ 800 MUSE units, the DC component) and then multiply the remaining values by 1.64498 to convert them to microvolts. For interest, you should also look at the variable 'muse_data' to see the full data that is sent from the MUSE.
Visualizing the EEG data stream in MATLAB to assess data quality
We have written a small program to visualize the EEG data stream, similar to what you can do in MUSELab. However, in our program the colour of the channel data indicates whether it is "good" or "bad". Good data is coloured green and bad data is coloured red. Our assessment of good or bad is based on a computation of variance. We compute the variance for the channel as the variance of the data over 500 samples (1 second). We examined all of our pilot data and determined that a variance of 200 or less is desirable. Note, this is a "good guess" and not an exact value. We chose this value as it ensured that a blink would result in "bad" data. We also chose this value as our analyses of ERP data revealed that data with a variance greater than this tended to be a bit noisy.
The code to visualize the data stream is here (CHECK_MUSE.m). With a MUSE connected, running this code should result in a visualization screen that looks like the image below. Note, you will also need to have the file scale_eeg.m in the path which you can download here (scaleeeg.m).
The code to visualize the data stream is here (CHECK_MUSE.m). With a MUSE connected, running this code should result in a visualization screen that looks like the image below. Note, you will also need to have the file scale_eeg.m in the path which you can download here (scaleeeg.m).
The image above shows our CHECK_MUSE.m file running. You will note the yellow colour suggests that the variance values are somewhere between an ideal and a bad value. We also note here that our stated criteria of 200 uV/ms2 is not an exact value - it is just a guideline range that we use.
Sample Experimental Task: Oddball
Here we provide the code to run the visual oddball paradigm while capturing data from MUSE. You will need to first complete all of the steps above to ensure there is an open Bluetooth connection with MUSE via muse-io before running the experiment script.
Oddball Version 1: Recording of MUSE Data in MATLAB
MUSE_ODDBALL.m
The m-file above will run a simple visual oddball task and record trial data from the MUSE before and after each trial. In brief, the program shows a series of coloured circles (blue, green). Participants need to count the number of target circles (the infrequent blue oddballs). The number of blocks and the number of trials per block can be changed by changing the values of the variables "number_of_blocks" and "trials_per_block". The percentage of trials that are infrequent can also be changed within the code - the default setting is 0.25 using the variable "oddball_probability". The output .may file has several variables that contain the oddball EEG, the control EEG, the concatenated EEG, and the markers. Finally, there is a file created that contains behavioural data.
In brief, the code does the following:
1. Opens a OSC server on port 5555 to read in MUSE data
2. Opens a Psychtoolbox Window for graphical drawing
3. Defines some useful variables
4. Starts a block loop
5. Starts a trial loop within the block loop
6. On each trial:
i. Randomly decide if a given trial is an oddball trial
ii. Draw a fixation cross
iii. Record the baseline data (200 ms)
iii. Draws a circle (coloured appropriately)
iv. Record 800 ms of EEG data
7. Saves the EEG and behavioural data to a variable
8. Ends the loops
9. Closes all windows, saves all data to the filesystem.
Oddball Version 1: Recording of MUSE Data in MATLAB
MUSE_ODDBALL.m
The m-file above will run a simple visual oddball task and record trial data from the MUSE before and after each trial. In brief, the program shows a series of coloured circles (blue, green). Participants need to count the number of target circles (the infrequent blue oddballs). The number of blocks and the number of trials per block can be changed by changing the values of the variables "number_of_blocks" and "trials_per_block". The percentage of trials that are infrequent can also be changed within the code - the default setting is 0.25 using the variable "oddball_probability". The output .may file has several variables that contain the oddball EEG, the control EEG, the concatenated EEG, and the markers. Finally, there is a file created that contains behavioural data.
In brief, the code does the following:
1. Opens a OSC server on port 5555 to read in MUSE data
2. Opens a Psychtoolbox Window for graphical drawing
3. Defines some useful variables
4. Starts a block loop
5. Starts a trial loop within the block loop
6. On each trial:
i. Randomly decide if a given trial is an oddball trial
ii. Draw a fixation cross
iii. Record the baseline data (200 ms)
iii. Draws a circle (coloured appropriately)
iv. Record 800 ms of EEG data
7. Saves the EEG and behavioural data to a variable
8. Ends the loops
9. Closes all windows, saves all data to the filesystem.
Sample Experimental Task: Two-Armed Bandit
decision_making.m
Here we provide the code for another experimental task. This task is a standard two-armed bandit reward learning task. The ERP events of interest are the feedback stimuli indicating wins and losses. In this example we only record data from MUSE directly into MATLAB.
Here we provide the code for another experimental task. This task is a standard two-armed bandit reward learning task. The ERP events of interest are the feedback stimuli indicating wins and losses. In this example we only record data from MUSE directly into MATLAB.