Skip to main content
This guide is for device companies that want their hardware to work with the Elata SDK. The target is simple: your device should plug into the shared Elata transport boundary and emit stable frames that apps can trust.

Start with the contract

Review the shared frame and transport types before writing adapter code.

Check browser support

Confirm Web Bluetooth, browser, and platform constraints first.

What You Are Building

A production-ready integration should do three things well:
  1. connect reliably
  2. stream frames in a stable, predictable format
  3. recover cleanly when the device, browser, or radio link misbehaves
In Elata terms, that means converging on HeadbandTransport and HeadbandFrameV1 instead of exposing vendor-specific packet layouts directly.
Apps should depend on the shared Elata transport contract, not on raw vendor packets. That keeps downstream integrations simple and makes device support easier to maintain.

The Fast Path

1

Choose an integration path

Decide whether your device belongs upstream in eeg-web-ble, in a separate package, or in an app-local adapter. Use Integration Paths to make that decision early.
2

Capture the protocol inventory

Gather your GATT services, characteristics, packet format, sample rate, channel names, timestamp behavior, and known firmware quirks. See Protocol Requirements.
3

Implement the adapter

Build the device layer that handles discovery, session setup, packet decoding, and frame emission. Start from Adapter Implementation.
4

Validate for reliability

Test connect, start, stop, disconnect, malformed packets, reconnects, and frame correctness before tuning anything downstream. Use Testing and Validation.
5

Prepare the handoff

Package the integration with platform notes, tested firmware versions, and support expectations. See Submission and Support.

What You Need Before You Start

RequirementWhy it matters
Device protocol detailsYou need a complete byte-level picture before implementation starts.
A supported browser pathWeb Bluetooth requires Chrome or Edge in a secure context.
Stable channel metadataApps need consistent channel order, names, and sample rates.
A clear ownership modelDecide early whether this will live upstream, in a vendor package, or privately.
If you have not reviewed the current BLE flow yet, read EEG BLE Getting Started first.

Guide Map

Integration Paths

Choose where the integration should live and how it should be owned.

Transport Contract

The shared interfaces your device must satisfy.

Protocol Requirements

The protocol and metadata inventory to collect before coding.

Adapter Implementation

Build the device adapter and connect it to BleTransport.

Testing and Validation

Make the integration reliable under normal and failure conditions.

Submission and Support

Hand off the integration with the docs and caveats partners need.

Reliability First

A device integration is not done when it streams once on a happy path. It is done when:
Done meansNotes
connect() is predictablediscovery and session setup succeed or fail clearly
start() produces stable framesrow width, channel order, and sample rate stay correct
stop() is cleanthe session stops without leaving the device in a bad state
disconnect() is cleanthe browser session releases resources correctly
failures are surfaced clearlyapps can react to disconnects, retries, and unsupported states

Next

Choose an integration path

Pick the right ownership and packaging model before coding.

Review the transport contract

Confirm the frame and lifecycle expectations your adapter must satisfy.