Electrocorticography (ECoG) sits at a specific point in the neural recording tradeoff space: better spatial resolution than scalp EEG, lower surgical risk than penetrating microelectrode arrays, and a signal quality that is well-suited for decoding the kind of broadband power changes used in motor intent classification. For rehabilitation devices that need to operate over extended periods without requiring daily calibration, ECoG is an increasingly attractive platform.
But ECoG-based rehabilitation devices introduce firmware requirements that are qualitatively different from desktop or tethered lab systems. The amplifier is implanted or semi-implanted. Power budget is constrained. Wireless data transmission introduces packet loss. Safe-state handling has direct patient safety implications. This post covers the firmware architecture decisions we have worked through for implanted ECoG applications, based on our experience building and testing the Ruten SDK against ECoG hardware targets.
Power Budget Constraints Shape Firmware Architecture
A typical scalp EEG amplifier running off USB power has a power budget that is effectively unlimited for firmware purposes. An implanted ECoG system running from a transcutaneously rechargeable battery operates under hard constraints: total system power is often in the range of 10 to 30 milliwatts. The neural recording front-end, the DSP core, and the wireless transmitter all share that budget.
The DSP core's firmware choices directly affect power consumption. Continuous full-speed processing of all ECoG channels is often not feasible within the power envelope. The firmware needs to implement an adaptive duty cycle: process at full rate when decoding activity is detected, drop to a reduced rate or selective channel mode during confirmed quiescent periods. This requires a lightweight background monitoring algorithm that runs continuously at low power and triggers full-rate processing when warranted.
In practice, we implement this as a two-tier architecture in the Ruten firmware. The background tier runs a low-bandwidth power spectral density estimate on a subset of channels, sampling at reduced rate, looking for broadband gamma power elevations that indicate intentional movement. When the background tier flags an event, it wakes the full-rate processing path. The transition adds approximately 5 ms of latency relative to always-on full-rate processing, which is within the acceptable budget for most motor decoding applications.
Clock gating and peripheral power management follow from the same principle. Every peripheral that is not actively needed should be in its lowest power state. The firmware state machine needs to track which peripherals are needed at each processing tier and transition them appropriately. This is straightforward in principle but requires careful implementation to avoid race conditions during tier transitions, particularly if an external event arrives during a transition sequence.
Wireless Transmission and Packet Loss Recovery
Implanted ECoG systems typically transmit data wirelessly to an external processing unit using a short-range protocol operating in the MICS band (402 to 405 MHz), the ISM band, or a proprietary near-field link. The physical channel introduces packet loss at rates that vary with patient movement, distance to the external unit, and RF environment. Loss rates of 1 to 5 percent are common in uncontrolled environments.
For neural recording data, packet loss has two distinct consequences. First, the recorded signal has gaps that corrupt any algorithm relying on continuous time-series features. Second, the stimulation command path, if it runs through the same wireless link in the reverse direction, may lose command packets, causing missed or delayed stimulation events.
The firmware approach to data loss recovery depends on whether the implant has sufficient local compute and memory to run decoding on-device or relies on the external processor. For decode-on-device architectures, the wireless link carries commands and status rather than raw signal, which dramatically reduces bandwidth requirements and makes packet loss less critical. For decode-on-host architectures, the implant firmware needs to implement a retransmission protocol for data gaps and a separate ARQ mechanism for command packets.
One nuance worth calling out: retransmission protocols add latency jitter that can be problematic for closed-loop timing. The recommended approach for the stimulation command path is to separate it from the retransmission queue entirely, giving it a dedicated low-latency channel with a simpler acknowledgment scheme. Missing a stimulation command is better handled by the application-layer safe-state logic than by waiting for a retransmitted command that arrives outside the therapeutic window.
Safe-State Handling for Implanted Systems
This is where ECoG rehabilitation firmware differs most sharply from research lab firmware. A desktop EEG system that crashes can be rebooted. An implanted system that enters an undefined state can deliver unintended stimulation or fail to deliver intended stimulation, both of which have patient safety implications.
The firmware safe-state design requires answering three questions: what constitutes a safe state, what conditions trigger a transition to safe state, and how does the system exit safe state reliably. Safe state for a stimulation system is stimulation off, amplifier recording halted, wireless link maintaining status telemetry only. Trigger conditions include watchdog timeout, communication link timeout, power supply undervoltage, and any decoded parameter value that falls outside pre-validated bounds. Safe-state exit requires explicit external command through the wireless link, not an automatic restart.
The pre-validated parameter bounds deserve attention. Closed-loop systems can drive stimulation parameters toward values that the algorithm finds locally optimal but that exceed safe physiological limits. The firmware layer should enforce absolute limits on pulse amplitude, pulse width, and charge per pulse that cannot be overridden by the algorithm layer. These limits are set from the physics of charge density at the electrode-tissue interface (the Shannon limit for charge density safety is well-established in the neural stimulation literature) and from device-specific impedance characterization. Ruten's stimulation command bus includes configurable parameter clamps that operate at the hardware-interface layer, below the algorithm layer, so they cannot be inadvertently bypassed by decoder updates.
Firmware Verification for Implanted Contexts
Testing firmware reliability for implanted devices requires a different approach than lab hardware testing. You cannot reboot the device mid-session to recover from a soft error. The firmware needs to be validated for extended operation durations, realistic wireless channel conditions including deliberate loss injection, and power-supply variation that simulates battery discharge over a multi-day operational period.
For the Ruten SDK integration layer, we use a hardware-in-the-loop test environment where the wireless channel loss rate is programmable, the power supply rail is controlled to simulate battery state, and the stimulator output is connected to a load bank with impedance monitoring rather than a live subject. This lets us run automated regression tests that exercise the packet loss recovery paths, the safe-state transition logic, and the parameter clamp enforcement, all in one test session without requiring benchtop hardware that exactly replicates the implanted system.
Automated testing of the safe-state logic is particularly important and often overlooked. Teams test that the system enters safe state correctly when a watchdog fires, but do not test the transition back out of safe state under adverse conditions: what happens if the wireless link goes down immediately after a safe-state entry command? What if the power supply dips during a safe-state exit sequence? The firmware state machine needs to handle these corner cases, and they need to be in the test matrix before the firmware goes into a human study.
We are not suggesting that middleware solves all of these problems. Some of them are hardware design questions that are upstream of the firmware layer. What middleware provides is a consistent boundary between the hardware specifics and the algorithm layer, which means the safe-state logic, the parameter clamps, and the wireless packet handling can be implemented once in the middleware and inherited by any hardware configuration that uses the standard adapter interface. A team that builds their closed-loop ECoG firmware on top of Ruten does not need to re-implement the safe-state state machine for each new hardware revision. They implement the hardware adapter and the safe-state behavior is inherited.