ERPLAB Studio: Boundary Events and Disabled Events - ucdavis/erplab GitHub Wiki

EEGLAB defines a special kind of event called a boundary event that marks a discontinuity in the EEG data. Boundary events are created automatically by EEGLAB when portions of the EEG are rejected from a continuous dataset or when multiple continuous datasets are concatenated. If your EEG acquisition system puts some kind of event code into the file when digitization is paused, ERPLAB can convert this code into a boundary code when the EVENTLIST is created. Boundary events are important, because there will usually be an artifactual jump in voltage across the boundary, and you would not want to include this segment of EEG data in your averaged ERPs. Filter artifacts can also occur if boundaries are not taken into account during filtering (see the Filtering Overview).

ERPLAB has inherited and extended this concept. When you create an EVENTLIST structure, any boundary events in the dataset will be included in the EVENTLIST structure, with an event code of -99 and a label of 'boundary', by default. You can use different values, but ERPLAB will only recognize the default values.

Boundary events are also inserted by EEGLAB when you delete segments of continuous EEG data. For example, you might delete segments of EEG that contain movement artifacts prior to ICA-based artifact correction, and boundary events are inserted at the deletion points. Again, you would not want epochs containing these boundaries to be included in your ERP averages.

It is important to ensure that a boundary event is placed in the EEG structure at the boundaries between different trial blocks (assuming that data collection was paused between blocks). If each block was originally stored in a separate data file, this will happen automatically if you append the files together into a single dataset using the EEGsets panel. However, if you record multiple blocks into a single file during data acquisition, your data acquisition system may not place a special event code between blocks to represent boundaries. In this case, you should have your stimulus presentation put a specific event code at the appropriate time. You can then use the Advanced button when you create the EVENTLIST to convert this code into a code of -99 and a label of 'boundary'. (This approach can also be used if your data acquisition system puts in a code automatically but does not use the string 'boundary' or the numeric code -99.)

ERPLAB does several things to ensure that data segments containing boundaries are excluded from the averaging process. First, when the BINLISTER routine assigns events to bins, it will not assign a given event to a bin if it encounters a boundary event in the sequence of events that define the bin. For example, if Bin 1 is defined as event code 100 followed 200-1000 ms later by event code 200, a given event code of 100 will not be assigned to Bin 1 if a boundary event occurs between the event code 100 and the event code 200. However, this does not eliminate a boundary if it occurs after the response but before the end of the epoch. Thus, ERPLAB also checks for boundary events during the epoching process, excluding any epochs that have boundary events at any point during the epoch. ERPLAB does a final check during averaging, re-checking for boundary events in the epoched data and excluding any epochs that contain boundaries.

ERPLAB allows you to mark other kinds of problematic events using the enable field of the EVENTLIST structure. If you set the enable value to -1 for a given event, that event will be treated just like a boundary event (in BINLISTER, in bin-based epoching, and in averaging). In addition, it is also possible to set the enable value to zero. This means that the event should be ignored, as if it did not exist. This impacts the operation of BINLISTER, of course, because events with an enable value of zero will be ignored. The bin-based epoching and averaging procedures will also exclude any epochs when the enable value for the time-locking event is sent to zero. However, if other events during the epoch have an enable value of zero, those events are ignored, so the epoch will not be excluded. This is the main difference between enable values of 0 and -1: the epoch will be excluded if the time-locking event has an enable value of either 0 or -1, but other events in the epoch will cause the epoch to be excluded only if they have an enable value of -1. The logic here is that 0 means ignore the event, and -1 means that the invalid data is present at the time of the event.

To set the enable value to 0 or -1, you can either write a script that accesses the EVENTLIST structure directly or export the EVENTLIST to a text or .xls file, edit the EVENTLIST, and then import the edited version.