BrainFlow includes a synthetic board for hardware-free BCI prototyping. Learn the SDK workflow, starter code, and debugging checklist. Read now.
Why start with an SDK instead of hardware
Building a brain-computer interface sounds like it should begin with electrodes and a headset, but the software layer is where most beginners get stuck. A BCI SDK gives you a consistent way to open a device, stream samples, and pull them into arrays you can analyze, without writing driver code for every board. BrainFlow is one such SDK, and its most useful feature for learning is the synthetic board: a virtual device that produces signal data on demand. You can write, run, and debug an entire pipeline before any hardware arrives, which removes the biggest source of early frustration.
Starting in software also separates two problems that beginners tend to tangle together: is my code wrong, or is my hardware connection wrong? When the synthetic board feeds you clean, predictable data, any bug you hit is in your logic. Once that logic works, swapping in a real board becomes a configuration change rather than a rewrite.
The basic SDK workflow
Most BrainFlow programs follow the same shape regardless of the board behind them. You describe which board you want and its connection details, open a session, start streaming, collect data, and then release the session cleanly. The synthetic board fits this exact pattern, so the code you write against it transfers directly to physical hardware later.
- Configure the board identifier and input parameters (for the synthetic board, no serial port or MAC address is needed).
- Prepare the session to establish the connection.
- Start the stream, then wait or run your loop while samples accumulate in the buffer.
- Pull the current data into an array for inspection or processing.
- Stop the stream and release the session so the device is freed.
Once you have samples in memory, they arrive as a matrix where rows correspond to channels and columns to time. Knowing how to index the EEG channels versus the timestamp and auxiliary rows is the first real skill to build, because every downstream filter or plot depends on selecting the right rows.
Writing your first starter script
A good first script does the minimum: connect to the synthetic board, stream for a few seconds, grab the buffered data, and print its shape. Seeing the array dimensions confirms that channels and samples are what you expect. From there, add one step at a time—plot a single channel, apply a bandpass filter, then compute a simple feature like band power. Building incrementally means each new line is the only thing that can have broken, which keeps debugging fast.
Resist the urge to wire up classification or real-time control on day one. The synthetic signal is not meaningful brain activity, so it is for validating plumbing, not for training models you trust. Treat it as a scaffold that proves your read, buffer, and processing steps run end to end.
A debugging checklist
When a pipeline misbehaves, work through the connection and data layers in order rather than guessing. Most early problems are mundane and repeat across projects.
- Confirm the session was prepared successfully before you try to read data.
- Check that you started the stream and waited long enough for the buffer to fill.
- Verify you are reading the correct channel rows for the board you selected.
- Make sure sampling rate assumptions in your filters match the board's actual rate.
- Always release the session, even after an error, so the next run can reconnect.
If the same script works against the synthetic board but fails on real hardware, the fault is almost always in the connection parameters or the physical link, not your processing code. That separation is the whole reason to prototype in software first.