Skip to main content
Once your protocol inventory is complete, build the adapter. The goal is to isolate device-specific BLE and packet logic while preserving the shared Elata transport contract for apps. For browser BLE integrations, the adapter should satisfy the BleDeviceLike shape expected by @elata-biosciences/eeg-web-ble. That means the device layer handles discovery, session setup, subscription, and packet decoding, while BleTransport handles the app-facing transport surface.

Implementation Order

1

Implement discovery

Define the requestDevice filters and any optional services required to find the device cleanly in the browser picker.
2

Prepare the session

Connect to GATT, resolve characteristics, and do any startup writes that are required before streaming can begin.
3

Decode packets into EEG rows

Turn vendor packets into number[][] where each row is one time step and the row width matches numEegChannels.
4

Emit stable metadata

Expose samplingRate, eegNames, numEegChannels, and related device metadata accurately.
5

Handle stop and release cleanly

Unsubscribe, stop the stream safely, and release the session without leaking resources.

Minimal Adapter Skeleton

What the Adapter Must Own

Packet Decoding Rules

Keep the decoder boring and deterministic.

Session Lifecycle Rules

Your adapter should make these transitions unsurprising:

Reliability Notes

startStreaming() is the safest default for app consumers because it combines connect and start. Your adapter should still make the underlying connect() and start() steps reliable on their own.
If the device exposes auxiliary signals such as PPG, optics, IMU, or battery, map them only when the semantics are clear. Do not force Muse-specific assumptions onto non-Muse hardware.

Next

Validate the integration

Turn the adapter into a reliable transport under real failure conditions.

Prepare the handoff

Package the integration with the docs and caveats other teams need.