Predict Before You Run: Debugging an EEGLAB/ERPLAB Script

Brian Rivera, St. Olaf College, Psychology
Author Profile
Initial Publication Date: October 6, 2026
DOI | Cite this

Summary

Students who have just processed one EEG participant through the EEGLAB and ERPLAB menus receive a MATLAB script that repeats the same steps in code: importing a BrainVision recording, filtering, re-referencing, creating an Event List, assigning bins, and epoching with baseline correction. The script contains ten planted bugs. Four stop MATLAB with an error, one runs and causes an error one section later, and five run without complaint and give a wrong result. Before running anything, students write a comment under every line predicting whether it will run, why, which GUI step it matches, and whether the result would match what they did in the GUI. They submit these predictions and then receive an answer Live Script that runs each buggy line inside try/catch, explains the problem, shows the effect of each silent bug in a figure or a number, and runs the fix. The activity ends with students comparing their script result to the dataset they saved from the GUI. The goal is for students to work out what a line does to the data before they trust it.

Key terms: EEG, ERP, event-related potentials, EEGLAB, ERPLAB, MATLAB, debugging, code reading, predict-observe-explain, preprocessing, filtering, re-referencing, epoching, baseline correction, BINLISTER, MATLAB Live Script, reproducibility

Share your modifications and improvements to this activity through the Community Contribution Tool »

Learning Goals

Content and concepts. Students connect each line of a preprocessing script to the GUI step it replaces and to what that step does to the data: what a low-pass cutoff removes, why the average reference makes the channels sum to zero at every time point, why the Event List must exist before events can be sorted into bins, what the baseline window subtracts, and why an ERP is an average across trials and not across time.

How MATLAB is used. Every part of the activity happens in MATLAB with EEGLAB and ERPLAB. Students read a real preprocessing script, predict its behavior, and then run a Live Script that executes each buggy line inside try/catch so the actual error message appears without stopping the script. For the bugs that produce no error, the Live Script shows the effect: the same four seconds of data under two low-pass settings, the mean across channels before and after re-referencing, and the averaged waveform under two baseline windows. Students then compare their script result with the dataset they produced in the GUI (channel count, sampling rate, number of epochs, and the largest point-by-point difference between the two waveforms). Reading alone catches a silent bug only when the reader already knows the intended setting. Running the code shows what the setting did to the data whether or not the reader knew to look.

Higher-order thinking. Students form predictions, test them, and explain the gap between prediction and result. They learn to separate code that stops with an error from code that runs and is wrong, to trace an error back to a line earlier than the one where MATLAB stops, and to see that a comparison cannot catch a bug that both sides share.

Other skills. Writing short, specific technical explanations in code comments; reading error messages; using help text and documentation to answer a question about a function's arguments.

Context for Use

This activity is designed for PSYCH 390: Electrophysiology of Complex Cognition, an upper-level undergraduate seminar at St. Olaf College, a liberal arts college. Enrollment is small (seven students in Fall 2026). The course meets twice a week: Tuesdays are student-led discussions of ERP components, and Thursdays are 80-minute MATLAB labs using EEGLAB and ERPLAB.

The activity fills one Thursday lab near the midpoint of the semester. By then students have completed five labs: one on MATLAB basics and four in which they processed one dataset step by step through the EEGLAB/ERPLAB menus (data loading, filtering, re-referencing, and then Event List, bin assignment, and epoching). In each of those four labs they also copied the code EEGLAB recorded for their GUI actions. This activity checks whether they can read that code on its own before the second half of the course, where they move to scripting and to a final project written entirely as a MATLAB Live Script.

The activity is easy to adapt. It needs EEGLAB, ERPLAB, one continuous EEG recording, and a bin descriptor file for that recording. An instructor using a different dataset would change the file names, the bin descriptor file, the bin labels, and the channel used in the averaging step. The bugs themselves do not depend on the data.

