Basic DECT support

[chrysn]

I'm not sure what of this has a place in this library, and this is all immature, but if nothing else, serves as a coordination point.

This PR contains updates and an example of using the nRF9151 in DECT mode. This has large overlaps in terms of setup and infrastructure (handler forwarding and all that), but after setup, paths diverge.

This

• updates nrfxlib (might be a candidate for a standalone PR once nrfxlib is released)
• uses that firmware in DECT mode, thus providing a test app for Make the DECT-2020 NR+ libmodem.a available as a feature nrf-rs/nrfxlib-sys#16
• splits the modem initialization up at a point where it can be used for DECT too
• provides a quick-and-basic DECT setup function (with completely non-thought-through abstractions on state, and many hardcoded parameters and choices)
• provides an example that uses the DECT module's RSSI indicator to get a visual representation of the level of radio chatter on the bands.

It is probably not this library's intention to serve as a full DECT library. If that is so, I see two possible cutting points to which this could be trimmed:

1. We could just have the bare minimum in here, and make init_with_custom_layout_core pub (that is init_with_custom_layout up to the point where the AT commands would begin, which the DECT firmware doesn't do, at least that way). Then, users would use this crate's core setups, including all the libc mangling, handler setup and log processing, and go their merry ways calling unsafe nrfxlib-sys functions.
2. This crate could provide safe wrappers for the DECT API surface (roughly as it is now, but this is all very sketch).

Either way, higher-layer functionality, DECT services and whatsonot should probably live in https://github.com/ariel-os/hophop.

Where do you think would be a sensible library boundary? I'd be happy with either 1. or 2., but maybe I missed other options.

---

As this is currently pretty much impossible to try out without contact to Nordic sales (see nrf-rs/nrfxlib-sys#16), here's a screenshot of the Python visualization of the RSSI report:

[diondokter]

Very cool!

So about how everything should be structured:

• Having this repo, nrf-modem, as the base layer for initialization and setup makes some sense.
• But the goal of this crate (in the readme) is:

  This is a library that provides a high-level async API for the modem on the Nordic nRF91* series chips

• So just having the low level parts is a bit counter to what this crate is made for
  • This can be changed. It makes sense to not duplicate the ffi layer and modem init in another crate
  • There is precedent for this as there's also an embassy-net feature exposed

So I think mainly this decision needs to be made:

• Are we exposing an interface hophop or another DECT stack can use? And the user uses the high level api's of the stack?
• Or are we keeping everything internal? The user doesn't see (much of) hophop and the high level api's are implemented in nrf-modem

I don't know what a DECT stack looks like, so it's hard for me to judge.

Another issue of course is maintenance.
I don't have hardware or access or any way of testing. This is true for the nrf9151 too, but it's similar enough to the 9160 that I've managed to keep everything working just fine.
So if there's gonna be a big DECT component, that's gonna be a problem. The hardware problem could be solved of course, but I'm not super stoked about buying an nRF9151-DK for €100 with my own money...

[chrysn]

I don't know have the full picture of what a DECT stack looks like either. But there's quite a bit of it on top of the PHY (which the nRF91xx series provides) – a MAC layer that decides whom to talk to when, a "DLC" layer that implements low-layer mesh and forwarding, and then a "CVG" layer with application multiplexing, end-to-end security, eventually fanning out to applications or IPv6.

With hophop I hope to keep as much of it hardware independent as I can, facilitating porting to different hardware.

Combining this with what you've written, I don't think a full-high-level provider is practical -- it just doesn't exist yet, and it's also not as simple as "here's your network interface, it's all set up from the modem, enjoy your pings". What we could do is

• Aim for the highest level of PHY APIs that make sense. That API would be shaped around how the modem works (like, almost everything is an operation scheduled on the modem's 64bit 69MHz clock, and events are returned on that).
• Optionally, as hophop develops, we could consider whether there can be a feature to pull it in and offer a configured full stack – if that provides any simplifications over a fantasized hophop.init(nrf_modem::init_dect().await?).await?.

As for possibilities for review: I'll look into possible solutions; mostly, though, the first show stopper is the lack of radio core firmware availability.

[chrysn]

Coarse status update: Making progress on the interfaces, but they're still in flux a lot while I'm building initial applications to hammer out how they would eventually be used.

As pushing to the branch probably triggers your notifications, feel free to unsubscribe from it: I'll ping you when there are updates on the hardware-and-firmware availability (WIP), or it is ready to review (which kind of implies the former).