BrainFlow includes a synthetic board for hardware-free BCI prototyping. Learn the SDK workflow, starter code, and debugging checklist. Read now.
Start Without Hardware: Synthetic Boards Matter
Building a brain–computer interface used to mean buying sensors first and only then learning the software stack. That order slows beginners down: setup friction, noisy signals, and driver issues hide the core pipeline you actually need to understand. BrainFlow’s synthetic board flips the sequence. You get a virtual device that streams realistic-looking sample data so you can learn session setup, channel layout, buffering, and feature extraction before any physical headset is involved.
Treat the synthetic board as a stand-in for real hardware, not as a finished product. It lets you practice the same API surface you will later point at a live device: open a session, configure sampling, pull arrays of samples, and shut down cleanly. Once that loop is solid, swapping to real hardware becomes a configuration change instead of a rewrite.
SDK Workflow: Session, Stream, Transform
Most BCI SDK work follows a short, repeatable path. First, choose a board type (synthetic while learning), create a board object, and prepare a session with the sampling rate and channel set you care about. Second, start the stream and read data in fixed-size chunks rather than one sample at a time—chunked reads keep your code aligned with how filtering and windowed analysis usually work. Third, convert raw arrays into something useful: band-power features, simple thresholds, or markers that map to an application event.
Keep acquisition and decision logic separate. The acquisition layer should only open, stream, buffer, and close. The analysis layer should receive arrays and return features or labels. That split makes it easy to unit-test transforms against saved synthetic runs and to replace the board later without touching your classifier or UI.
Starter Code Shape to Copy
A minimal starter script should do four things in order: import the SDK, instantiate the synthetic board, start a session, and loop on timed reads until you stop. Inside the loop, check that each buffer has the expected shape (channels × samples) before you filter or plot. Log a few rows of values early so you can confirm the stream is live. On exit, always stop the stream and release the session so the next run does not inherit a half-open connection.
Prefer short scripts over large frameworks at first. One file that records a few seconds of synthetic data to disk and another that loads those samples and prints basic stats (mean, range, per-channel variance) will teach more than a full dashboard. Add visualization only after you trust the numbers. When you move past synthetic input, change board selection and device parameters in one place and leave the rest of the pipeline alone.
Debugging Checklist When Signals Look Wrong
- Confirm the board type and session actually started—failed prepare or start calls often surface only as empty buffers later.
- Check buffer shape and sampling rate against what your filters expect; off-by-one channel counts and mismatched windows produce silent garbage.
- Verify you are reading after the stream is running, not before; early reads can look like “dead” hardware.
- Log a short raw snippet before filtering so you can tell device issues from bad transform code.
- On exit, force-stop and release; stuck sessions are a common cause of “works once, fails on restart.”
- When you introduce real hardware, re-run the same checklist before blaming the sensors—most pipeline bugs show up identically on synthetic data.
If synthetic data behaves correctly and live data does not, narrow the problem to cabling, contact quality, power, or board configuration rather than rewriting analysis. A disciplined SDK workflow, small starter scripts, and this checklist will get you from first neural-interface prototype to hardware-backed experiments with far less thrash.