dectnrp_nrf91x1: first driver implementation by RainerSchubert · Pull Request #3 · Opener-Initiative/opener

RainerSchubert · 2026-07-14T17:10:03Z

A first shot dectnrp_nrf91 driver implementation is added.

This PR can be setup/build/debugging and tested in combination with Opener-Initiative/opener-samples#1.

You can "easily" follow the steps in README.md. This branch of this PR gets automatically checked out by west.

RainerSchubert · 2026-07-14T17:16:24Z

Also here:
All the l2 protocol header files should live in include/zephyr/net
https://github.com/zephyrproject-rtos/zephyr/tree/zephyr-v3.5.0/include/zephyr/net
Naming should be similar to ieee802154_...

RainerSchubert · 2026-07-14T17:24:47Z

+			 */
+			uint8_t phy_header_type :1;
+			/** Transport parameters related to this operation */
+			struct dectnrp_transport_parameters transport_parameters;


Packet related parameters as transport parameters phy_header_type etc are currently implemented that way as we can not inject a control-block directly into net_pkt as for example ieee802154 does
https://github.com/zephyrproject-rtos/zephyr/blob/1ce2060f563897d4430d66c111a77cbc611634a7/include/zephyr/net/net_pkt.h#L354.

But we could use the generic one and append packet related parameters directly to the packet.