Technical skills and experience with MATLAB students must have mastered before the activity:
- Opening, editing, and saving scripts in the MATLAB Editor, and running one section at a time with Run Section
- Variables and assignment, including the difference between a line that displays a result and a line that stores it
- Indexing into arrays, including a three-dimensional array (channels x time points x trials)
- Calling functions with inputs and outputs, and reading a function's help text
- Basic plotting (plot, xlabel, ylabel, legend)
- Loading data in EEGLAB and completing the filtering, re-referencing, Event List, bin assignment, and epoching steps through the GUI at least once
- Knowing that EEGLAB stores the command for each GUI action in EEG.history

Description and Teaching Materials

Before the activity. In the previous lab, students process one participant through the EEGLAB/ERPLAB menus with the course settings (import the BrainVision file, high-pass 0.1 Hz and low-pass 30 Hz, average reference, Event List, bin assignment with the course bin descriptor file, epoch from -200 to 800 ms with a pre-stimulus baseline) and save the result as an EEGLAB dataset under a file name given in the script.

Part 1: Predict (30 minutes, no running code). Students open BugHunt_1102.m, a script that repeats their GUI steps in the same order. They are told that it contains several problems, that some cause errors and some do not, and that some strange-looking lines are correct. They are not told how many problems there are. Under every line or group of lines they fill in a comment block: whether it will run, why, which GUI step it matches, and whether its result would match their GUI result. They may use the MATLAB and EEGLAB help and their lab guides but no AI tools. They submit the annotated file to the course site.

Part 2: Run and explain (40 minutes). Once everyone has submitted, the instructor releases BugHunt_1102_Key.mlx and students run it one section at a time. Each section shows the buggy line, runs it inside try/catch, explains the problem, and runs the fix so the pipeline continues. Students add OBSERVED and EXPLAIN notes under their own predictions. The last sections overlay the script waveform on the GUI waveform, print a comparison table, and display the GUI dataset's command history so students can compare it line by line with the fixed script.

Wrap-up (10 minutes). Discussion of the silent bugs and of what would have caught them without the key (see Teaching Notes).

The ten bugs:
1. A misspelled file extension when importing the data (error)
2. A missing parenthesis (syntax error; pressing Run executes nothing at all)
3. eeg in place of EEG (error; MATLAB is case sensitive)
4. A 3 Hz low-pass filter where the course uses 30 Hz (runs; wrong result)
5. pop_reref called without assigning its output back to EEG (runs; the step does nothing)
6. Bin assignment placed before the Event List is created (error; order of steps)
7. A post-stimulus baseline window (runs; wrong result)
8. A channel number typed by hand with a comment that names the wrong channel (runs; wrong channel)
9. Averaging over the time dimension in place of the trial dimension (runs; the error appears one section later when the result is plotted)
10. A missing hold on, so the comparison figure shows only one waveform (runs; wrong figure)

Correct lines that look suspicious include eeglab nogui and the empty brackets used as arguments to pop_eegfiltnew and pop_reref.

Why MATLAB. EEGLAB and ERPLAB run in MATLAB, and the EEGLAB GUI records each action as a line of MATLAB code. The activity uses that recorded code as the link between what students clicked and what they read. The same idea would work in Python with MNE-Python, but the GUI-to-code step would be lost. Live Scripts let the answer key show the explanation, the code, the error message, and the figure in one document.

Materials (uploaded):
- BugHunt_1102.m: the student script with ten planted bugs and a prediction block under every line.
- BugHunt_1102_Key.m: the answer key. Open it in MATLAB as a Live Script and save it as .mlx. Each section explains one bug, demonstrates it, and runs the fix.
- BugHunt_Instructor_Notes.docx: setup steps, the GUI settings students should use, a table of the ten bugs and what each teaches, and grading notes.

The EEG recording is not included. Any continuous recording that EEGLAB can read will work, along with a bin descriptor file for its event codes. One participant from ERP CORE (Kappenman et al., 2021), which is free to download, is a good option for instructors without their own data.


