The point about starting from the measured sleep floor rather than the datasheet number matches what I see on small ESP32 builds, where regulator quiescent current and a leaky divider often outweigh the chip itself. Have you found that wake-up retries in weak signal are usually the biggest single drain in the field, or is paging/PSM timer config a bigger factor? A quick tip: logging charge used per report cycle (not just average current) makes those retry spikes easy to spot.
Thanks, and good tip on logging charge per report cycle. It is the quickest way to separate retry spikes from the baseline.
On your question: in weak-signal sites the retries usually dominate. Each failed attach or resend keeps the radio at its highest current for seconds, while PSM/eDRX timers mostly set the floor between reports. The two interact, though: the network can grant shorter PSM or eDRX timers than the device requested, so the unit wakes more often, and in poor coverage every extra wake brings its own retry series. So we would first check the timers the network actually granted (AT+CEREG=4 shows the granted T3412/T3324), then count retries per cycle. Randomised back-off after failures, as GSMA TS.34 recommends, also stops a whole site from retrying at the same moment.
Yunus Emre Vurgun
Writing about AI agents, hardware, and practical software.
The point about starting from the measured sleep floor rather than the datasheet number matches what I see on small ESP32 builds, where regulator quiescent current and a leaky divider often outweigh the chip itself. Have you found that wake-up retries in weak signal are usually the biggest single drain in the field, or is paging/PSM timer config a bigger factor? A quick tip: logging charge used per report cycle (not just average current) makes those retry spikes easy to spot.