Hardware: RAK3172-T, RUI3 4.2.4, LoRa P2P mode, custom firmware built in Arduino.
I am building a battery-powered product where the RAK3172 spends almost all of its life listening for an occasional command. Target standby life is six months on the pack, so receive current dominates the entire design.
Today the only way to duty-cycle the receiver in P2P is from the application: start a timer, call api.lora.precv(65535), and call api.lora.precv(0) when the window closes. That works, but an armed receiver keeps the MCU awake for the whole window, so the duty cycle costs both radio and MCU current.
Measured on my board, referred to the pack:
Continuous RX (precv armed) 2.05 mA
MCU asleep via lpm, radio stopped 0.17 mA
Computed at a 100 ms / 1000 ms duty cycle ~0.36 mA
The SX1262 already supports this in hardware. SetRxDutyCycle (opcode 0x94) has the radio alternate RX and sleep on its own, latch on preamble detect, and raise DIO1 only when a packet actually arrives. The MCU never wakes for an empty window. With a suitably long preamble this should bring the average close to the sleep floor.
The SX126x driver in the RUI3 BSP already contains the call - it just is not reachable from the P2P API. Would it be possible to expose it? Something like:
api.lora.precvduty(rx_period_ms, sleep_period_ms)
AT+PRECVDC=<rx_period>,<sleep_period>
with 0 reverting to normal behaviour, would be enough.
Is this feasible, and is anything like it on the roadmap? If there is a way to reach the underlying radio driver from an Arduino sketch under RUI3 today, I would be glad to hear that instead.
Thanks.