/* Control block which could be used by any layer */ union { uint8_t cb[CONFIG_NET_PKT_CONTROL_BLOCK_SIZE];

https://github.com/zephyrproject-rtos/zephyr/blob/1ce2060f563897d4430d66c111a77cbc611634a7/include/zephyr/net/net_pkt.h#L349

RainerSchubert · 2026-07-14T17:32:57Z

+			/** RSSI2 value of this message.
+			 *  Encoded according to @ref ETSI TS 103 636-2 chapter 8.3.
+			 * 
+			 * @todo It needs to be decided whether we want to transmit the RSSI2 according to spec.


I have chosen the format according to ETSI TS 103 636-2 chapter 8.3 because it is saving space.
But we pay for that by more overhead when decoding encoding.

Maybe for single RSSI2 values it would be more useful to have int16_t with simple integer values.
It takes one byte more but saves the hassle of encoding/decoding.

For RSSI1 I choose the format according to ETSI TS 103 636-2 chapter 8.2 (same as RSSI2) because there are a lot more values to handle. There I think it makes sense to save memory.

it depends on what you are using it for; RSSI2 is better for computing/calculations and RSSI is ok for human readable.

RainerSchubert · 2026-07-14T19:52:47Z

+			/** Related start time. */
+			net_time_t start_time;
+			/** Points to PCC.  */
+			const uint8_t *pcc;


With this implementation I decided to use the event interface in interrupt context. With this implementation the events are notified directly in interrupt context of the IPC. That means the upper layer (presumable the scheduler) finish this interrupt as fast as it can.
Decision needed: Do we want the event interface be an interrupt.

With this implementation I decided also to hand the PCC and PDC to the upper layer as raw pointers into IPC buffers. The upper layer (presumable the scheduler) has the flexibility how to handle it. But as we are in interrupt context anyway the scheduler has to make a copy and finish the interrupt as fast as it can.

Naturally I would prefer a net_pkt instead of raw pcc + pdc. But that may involve duplicate copying of data. If we do decide to use a net_pkt the driver is responsible of copying data into it.
In that case

we can also manage meta data related to the message in the context block of the net_pkt.

the driver needs to get the net_pkt for example via struct net_pkt *pkt = net_pkt_rx_alloc_with_buffer(ctx->iface, packet_size, AF_UNSPEC, 0, K_MSEC(100));

Decision needed: Do we want to use net_pkt to transfer messages (pcc alone, pcc+pdc) via event interface.

I think that copying data here now is fine. If we do want to optimize that later, we might sidestep some of libmodem's memory management and then let the radio core write the data right into the right place in a net_pkt.

For me using net_pkt for events passing is too much work at this stage, would involve copying in the driver, notify the scheduler, handling net_buf allocation and associated errors, etc...

As for latency concerns, having the scheduler handling events in interrupt context and decide if it takes action immediately or defer processing is beneficial, so I think passing raw pointers in interrupt mode and make the scheduler copy data and return is the right choice for now (at least until we can have net_pkt directly wired at libmodem's memory management layer like @chrysn suggested)

So for now I am going to leave it the "raw pointer" way.

RainerSchubert · 2026-08-11T16:43:10Z

-struct dectnrp_rssi_mode {
-	uint8_t _dummy;
+	/** The result holds the rssi1 dbm values for each sub-slot for one frame. */
+	uint8_t subslot[DECTNRP_SUBSLOTS_PER_FRAME];


I decided to have a resolution of subslots for reported RSSI1 results.
We also could choose the per symbol resolution as Nordic reports it but that consumes a lot more memory (5*48 = 240).
I may see a use-case for the per symbol resolution to make the scheduling (frame start placement) more fine granular.
Also we have to support sub-frame/per-slot/per-subslot measurement.
We anyway have to deal with a more flexible solution here when we start supporting µ>1..

RainerSchubert · 2026-08-11T16:51:09Z

+ * @param data
+ * @param len
+ */
+static void rssi1_accumulate(struct dectnrp_driver_op *op, int8_t *data, uint16_t len)


As decided with the dectnrp_driver_api

850c0ed#r3759909992

we currently accumulate RSSI1 symbol values into RSSI1 sub-slot values.
Accumulate means we pick the maximum value out of 5 rssi1 (per-symbol) values.

RainerSchubert · 2026-09-03T11:04:03Z

 };

-union dectnrp_event_data {
+enum dectnrp_driver_error {


I started to add some enumerated error codes. This should be discussed.

In my opinion generic posix errno are not fine granular enough to differentiate errors of dectnrp_driver.

I agree, these can be added as the work progresses and they are justified

WilliamGFish · 2026-09-09T14:14:54Z

+
+#if CONFIG_DECTNRP_DRIVER_BLOCKING_API
+
+static int nrf91_set_channel(const struct device *dev, uint16_t channel)


Should we be considering the use of zephyr inbuilt network management functionality (NET_MGMT). If the application changes the channel, tx power, etc it could be dangerous as it does not have access to the resource and scheduling functions.
For early samples it is of minimal importance but long term could be a n issue.

I agree, I think we should indeed use Zephyr network management, but we should be careful where to wire it within the stack since we will have non Zephyr users like @chrysn with Ariel OS, who will probably not be able to reimplement the whole Zephyr network management subsystem. This is surely something we should discuss and plan.

Yes net_mgmt is the way to go. But here we have the driver interface, I think the net_mgmt should go to l2 layer which may use driver api to change something in the driver. That is also the way ieee802154 does use it.

Also that nrf91_set_channel function will not be needed as channel should be set per operation.

WilliamGFish · 2026-09-09T14:29:22Z

+{
+	char fw_uuid_buf[64];
+
+	int ret = nrf_modem_at_cmd(fw_uuid_buf, sizeof(fw_uuid_buf), "AT%%XMODEMUUID");


I am a little confused with the use of AT commands rather than function calls:
hwinfo_get_device_id(*uint_16 device_id, sizeof(device_id));

The modem build UUID describes the modem firmware build, it is not the same as the device id returned by hwinfo_get_device_id (u64 stored in the FICR)

I have not found a function to retrieve the modem build UUID in the modem / nrfxlib library (but I may have missed it)

i can not see it either but we should talk to Lauri about this being part of the modem firmware as in future releases certain functionality will be reliant on the firmware version installed.

WilliamGFish · 2026-09-09T14:50:12Z

+	*mfw_version = RADIO_MFW_UNKNOWN;
+	char fw_version_buf[32];
+
+	int ret = nrf_modem_at_cmd(fw_version_buf, sizeof(fw_version_buf), "AT+CGMR");


again an AT command rather than direct function call.
They should have an easy method for modem firmware version query

I have not found a function to easily retrieve the firmware version, and as this AT commands is an officially documented way to get it and we only check it at init, I think it is fine

But it works and as it is the "official" way of retrieving uuid and mfw I think for now it should be OK.
It anyway is a wrapper around the IPC and AT commands is just a "string API" to access the modem firmware.

bullekeup · 2026-09-10T09:36:06Z

I have reviewed and tested on my two nRF9151 DKs, everything works as intended first try !

Before merging, I think we should apply the rename refactor from nrf91 to nrf91x1 to be more descriptive of the intended target (but I will not block merging on that if everyone else is OK with current naming)

@po3ts @chrysn what's your view on this ?

WilliamGFish

LGTM but I have questions about the use of AT commands with the driver

po3ts · 2026-09-10T11:48:30Z

I have reviewed and tested on my two nRF9151 DKs, everything works as intended first try !

Before merging, I think we should apply the rename refactor from nrf91 to nrf91x1 to be more descriptive of the intended target (but I will not block merging on that if everyone else is OK with current naming)

@po3ts @chrysn what's your view on this ?

I support renaming to nrf91x1. I still have to run it on my boards, though. I'll do that either this evening or tomorrow morning...

RainerSchubert · 2026-09-10T14:42:35Z

So I am going to rename nrf91 -> nrf91x1.
It seems a democratical consensus ;)

RainerSchubert · 2026-09-10T14:44:35Z

LGTM but I have questions about the use of AT commands with the driver

We have no other solution for that merge (or do we have one!?) .. I think Nordic will not change it in the near future.

po3ts · 2026-09-12T14:46:09Z

Just ran it on my nRF9151 DKs, worked out of the box! This is ready to merge from my side once the nrf91x1 rename is in.

* improved the dectnrp_driver_api * first implementation of nrf91x1 driver * implements scheduled api with rx, tx, rssi1 operations * DECTNRP_DRIVER_NRF91X1 depends on SOC_SERIES_NRF91X * added static driver capabilities hard-wired via kconfig * add first simple DECTNRP_L2 draft Signed-off-by: Rainer Schubert <rainer.schubert@deveritec.com>

RainerSchubert · 2026-09-14T18:54:21Z

I changed (hopefully) every occurrence of nrf91 to nrf91x1 (both lower and upper case and also filenames).

WilliamGFish

LGTM...if you guys test on hardware then ok with me

po3ts

That's very good work, @RainerSchubert! Ready to merge from my side.

po3ts · 2026-09-18T09:08:44Z

@bullekeup and @chrysn, we need one additional approval before this can be merged into main. Can one of you please approve the changes?