Spinel over SPI and UART: driving the Opener DECT NR+ radio from a host

Why a host protocol?

In our Opener status update, we explained that the stack is built bottom-up and that only the driver is finished today. Our boards need more than a driver, though. The NR+Gate pairs an nRF9151, which carries the NR+ modem, with a Rockchip RK3566 Linux module. To run a sniffer, a web UI or a test tool on that gateway, the Linux software has to be able to control the radio.

That is exactly OpenThread's RCP (Radio Co-Processor) model: the radio microcontroller runs only the real-time part, and a host drives it over a serial link using a protocol called Spinel. We chose to reuse Spinel rather than design our own protocol, for three reasons:

• A proven format: compact type encoding, transaction IDs, generic get/set/insert properties, and ranges reserved for vendor extensions.
• Existing transports: HDLC-lite framing for UART and OpenThread's SPI framing are specified and widely deployed.
• Reusable tooling: OpenThread's C codec drops in as is, and a tool like pyspinel can talk to an Opener device.

Layered control

This first version exposes the driver level. The host schedules radio operations (TX, RX, RSSI1), reads the modem time and the radio capabilities, and receives the driver events. The MAC, DLC and convergence layers then run on the host. Property ranges are reserved for the higher levels: once the embedded stack has a MAC, a later version can expose it without breaking the protocol.

The device advertises the levels it exposes in PROP_CAPS and identifies itself with a new interface type, 0x4E52 ("NR"). A host that only speaks the Thread or IEEE 802.15.4 properties simply gets PROP_NOT_FOUND.

From the Opener driver to Spinel properties

The design work consisted of mapping each function of the Opener driver API (dectnrp_driver.h) to a Spinel command on a property. The result fits in about ten properties:

Operations: a token chosen by the host

Most of the work goes through DRV_OP_QUEUE. Each insert carries a common prefix (token, type, channel, flags, start time in modem ticks), followed by a suffix specific to the operation type: modulation parameters and data for TX, duration and expected RSSI for RX, number of subslots for RSSI1. The flags cover scheduling, LBT, HARQ, beacons and reception mode. The device rejects any flag that makes no sense for the operation type with INVALID_ARGUMENT.

The token is chosen by the host and must be unique among the operations in flight. The device replies INSERTED once the driver has accepted the operation, and every event that follows carries the token. Driver errors are translated into Spinel statuses: -ENOMEM becomes NOMEM, -EBUSY becomes BUSY, and so on. Other errno values are passed through in a vendor status range.

Explicit delivery guarantees

A host that drives a radio remotely needs to know when it can reuse a resource. So we wrote the contract down:

• after INSERTED, the device sends exactly one OP_FINISHED event for the token, and it is the last event of the operation;
• the other events share a buffer pool. When it is full, they are dropped and counted, and the number dropped is reported in the next event sent;
• OP_FINISHED has its own buffer per operation slot: it is never dropped, so the host never waits forever;
• CMD_RESET stops the driver, waits for the operations to finish, frees every slot and invalidates every token, without rebooting the device.

# Host → device: TID 1, CMD_PROP_VALUE_GET, PROP_PROTOCOL_VERSION
7E 81 02 01 <FCS> 7E

# Device → host: TID 1, CMD_PROP_VALUE_IS, PROP_PROTOCOL_VERSION = 4.3
7E 81 06 01 04 03 <FCS> 7E

The implementation in Opener

The Spinel interface is an optional Opener subsystem (subsys/spinel). It sits between the driver and the transport, and is split into blocks with clear responsibilities:

All memory is bounded and sized through Kconfig: 8 operation slots, 16 event buffers, and 4 receive and 4 transmit buffers by default, with frames of at most 1300 bytes (the NR+ MTU plus headers). There is no dynamic allocation. Enabling it takes a few lines:

CONFIG_NETWORKING=y
CONFIG_DECTNRP_DRIVER_SCHEDULED_API=y
CONFIG_DECTNRP_SPINEL=y

UART: HDLC-lite

