The case study
I set out to train a consumer EEG headset to recognise imagined movement. The question was narrow: can an 8-sensor consumer headset learn to tell one imagined movement from another? The wall I hit answering it turned out to be worth more than the answer, and this is the whole arc, including the parts that did not go the way I planned.
Hardware
Neurosity Crown 3 (Crown-2B1)
Channels
8 at 256 Hz
Trials
219 across 17 experiments
Sessions read closely
3
One loaned headset, 248,320 samples
The hardware is a Neurosity Crown, a consumer EEG headset with 8 recording electrodes sampling at 256 times a second. It ships with a training feature: you pick a command like "left hand pinch," record yourself imagining it thirty times, and a model on Neurosity's servers learns to spot that pattern in your live signal.
Over the course of the project I recorded 219 training trials across 17 experiments, and read three full recording sessions closely, about 16 minutes of raw voltage, 248,320 samples in total. That is a small dataset by research standards and a large one by the standard of actually looking at every part of it, which is what I did.
The method was the same throughout: record in the console, export the raw CSV, and read it from the samples up with a 1 to 45 Hz zero-phase Butterworth filter and Welch power spectra in four-second windows. Every figure on this site traces back to a file.
The wall was the finding
The training stalled, and not because the physics said no. It stalled at the console.
The trials you record are not inspectable. The console shows a count, and that is all: no list of trials, no per-trial score, no export, and nothing the developer tools return either. The recordings are consumed to fit a model in Neurosity's cloud, and the only thing that ever comes back is a live prediction. On top of that, every experiment I set up with more than one command recorded zero trials; all 219 of mine sit in single-command experiments, and a single-command experiment only teaches the model "this versus nothing," never "this versus that." At some point I recognised what I was doing: collecting a dataset I would never be able to open.
That reframed the whole project. A model trained on my brain does not transfer to anyone else's, so even a successful model would have been a dead end as a deliverable. What does transfer is the knowledge. The four findings I would hand to anyone starting on this hardware:
- If you want data you can keep, record it yourself.
- On this hardware, I trust the calm score more than the focus score.
- The raw export has traps that cost data silently.
- A loud channel is a bad connection, not a busy brain.
The constraint analysis and all four findings, in full: Can an 8-sensor consumer headset learn to tell one imagined movement from another?
At some point I recognised what I was doing: collecting a dataset I would never be able to open.
Samantha Lin
Independent researcher
An interpretation layer: two tools and a guide
The pivot produced two tools and a guide, each one a direct response to something above.
crown-focus-logger records focus, calm, and the five frequency bands to a CSV you own.
crown-debrief turns a recording into a plain-English account with no AI model in the loop.
A built-in guide answers questions, cites its sources, and refuses rather than guesses.
All of it runs in a browser: try the interpreter and its guide, no install and nothing uploaded.
Where it stands, and what is still open
The tools run end to end, and they have now been run on real recordings: the interpreter reads the raw voltage exports the console produces, and its reading of them was checked against the console's own channel readouts, agreeing to within 0.1%. What has never been run is live mode against a physical Crown. Everything here came from exported files, and the live screens were developed in mock mode, labelled as such.
What is here has been checked from the outside. The filter and spectral method were validated against a SciPy reference implementation, an independent reimplementation of the pipeline reproduced the readings that remain and forced the withdrawal of the ones it could not, and 120 automated checks hold the analysis in place. The repositories are public and the checks run on them.
Still open, plainly:
- The calm-over-focus claim remains my inference until the ten-minute clench-versus-concentrate test is run.
- The first baseline protocol has not been run: 30 imagined left-hand pinches against 30 right in one sitting, written up in full at a baseline protocol worth running. It is sized deliberately below the published trial counts so it fits inside the fatigue window, and it is the run I would hand to whoever continues.
- The guide's retrieval is keyword-based and misses paraphrased questions.
- Live mode has never been run against a physical Crown.
- Nothing here is diagnostic or clinical, and comparing scores between two people is meaningless, because the normalisation layer that would make it possible does not exist on this platform.
The closing section of this study, guidance for four kinds of reader, is published as Who you are, and what to use the Crown for.
Sources. My own data: the Crown Signal Reader analysis, the crown-debrief repository (README.md and HANDOFF.md), the Notion training plan, and the four-persona analysis notes.
trials audited
samples
automated checks
Design decisions that hold up
Open any card for the detail behind it.
The honest limits
The analysis is tested and the design decisions are made. What follows is what the system cannot do even when it runs perfectly, and it is addressed to whoever picks this up next.
Open any card for the detail behind it.
Sources. README.md and HANDOFF.md in the crown-debrief repository.
Explore more
This site covers what the documentation doesn't: the things I wish someone had handed me first.