That was the opening question, and it is a question with a right answer, not a matter of opinion. Motor imagery, imagining a movement without making it, produces measurable changes over the brain’s motor strip, and a century of EEG work says which movements produce signals where. So before recording anything, you can reason out which commands this specific sensor layout has a fair chance of seeing, and which it physically cannot.
There turned out to be a second question hiding underneath the first, and the project ended up answering that one instead: once you have trained this headset, can you inspect what you taught it? And if you cannot, what would a person actually need to make their own brain data legible?
Command selection as a constraint problem
I did not pick commands from the menu by what sounded interesting. I started from the physiology and worked backwards.
Imagining a left-hand movement suppresses the mu rhythm, 8 to 12 Hz, over the right motor cortex, where the Crown has an electrode (C4). A right-hand movement does the same over the left (C3). Because the two hands light up opposite sides of the head, left versus right hand is the easiest discrimination in all of motor imagery, and this headset has a sensor sitting on each side for exactly that. The hand also has the largest representation in the motor cortex of any body part, so it gives the loudest signal you can get.
From there, the eliminations follow. The foot’s motor area sits on the inner wall of the brain, directly under the midline of the head, and the Crown has no midline sensor, so foot commands are close to invisible. Arm imagery overlaps hand imagery too much to separate. Jumping jacks activate both sides at once, which removes the left-right difference that makes discrimination work. And my training plan classed push and drop as spatial force imagery, loading the frontal planning regions (F5, F6) more than the motor strip. Disappear is not a motor command at all, so there is no motor signature for it to produce.
That leaves three: rightHandPinch and leftHandPinch as the pair, because they are the loudest signal this montage can see and they land on opposite hemispheres, plus tongue as a candidate third. Tongue is the weakest of the three and I kept it as a candidate rather than a pick, because its motor area sits low and to the side, near the two positions the Crown uses for reference rather than recording. The rest were set aside before recording anything, on the same reasoning.
Every command is imagined, you never actually move, because moving wrecks the reading. What differs is what each one physically produces, and where.
What I actually recorded: push 30 trials, left hand pinch 30, drop 30, mental math 60, biting a lemon 31, jumping jacks 30, and 8 trials of an artifact detector, 219 in all. One protocol lesson came free with the data: in the 60-trial mental math run I was fatigued by around trial 20, and the back half of that session is a different, worse task than the front half. Shorter sittings, spread across days, would have given better data.
What I actually set up, against what I just described
Reading the training log back afterwards produced an uncomfortable result: the reasoning above is right, and I did not follow it.
Only two of the seventeen experiments ever paired commands that could be told apart by which side of the head they land on, and both of them grouped the same side. In one experiment I set up leftHandPinch against leftArm. In another, rightHandPinch against rightFoot against rightArm. Every class in both experiments competes for the same patch of cortex on the same hemisphere, which is the hardest version of the problem rather than the easiest. The pairing that the argument above points at, left hand against right hand, appears nowhere in the log.
Neither experiment recorded a trial, so nothing was lost to it. But the reason it matters is that I could have caught this before sitting down rather than after: the constraint analysis was already written, and the label picker in the console offers no hint that two same-side commands are a harder ask than two opposite-side ones. The protocol I would run first is written up at a baseline protocol worth running, and what the training log shows is the full audit those two experiments came out of.
The four findings I would hand to anyone starting on this hardware
If you want data you can keep, record it yourself. Console training is a live feature, not a data collection method. The SDK’s own recording path produces files you own and can re-analyse. I learned this after 219 trials, which is the expensive way.
On this hardware, I trust the calm score more than the focus score. Focus is built from gamma waves, 30 to 44 Hz, and clenching your jaw or tensing your brow produces electrical noise in that same range that dry electrodes cannot reliably separate from brain activity. Calm is built from alpha, 7.5 to 12.5 Hz, which is slower, stabler, and much less exposed to muscle. My own trials back this up: “biting a lemon,” a jaw clench, lands exactly in the band focus reads from. To be clear, the two building blocks are established EEG fact, but the conclusion “therefore trust calm first” is my own inference, not something Neurosity states, and it is testable in ten minutes with one recording that alternates jaw clenches with real concentration.
The raw export has traps that cost data silently. The CSV has no header row, so a spreadsheet eats your first sample as column names with no warning, and the timestamps occasionally step backwards or skip. Order by sample index, never by time, and declare the columns yourself.
A loud channel is a bad connection, not a busy brain. In one of my sessions, one frontal electrode ran 26 times louder than the median. That is contact failure, not cognition, and bad contact still produces confident-looking numbers. Check signal quality before trusting anything built on top of it.
An interpretation layer, built as an answer to each finding
The pivot produced two small tools and a guide, each one a direct response to something above.
Because the console keeps your training data, I built crown-focus-logger: it records focus, calm, and the five frequency bands to a CSV every two seconds, in live mode against a headset or in mock mode against synthetic data, so you own the record from the first session.
Because the console’s numbers are illegible to anyone who has not studied EEG, I built crown-debrief. It reads that CSV and writes a plain-English account of the session. The design is computed-then-written: an analysis engine works out the facts, and sentence templates turn them into English. There is no AI model in the loop, every claim traces back to a number in the CSV, and 120 automated checks hold that guarantee. It shows three screens: Today, which is one number (minutes of deep work), Session, a ribbon of states over time, and Detail, the technical view kept behind a quiet link. The live dashboard is deliberately off the main screens; my design position is that watching your own focus score is itself a distraction that lowers it. The tool learns your personal baseline from your first ten sessions, per metric and per hour of day, saying “learning what’s normal” until then, and it only ever describes readings on a fixed five-word scale, from well above usual to well below usual. Never good or bad.
Because the questions do not stop when the debrief ends, there is a built-in guide: keyword search over the project’s knowledge files, answering with the relevant passage, citing which file and heading it came from, and refusing to answer when nothing matches rather than guessing.
Sources
My own data: three recorded console sessions (248,320 samples), an audit of seventeen training experiments, the Crown Signal Reader analysis, and the Notion training plan and sensor map.
- Neurosity documentation: Focus and Calm, for both bands, the 0.3 threshold and the 16-second initialisation
- Pfurtscheller, G., and Neuper, C. (2001). Motor imagery and direct brain-computer communication. Proceedings of the IEEE 89(7):1123-1134.
- Cho, H. et al. (2017). EEG datasets for motor imagery brain-computer interface. GigaScience 6(7):gix034.
- Neurosity, Motor Imagery BCI guide.
- Whitham, E. M. et al. (2007). Scalp electrical recording during paralysis. Clinical Neurophysiology 118(8):1877-1888.
- Goncharova, I. I. et al. (2003). EMG contamination of EEG. Clinical Neurophysiology 114(9):1580-1593.
- Banker, L., and Tadi, P. Neuroanatomy, Precentral Gyrus. StatPearls.
