Skip to main content
Reliability is the main goal of this page. A device integration should survive real-world conditions, not just a clean demo session.

Definition of Done

The integration is ready when all of the following are true:
CheckWhat to verify
Frame widthEvery row width matches numEegChannels
Channel orderThe order is stable and documented
Sample rateMatches the real device output
Status transitionsConnect, start, stop, disconnect, and failures are surfaced cleanly
Packet handlingMalformed or short packets are rejected safely
Reconnect behaviorThe session can recover or fail clearly

Minimum Test Set

1

Happy path

Verify connect -> start -> frames -> stop -> disconnect with mocked BLE or bridge fixtures.
2

Malformed packet handling

Feed short, corrupt, or partial packets into the decoder and confirm that they are rejected safely.
3

Disconnect and reconnect behavior

Simulate device loss, browser disconnects, and retry behavior.
4

Firmware variants

Add fixtures for known protocol differences across supported firmware lines.
5

Metadata verification

Confirm channel names, count, sample rate, and timestamp handling.

What to Test First

AreaWhy it usually fails first
Discovery filtersWrong filters hide the device or expose unrelated devices
Characteristic setupOne bad UUID or missing notify step blocks streaming
Decoder assumptionsEndianness, packet size, or scaling errors corrupt rows
Session teardownOrphaned subscriptions make reconnects flaky
Timestamp logicGood-looking samples can still arrive with bad timing metadata

CI Guidance

Real hardware is not required for CI. Use mocked Bluetooth or bridge I/O and stable packet fixtures so the tests are repeatable and easy to maintain.
A good fixture set is more valuable than one manual test pass on a real headset.

Manual Validation Pass

After automated tests are green, do one real device pass for each supported firmware line.
Manual checkWhat to confirm
Initial pairingthe browser can discover and connect cleanly
Streaming startframes begin without duplicate subscriptions
Session lengththe stream stays stable over time
Interruptionstransient disconnects behave predictably
Recoverythe device can be stopped and started again

Common Failure Patterns

Check channel order, scaling, and sample rate before looking at models.
Review teardown. Most reconnect bugs come from stale subscriptions or an incomplete session release.
Revisit timestamp behavior and packet batching. Sample values can look fine while timing metadata is still wrong.
Separate version-specific packet handling and add fixtures for each supported firmware branch.

Release Readiness Checklist

Before you hand off the integration, make sure you can answer these clearly:
  1. which devices and firmware versions were tested
  2. which browsers and platforms were tested
  3. what known limitations still exist
  4. what recovery behavior apps should expect
  5. who owns future maintenance

Next

Prepare the handoff

Package the tested integration for review or partner delivery.

Return to the guide index

Review the full integration flow.