Studio Tutorial: Assigning Events to Bins - ucdavis/erplab GitHub Wiki

When we create an ERPset containing averaged ERP waveforms, we often want to combine trials with different event codes into the same average. For example, the N400 experiment used separate event codes to indicate which of the two word lists was used for a given trial, but we want to average together the trials from the different word lists.

Also, we won’t be making averages for the response event codes, but we want to use those codes to exclude trials with incorrect responses from our averaged ERPs. Thus, we need a sophisticated way of indicating which events should be combined together when we average the data to create an ERPset. We call this process assigning events to bins, and ERPLAB accomplishes this with a routine called BINLISTER (click here for details of how BINLISTER works).

A bin is a set of averaged ERP waveforms—one for each electrode site—that were created by averaging together a specific set of trials. In our N400 experiment, for example, we will create four bins:

• Bin 1: Primes followed by a related target
• Bin 2: Primes followed by an unrelated target
• Bin 3: Targets preceded by a related prime and followed by a correct response
• Bin 4: Targets preceded by an unrelated prime and followed by a correct response

The ERP CORE N400 dataset has 30 channels, so each bin in the ERPsets will have 30 averaged ERP waveforms, one for each channel. For all 30 channels in a given bin, we will average together the same set of trials.

The bins for a given participant are stored together in an ERPset, along with some “header” information (e.g., the sampling rate, the subject ID). Here’s a graphical representation of how the information is structured in an ERPset (taken from Chapter 2.6 in Applied ERP Data Analysis).

We can create additional bins based on the original bins (e.g., difference waves) after we create the averaged ERPs using the Bin Operations tool.

We’re now going to run BINLISTER to sort the events in the current EEGset into bins. After we’ve done that, we’ll take a look at how BINLISTER determines how to sort the event codes into bins. Make sure that 6_N400_filt_elist is selected in the EEGsets panel and go to the Assign Events to Bins (BINLISTER) panel.

The first step is to load a bin descriptor file (BDF), which tells BINLISTER how to assign the event codes to bins. Click on the Browse button and select the file named BDF_N400.txt (which should be in the same folder as the tutorial data). Then click the Run button. You will then see the standard window for naming the EEGset that will be created by this operation. Click Okay to confirm the name of the new EEGset (which adds _bins to the end of the previous EEGset name).

BINLISTER then runs. In some situations, it can take quite a while to run. While it is running, a ton of information is printed in the Matlab Command Window. This information can be helpful in making sure that BINLISTER is doing what you want it to do.

After BINLISTER is complete, the panel will show the number of trials that were assigned to each bin (as shown in the screenshot above). You will also be able to see the new EEGset in the EEGsets panel (6_N400_filt_elist_bins).

Pro tip: You should always check the number of trials per bin for each subject to make sure you have the expected number of occurrences for each bin. This will help you catch many kinds of problems, such as subjects who didn’t understand the task, faulty response hardware, missing event codes, and errors in the stimulus presentation script. It’s important to catch these problems right away so that they don’t ruin your whole experiment.

BINLISTER saves the bin information in the EventList. Take a look at which bin was assigned to each event by going to the EventList panel and clicking the View button.

You can see that the bin column for the individual events (at the far right of the window) now indicates which bin (if any) a given event has been assigned to. When an event is assigned to a bin, this means that the event is the time-locking event for that trial. In other words, the time of the event code will be time zero in our averaged ERP waveforms.

The first two events both have code 202, which is the code for an incorrect response (see table of events codes in the description of the experiment). This subject just pressed the response button randomly a couple times before the experiment began, generating these event codes. These events are not assigned to any bins.

Event #3 has an event code of 121, which means that it is a prime word that will be followed by an unrelated target word, with the word taken from the first word list. It was assigned to Bin 2 (“Primes followed by an unrelated target”). When we eventually make averaged ERP waveforms for these data, we’ll use this event code as time zero in the waveform, allowing us to see the brain activity time-locked to the prime.

Now look at item #4 on the next line. It has an event code of 221, and it was the target word that followed the prime word from item #3. The next event (#5) is the response on that trial, with an event code of 201 indicating that it was a correct response. The combination of code 221 for event #4 and code 201 for event #5 indicates that event #4 should be assigned to Bin 4 (“Targets preceded by an unrelated prime and followed by a correct response”). Again, the bin number is placed on the line for the event that serves as the time-locking point for that trial.

Event #5 is a response event, and we are not time-locking to the responses in this analysis, so it is not assigned to a bin (even though this event was used to determine that event #4 was followed by a correct response). If we wanted to compute response-locked averages, we could instead make event #5 the time-locking event. The file BDF_N400_resplocked.txt shows how to make response-locked bins with the N400 dataset (which is possible only for the targets, because the primes are not followed by responses). Note that there is a “trick” for using the prestimulus baseline in response-locked averages, as described in the Tutorial page on Converting Epoched to Continuous Data.

How did BINLISTER know what bins we wanted and which event codes should be assigned to each bin? To accomplish this, BINLISTER used a set of bin descriptions that are stored in the BDF_N400.txt file that you entered in the BINLISTER panel. The BDF at the beginning of the filename stands for bin descriptor file, because it is a file that contains an abstract descriptor for each bin.

Double-click the BDF_N400.txt file in the Current Folder area of the main Matlab window to open it in a text editor. Here’s what you should see:

Bin 1
Prime word, related to subsequent target word
.{111;112}

Bin 2
Prime word, unrelated to subsequent target word
.{121;122}

Bin 3
Target word, related to previous prime, followed by correct response
.{211;212}{t<200-1500>201}

Bin 4
Target word, unrelated to previous prime, followed by correct response
.{221;222}{t<200-1500>201}

The details of the bin descriptor file syntax are described in the BINLISTER Overview and Chapter 6 of Applied ERP Data Analysis, but some aspects of the syntax are fairly obvious here. Each bin is described with three lines. The first line just gives the bin number. The second line is a text label that describes the contents of the bin (and can be whatever you want). The third line is the actual bin descriptor.

Each bin descriptor contains one or more event codes inside curly brackets. For example, Bin 2 contains 121;122 inside the curly brackets, indicating that event codes 121 or 122 should be used as the time-locking event for this bin. Bins 3 and 4 contain a second set of curly brackets that indicate what must follow the time-locking event code. The text t<200-1500>201 means that the time-locking event code must be followed within 200-1500 ms by an event code 201. For example, an event code of 221 will be assigned to Bin 4 if and only if it is followed by a correct response (event code 201) within 200 to 1500 ms.

BINLISTER reads in the bin descriptor file and then goes through all of the event codes in the EventList. When it finds an event code that matches the bin descriptor for a given bin, it puts that bin number into the bin column for that event code. Note that a given event code can be assigned to more than one bin. For example, we could have one bin for target words that are followed by a correct response and a separate bin for target words irrespective of whether the response was correct.

Now that you’ve seen the basics, it’s a good idea to go through the EventList in detail and make sure you understand why a given event was assigned to a given bin (or to no bin).