Bug Hunt Student Script (subject 1102) (Matlab File 4kB Sep30 26)
Bug Hunt Answer Key (Live Script) (Matlab File 12kB Sep30 26)
Bug Hunt Instructor Notes (Microsoft Word 2007 (.docx) 12kB Sep30 26)

Teaching Notes and Tips

Run the key once in your own MATLAB installation before class. Three of the demonstrations (the misspelled file, bin assignment without an Event List, and plotting an array with the wrong shape) depend on how your versions of EEGLAB and ERPLAB respond. Each is inside try/catch, so the script will not stop, but the explanation should match the error students see.

Make sure every student has saved the GUI dataset from the previous lab under the file name the script expects. The final comparison depends on it.

Release the key only after all predictions are in, and tell students how many bugs there are only then. Without the number, they have to decide line by line whether something is wrong, and that decision is what the activity practices.

Grade the predictions on reasoning, not correctness. The activity depends on students committing to a prediction and then explaining a wrong one. If wrong predictions cost points, students have a reason to leave blocks vague.

Spend most of the wrap-up on the silent bugs. Ask students what check, other than this key, would have caught each one. Possible answers include comparing settings against a written analysis plan, checking a known property of the data (the average reference sums to zero), plotting after each step, and looking up channels by label.

The key ends with a point worth discussing: a script that matches the GUI has repeated what the student did, which does not show that what they did was right. In the buggy script, the same wrong channel number was used for both waveforms in the comparison, so they would have matched.

To use a different dataset, change the three paths at the top, the file names, the bin descriptor file, the bin labels in the bin assignment section of the key, and the channel label used for averaging.


Assessment

Students submit two versions of the same file: the prediction version before they receive the key, and the final version with OBSERVED and EXPLAIN notes under each prediction plus short answers to two questions at the end (which bug they did not predict and what would have helped them see it, and what check would have caught each of the five silent bugs). I grade it with the course lab rubric (15 points): a complete submission with every block filled in (8), correct explanations and fixes for the five silent bugs (4), and predictions that give reasons and not only yes or no (3). Having both versions shows what each student could reason out before running the code, which is what the activity is meant to teach.

References and Resources

EEGLAB (https://sccn.ucsd.edu/eeglab/): the open-source MATLAB toolbox used for loading, filtering, and re-referencing. Delorme, A., & Makeig, S. (2004). EEGLAB: An open source toolbox for analysis of single-trial EEG dynamics including independent component analysis. Journal of Neuroscience Methods, 134(1), 9-21.

ERPLAB (https://erpinfo.org/erplab): the EEGLAB plugin used for the Event List, bin assignment, and epoching. Lopez-Calderon, J., & Luck, S. J. (2014). ERPLAB: An open-source toolbox for the analysis of event-related potentials. Frontiers in Human Neuroscience, 8, 213.

ERP CORE (https://erpinfo.org/erp-core): a free set of EEG recordings for seven ERP components, an option for instructors who do not have their own data. Kappenman, E. S., Farrens, J. L., Zhang, W., Stewart, A. X., & Luck, S. J. (2021). ERP CORE: An open resource for human event-related potential research. NeuroImage, 225, 117465.

Luck, S. J. (2014). An Introduction to the Event-Related Potential Technique (2nd ed.). MIT Press. The course textbook; its chapters on filtering, baseline correction, and averaging cover the concepts behind the silent bugs.

White, R. T., & Gunstone, R. F. (1992). Probing Understanding. Falmer Press. Source of the predict-observe-explain approach the activity follows.

ERP Pipeline teaching pages (https://brivera21.github.io/diagrams/erp-pipeline.html): interactive pages I made for the course, one per preprocessing step, useful for reviewing what each step does before the activity.

My Favorite ERP Component MATLAB Live Script (SERC activity collection): the final project from the same course, which this activity prepares students for.