Capability Map

iOS and Android. The everyday face of the device.

Connect the Crown to Wi-Fi, watch your focus in real time, run sessions up to an hour, and check battery and signal. It also carries NeuroAdaptive Audio, music that adjusts itself based on what your brain is doing, rather than a fixed playlist.

Beta

Spotify recommendations chosen by your brain activity.

Hooks your Spotify account up to the Crown and suggests tracks based on your current state. Still labelled a beta, and nothing has been published about how it will be offered once the beta ends.

No code needed

A website, despite the name, and the most underused thing Neurosity ships.

At console.neurosity.co you can watch your live brainwaves, record raw EEG sessions and download them, train Kinesis commands, and flip the seven device settings. You do not need to be a programmer to use any of it. “Developer” in the name puts people off, which is a shame.

Experimental

Teach the Crown to recognise an imagined movement.

You repeatedly imagine a specific action, say, pushing with your right arm, and the Console learns your pattern. Once trained, that thought becomes a trigger you can attach to something. Neurosity is candid that lag and accuracy are still being worked on, so treat it as a toy for now rather than a control system.

No code needed

Talk to your brain data through Claude or ChatGPT, in plain English.

Add https://mcp.neurosity.co as a connector and you can simply ask: “how has my focus been this week?” or “record two minutes and chart it.” This is the single biggest no-code capability Neurosity has, and it is barely advertised, it is also how the numbers in this document were read off the loaned headset.

The toggles in your Console, worth knowing what they do.

Activity Logging quietly saves focus and calm snapshots over time. System Haptics enables the two vibration motors in the band. OSC, OSC Performance, OSC Batch and LSL open the developer routes in section 04, leave them off if you are not using them. Support Access lets Neurosity’s support team look at your device; keep it off unless you are in a ticket.

Neurosity runs a hosted simulator that anyone can try without owning a Crown. You request access and login details arrive by email. It gives you the Console with live simulated brainwaves and focus metrics, walkthroughs of the neurofeedback and focus-session flows, and, the part that matters here, a live environment to exercise the JavaScript and Python SDKs against.

If you are still deciding whether the Crown is worth building on, start here. No usage limits are published, so treat it as an evaluation tool rather than a development dependency.

Emulators are created from console.neurosity.co/emulators. Neurosity describes an emulator as a private virtual EEG machine running the actual Neurosity operating system, not a data faker bolted onto the SDK, but the real OS with synthetic sensors underneath. That distinction matters, because it means the surface your code talks to is the same one it will meet in production.

What an emulator gives you:

• Raw, PSD and power-band brainwaves

• Awareness metrics, calm and focus

• EEG recording exported as EDF, JSON or CSV

• Device info, status and settings, so your settings UI is testable

• Timesync and event markers

• Activity logs

The SDK also exposes setEmulatorStatus(), which is the quietly valuable bit: you can script device states. Battery at 3%. Charging. Asleep. Connection lost mid-stream. These are exactly the paths that ship broken, because on real hardware you can only test them by waiting for them.

Worth it when you have continuous integration to run, a demo to give without a headset on stage, or an onboarding flow that needs testing dozens of times a day. Not worth it if you’re one person building one thing, record a real session instead.

An open-source Node simulator of the OSC server that runs on the device itself. Neurosity built it specifically to validate BrainFlow and neuromore Studio integration, which tells you exactly what it’s good for.

Clone it, npm install, npm start. A .env file overrides the device UUID, model name and version, sampling rate, channel count and channel names, and the OSC host and local/remote ports. The channel defaults are the Crown’s own, CP3, C3, F5, PO3, PO4, F6, C4, CP4, so what you build against lines up with your real hardware.

If your project lives on OSC, this covers you completely.

The most underrated option, because it is the only one that produces real data. record({ label, duration }) captures a session; it saves to the device first, then uploads to cloud storage with metadata in Firestore. If the network is down at the time, the device uploads when it comes back, so a recording made on a train is not lost.

Synthetic data is clean. Real EEG is not, and almost every bug you will ship is in the handling of the mess. Which is why the fixture set matters more than the mechanism:

The workflow most projects converge on

The demo to evaluate → record a real fixture set on your own head over one afternoon → develop and test against those recordings → add an emulator only when you have CI or demos that need one. The recordings stay useful forever; the emulator is the part you can turn off.

When more than one door would work, this is what you’re trading.

• Choosing OSC because the tutorial used it. Most Crown tutorials are creative-coding demos, so OSC looks like the default path. Then you try to give the thing to a friend and discover it only works in your flat. Decide the multi-user question before you write anything.

• Reaching for raw EEG when Perform Mode would do. Raw is 256 Hz across eight channels and you will spend a week on filtering before you see anything. If a human is going to look at the output, Perform Mode’s 4 Hz smoothed metrics are almost certainly what you actually wanted.

• Building the UI before the signal-quality gate. The demo looks great on your own well-seated headset and falls apart on someone else’s. Subscribe to signalQuality() first and make “I can’t read you right now” a first-class state.

• Starting with the Python SDK. It is still marked beta. Prototype in JavaScript, port later if you need Python’s analysis ecosystem, or reach it through BrainFlow instead.

You are allowed to use more than one

These routes are not exclusive, and the good projects mix them. A common shape: Perform Mode over the SDK drives everything the user sees, while record() captures raw sessions in the background for later analysis, cheap live loop, full fidelity when you need to look properly. Another: prototype on OSC because it’s a single toggle and instant feedback, then rebuild on the SDK once you know the idea works and you want to ship it.