The gap between a working BCI signal decoder and a functional BCI-exoskeleton integrated system is larger than it looks from a software-only perspective. The decode algorithm is, in some ways, the easier part. What actually consumes engineering time during hardware integration is the command interface between the BCI software layer and the exoskeleton actuator stack — a layer that is inconsistently documented, varies significantly between exoskeleton platforms, and has failure modes that are not obvious from the BCI literature.
This post covers what the integration surface actually looks like from an OEM device manufacturer's perspective: command latency requirements, safety interrupt protocols, electrical interface considerations, and the behavioral contract between the BCI software and actuator control firmware that both parties need to agree on before integration can succeed. It is based on the interface design decisions we made when specifying the Synaptiq SDK's command output layer, informed by the requirements of real rehabilitation hardware categories.
Command Output Formats and the Interface Contract
A BCI decoder produces a classification decision — in the simplest case, a discrete output: "left-hand imagery detected," "right-hand imagery detected," or "no clear imagery detected." That classification must be converted into a command that the exoskeleton's actuator firmware can act on. The interface between these two layers is where most integration friction lives.
Exoskeleton control firmware operates in one of several command models:
- Trigger-based: A rising edge on a digital I/O line triggers a pre-programmed movement sequence. The BCI system asserts a GPIO signal; the exoskeleton firmware handles the rest. Simplest interface, least flexible.
- Mode selection: The BCI system sends a command encoding selects among a pre-defined set of movement programs. Typically implemented as a serial byte stream (RS-232/RS-485) or CAN message.
- Continuous intent streaming: The BCI system streams a real-time intent signal — a probability or confidence score for each movement class — at a fixed update rate (typically 50–100 Hz). The exoskeleton firmware maps this stream to proportional actuator force or velocity. Most flexible, most complex interface.
- UDP/network command: For systems where the BCI compute platform and the exoskeleton are networked (common in research setups, less common in clinical hardware). Flexible but introduces network latency variability and requires clock synchronization.
The choice of command model affects latency, regulatory documentation requirements, and failure mode behavior. Trigger-based interfaces have predictable single-message latency (microseconds for GPIO assertion). Continuous streaming interfaces accumulate latency from multiple sources and have more complex failure modes when the stream is interrupted.
Latency Requirements at the Interface
The BCI literature's 100ms end-to-end latency target encompasses everything from EEG sample collection to actuator response. But within that 100ms, the distribution across subsystems matters and the contract must be specified at the interface.
A realistic latency budget for a 32-channel, 500 Hz EEG system with a 500ms trial window decoder looks approximately like:
- EEG amplifier sample buffer latency: ~10ms (2 samples at 500Hz, internal amplifier processing)
- USB transfer latency (USB 2.0 full-speed): ~4-8ms typical, ~20ms worst-case
- Software preprocessing (bandpass, CAR, covariance estimation): ~3-5ms for 32 channels
- Classification (Riemannian MDM or tangent space + LDA): ~1-2ms
- Command encoding and transmission (serial at 115200 baud): ~1ms
- Exoskeleton firmware command parsing and actuator initiation: ~10-20ms
The EEG acquisition itself has a structural latency: you cannot classify motor imagery from a 500ms window until 500ms of data have been collected. Choosing a shorter classification window (200ms) reduces this latency but typically reduces classification accuracy. This is a fundamental trade-off without a right answer — the optimal window length depends on the specific classification task, the patient population, and the minimum acceptable accuracy for the clinical protocol.
The implication for the interface contract: the BCI software layer needs to specify its worst-case command latency (not mean latency) and the exoskeleton firmware needs to specify its worst-case response time from command receipt to actuator initiation. The sum must fit within the overall system latency budget. We specify worst-case (99th percentile under normal operating conditions) rather than mean because rehabilitation patients will encounter the worst-case behavior, and a system that "usually" meets the latency target but occasionally fails by 200ms provides inconsistent feedback that degrades therapy effectiveness.
Safety Interrupt Protocols: The Non-Negotiable Layer
Any BCI-exoskeleton integration must implement safety interrupt handling with dedicated priority. This is not optional from an IEC 62304 / ISO 14971 perspective, and it is not optional from a clinical safety perspective.
The safety interrupt layer must handle at minimum:
Signal quality below threshold: If EEG signal quality degrades below the minimum acceptable level (too many channels with high impedance, artifact amplitude exceeding threshold), the BCI software must emit a stop command and not resume decode until signal quality is restored. The exoskeleton must respond to the stop command with higher priority than any active movement command — the stop signal cannot be queued behind pending movement commands.
Classification confidence below threshold: If the decoder's output confidence is consistently below a minimum threshold over a time window (e.g., 10 seconds of ambiguous outputs), this is a signal quality or patient attention problem that should trigger a pause and operator notification rather than continued low-confidence decode.
Patient-initiated stop: Clinical exoskeletons must support immediate stop by physical switch or button independent of the BCI software layer. The BCI system should not be in the critical path for emergency stop — this is a fundamental safety design principle.
BCI software host fault: If the BCI compute host fails (OS crash, process termination, USB disconnection), the exoskeleton must detect the absence of a heartbeat signal within a defined timeout and enter a safe state. The exoskeleton should never assume the BCI system is active and commanding it; it should require positive confirmation of BCI system liveness at a defined interval.
The heartbeat mechanism deserves explicit specification in the interface contract: what is the heartbeat message format, what is the expected interval, and what action does the exoskeleton take on timeout? We typically specify a 20ms heartbeat interval (50 Hz) with a 100ms timeout — three missed heartbeats triggers safe state. This is conservative but appropriate for powered rehabilitation hardware.
Electrical Interface Considerations
When both EEG acquisition and exoskeleton actuators are attached to the same patient, electrical isolation is a clinical safety requirement. Leakage current from the exoskeleton actuator power supply must not flow through the EEG electrode path to the patient. IEC 60601-1 (medical electrical equipment safety) specifies patient leakage current limits; your system design must demonstrate compliance.
Practical implications for the integration: the EEG amplifier's patient connection must be electrically isolated from the exoskeleton's control electronics. This typically means the BCI compute platform connects to the EEG amplifier via USB (which has inherent isolation from the amplifier's patient-side electronics) and to the exoskeleton via a separate port with appropriate isolation requirements specified in the interface contract.
Ground loops are a persistent practical problem. If the EEG amplifier and the exoskeleton's control computer share a common ground through the patient (which can happen when both devices are connected to the same mains circuit and the exoskeleton touches the patient's body), common-mode noise from the exoskeleton's motor drivers can appear in the EEG signal as correlated noise in the 50-60 Hz range and its harmonics. This noise is in-band for some BCI frequency ranges and can significantly degrade classification accuracy.
The solution is battery-powered EEG acquisition during sessions where the exoskeleton is active, or explicitly specified ground isolation in the system hardware design. This is an integration design requirement that must be addressed in the device OEM's hardware architecture, not something that can be solved in BCI software alone. We flag it explicitly in Synaptiq's integration documentation because it is the most common source of unexplained classification degradation during first hardware integration testing.
Testing the Integration Before Clinical Use
The integration test plan for a BCI-exoskeleton system should cover behavioral verification at the interface level, not just individual component performance. Specifically:
- Verify worst-case command latency under maximum BCI processing load
- Verify that stop commands are processed with higher priority than movement commands
- Verify that heartbeat timeout correctly triggers exoskeleton safe state
- Verify that exoskeleton actuator EMG does not degrade BCI classification accuracy beyond specification
- Verify the full latency chain from motor imagery trial start to actuator initiation under representative clinical conditions
This level of integration testing is distinct from component-level software testing and requires access to the actual hardware combination. It cannot be conducted in simulation alone, and it is where interface specification errors that look fine on paper produce observable behavioral failures. Building integration test protocols into the development schedule before clinical deployment is not conservative caution — it is the minimum rigor appropriate for a powered rehabilitation device under patient use.