Setup
- nRF9151 (custom board + nRF9151 DK, same results on both)
- Modem firmware: mfw_nr+ 2.0.0 (MAC and PHY / full stack)
- nRF Connect SDK v3.3.0, DECT NR+ L2 (l2_dect + dect_mdm driver), star topology: 1 FT + 1 PT
- PT configured with dect_settings.power_save = true (written via DECT_SETTINGS_WRITE_SCOPE_POWER_SAVE before association; verified applied — reactivation log confirms it)
- Current measured with PPK2 (source-meter mode) on the PT while associated and idle (no application traffic)
▎
Observation
With power_save enabled and the PT idle between cluster beacons, the current floor is ~2 mA. Short RX windows on each cluster beacon are visible on top of that floor, so beacon tracking itself works as expected. Increasing the FT cluster beacon period (tested 2000 ms and slower, network beacon 50 ms) does not lower the floor — it only reduces the small beacon-RX duty component, confirming the ~2 mA is the standby baseline of the modem core, not radio duty cycle.
This matches your own blog post "Hands on with DECT NR+ API release v2.0", where the power-save demo shows ~2.2 mA idle during the radio-off periods between beacons.
Why this matters
Our product is a battery-powered sensor reporting every 12–30 s. On the same silicon, LTE PSM reaches 3–4 µA and eDRX ~38 µA, so the hardware is clearly capable of µA-level sleep. With the current 2 mA floor, keeping the PT associated in power_save is actually worse than fully deactivating the modem between transmissions (NET_REQUEST_DECT_DEACTIVATE, µA floor) and paying the full re-activation + scan + association cost every cycle (~150 ms activation, mostly CFUN). That defeats the purpose of MAC-level power save / paging.
Questions
1. Is ~2 mA the expected/official standby floor for a PT in power_save on mfw_nr+ 2.0.0, or is there any configuration (L2 settings, AT command, PHY radio mode) that lets the modem core sleep deeper between scheduled cluster beacon receptions?
2. The nrf_modem_dect.h / L2 API exposes only a boolean power_save — are there any paging-cycle / DRX-like parameters planned (e.g., sleep depth tied to the cluster beacon period), similar to eDRX on the LTE side?
3. Are there plans (and a rough timeline) for a future mfw_nr+ release with a deeper PT sleep state between beacons? Even ~100–150 µA (eDRX-class) would change our architecture from "deactivate every cycle" back to "stay associated and rely on paging".
4. If deeper sleep is not planned, can you confirm that full deactivation between transmissions is the recommended low-power pattern for periodic-reporting PT devices, so we can lock our design on that?