On UART, frames use Spinel's HDLC-lite framing: 0x7E flag bytes, escaping of control bytes and a CRC-16/X-25 FCS. Both directions are interrupt-driven, at 1 Mbaud. Hardware flow control is essential: without it, the UARTE loses bytes from the host whenever its interrupt is served late. This is the transport we use with the nRF9151 DK and nRF9131 EK development kits, plugged into a PC over USB.

SPI: OpenThread framing, plus a BUSY line

On the NR+Gate, the nRF9151 is an SPI slave of the RK3566. We reuse OpenThread's SPI framing: every transaction starts, in both directions, with a 5-byte header (flags, largest frame accepted, length of the frame sent), followed by the raw Spinel frame, without HDLC.

&spi2 {
        compatible = "nordic,nrf-spis";
        def-char = <0xff>;

        spinel@0 {
                compatible = "opener,spinel-spi";
                reg = <0>;
                spi-max-frequency = <8000000>;
                irq-gpios = <&gpio0 9 GPIO_ACTIVE_HIGH>;
                busy-gpios = <&gpio0 26 GPIO_ACTIVE_HIGH>;
        };
};

SPI raises a problem UART does not have: the slave cannot send anything until the master clocks, and a transaction started while the slave is not ready is lost. Two lines therefore complete the bus:

• IRQ: the device has a frame for the host;
• BUSY, our extension to the OpenThread specification: the device is not ready for a transaction. It goes busy at the end of each transaction and releases BUSY once the next one is armed, after updating IRQ. The host therefore reads IRQ only while BUSY is inactive.

To cut latency, the device holds BUSY after a transaction that brought it a request, for at most 2 ms by default, until the reply is ready. The reply then goes out in the host's next transaction, which can itself carry the next request: a round trip takes two transactions. And if no host reads, the frames queued behind the offered frame are dropped after one second, so the buffers do not run out.

Hardware note: the SPI slave controller's default character (def-char) is set to 0xFF. A transaction clocked while the device is not armed therefore reads an invalid header, which the host safely ignores.

The dectnrp-spinel sample in opener-samples provides a ready-made firmware: UART for the nRF9151 DK and nRF9131 EK, SPI for the NR+Gate. Its main() only prints a banner: the interface starts on its own at boot.

Testing with Twister

A radio control protocol is hard to test by hand: the interesting bugs live in the edge cases (pool full, reset during an operation, an SPI transaction at the wrong moment). So we wrote the tests along with the code, using ztest and Twister, Zephyr's test runner. Everything runs on native_sim, with no hardware.

Two building blocks make these tests possible. A mock driver implements the Opener driver API with a simulated 69.12 MHz modem clock: tests choose which events it returns, or let it generate traffic on its own. A fake SPI slave controller, declared in the test devicetree, lets the test play the master one transaction at a time and check the IRQ and BUSY lines at every step.

west twister -T deps/dectnrp-opener/tests/subsys/spinel -p native_sim/native/64

The simdev scenario deserves a mention. It builds a complete Spinel firmware for native_sim, with the mock driver, and exposes the Spinel UART on a pseudo-terminal of the PC. To the host, it is a real device: our host-side integration tests connect to it as they would to a real board. The protocol is thus tested end to end, firmware and host together, with no hardware at all.

Then on real hardware

Tests on native_sim validate the logic, but not the electrical behaviour of a real bus. So the interface was also tested on our NR+Gate: the dectnrp-spinel firmware on the nRF9151, driven over SPI by the RK3566, with real NR+ frames on the air. That is the setup that ran our demos at the DECT World 2026 pre-event, both for sniffing and for remote control.

What's next?

A Spinel host interface is in the "beyond" part of the Opener roadmap. Our implementation currently lives on the spinel-ctrl branch of our public Opener fork, and we intend to propose it upstream. A few points remain to be discussed with the community:

• the interface type value (0x4E52) and the vendor ID, to be agreed upstream with Spinel;
• the optional CRC of the SPI framing, which we do not support yet;
• exposing the MAC, DLC and CVG levels, once those layers exist in the embedded stack.