modem — Overview
The modem module controls the onboard nRF9151 LTE-M/NB-IoT/GPS modem over UART1 via AT commands. It is split into two modules that expose the same interface but differ in how they wait for modem responses.
| Module | Class | I/O model |
|---|---|---|
modem | Modem | Blocking — occupies the thread until the modem replies |
modem_uasync | ModemAsync | Non-blocking — yields to the uasyncio event loop while waiting |
ModemAsync extends Modem: validation logic and AT command builders are defined once in Modem and reused by both. Both classes are singletons with separate instances — do not use both in the same application.
What the modules provides
Section titled “What the modules provides”Both classes expose the same set of capabilities:
- Modem control — power states via
AT+CFUN(full RF, flight mode, off) - Raw AT I/O —
send(),read(),wait_response(),send_cmd() - MQTT client — configure, connect, publish, subscribe; connection status check
- Certificate management — write, list, read, delete credentials in the modem’s secure storage (
AT%CMNG)
ModemAsync adds one extra method not present in Modem:
recv()— suspends the calling coroutine until an incoming MQTT message arrives (unsolicited#XMQTTMSG:event)
Choose your driver
Section titled “Choose your driver”Use Modem when your script has a single flow of execution and does not run a uasyncio event loop.
Use ModemAsync when you need the modem to run alongside other concurrent tasks — timers, LED control, sensor reads, etc. Every method call must be awaited.