Decode the Granted PSM and eDRX Timers Before Trusting a Battery Number

Two Timers, Two Encoding Schemes

PSM uses two timers negotiated during LTE attach: T3412 extended (Periodic TAU timer) sets how long the device stays asleep before it must perform a Tracking Area Update with the network. This is the big number - the one that dominates battery life. T3324 (Active Time) sets how long the device stays reachable in RRC Idle after a data exchange, before it drops into PSM. This is the small number, typically seconds to a few minutes. The sleep duration is T3412 minus T3324. A device with a 4-hour T3412 and a 20-second T3324 sleeps for 3 hours, 59 minutes and 40 seconds per cycle.

Both timers are encoded as single bytes, but they use different encoding tables from 3GPP TS 24.008.

T3412 Extended - GPRS Timer 3

The three most significant bits select the unit. The five least significant bits carry the multiplier.

So 01000011 is 010 (10 hours) × 00011 (3) = 30 hours.

T3324 - GPRS Timer 2

Same structure, different unit table.

So 00001000 is 000 (2 seconds) × 01000 (8) = 16 seconds.

Notice that the same three-bit code means different things in Timer 2 and Timer 3. 000 is 10 minutes in T3412 but 2 seconds in T3324. Swap the tables and your battery estimate is off by a factor of 300.

Requesting Is Not Receiving

You request PSM parameters with AT+CPSMS before the modem attaches:

AT+CPSMS=1,,,"00100100","00001010"

The third quoted field requests a T3412 of 001 (1 hour) × 00100 (4) = 4 hours. The fourth requests a T3324 of 000 (2 seconds) × 01010 (10) = 20 seconds. The modem sends this in the Attach Request. The network returns what it actually grants in the Attach Accept. The AT command returns OK regardless - OK means the modem accepted your request and will forward it, not that the network agreed.

To read what the network actually granted, query the registration result:

AT+CEREG?

In mode 4 or 5, the response includes two extra fields at the end: the granted T3324 and the granted T3412 extended, both as quoted eight-character binary strings. These are the values the network is enforcing. If T3324 comes back as 11100000, active time is deactivated - the network rejected PSM entirely.

Here is the part that wrecks battery calculations: the network is under no obligation to grant what you requested. It may shorten your T3412. It may grant the non-extended T3412 format instead of the extended one, capping your sleep at a shorter ceiling. It may deactivate PSM altogether. None of this generates an error.

An nRF9160 developer on Nordic's DevZone requested a specific TAU interval from China Mobile and received 54 minutes instead. Nordic's own engineer confirmed: "The value of timer T3412 is sent by the network to the UE in the ATTACH ACCEPT message." The carrier controls the interval, and getting a different one may require a dedicated APN.

eDRX Has the Same Problem, Smaller

eDRX extends the interval between paging occasions - the moments when the device listens for downlink data. Instead of waking every 1.28 or 2.56 seconds to check for pages, the device and network agree on a longer cycle.

You request it with:

AT+CEDRXS=2,4,"1001"

Mode 2 enables eDRX with unsolicited result codes. AcT type 4 is LTE-M (5 for NB-IoT). The four-bit value 1001 requests a 163.84-second cycle for Cat-M1. The available cycle lengths are fixed by the standard:

To check what the network actually granted:

AT+CEDRXRDP

The response returns four fields: the access technology, the requested value, the network-provided value, and the Paging Time Window. When the requested and network-provided values differ, the network rejected your cycle length and substituted its own.

Qoitech's measurements with the Otii Arc Pro showed this in current traces: a device requesting one eDRX cycle and receiving another produces a power profile that matches neither the requested configuration nor the datasheet's nominal figure. Their conclusion: "These differences are impossible to detect in firmware logs or modem responses. Only current trace measurements reveal the true power impact."

Where the Battery Estimate Breaks

A standard battery calculation for a PSM device looks like this:

1. Measure the sleep current (1-5 µA for most LTE-M SiPs in PSM)
2. Measure one wake cycle: modem-on → TX → RX → return to sleep
3. Compute average current: (sleep current × sleep time + wake current × wake time) / total cycle
4. Divide battery capacity by average current

The number that comes out depends almost entirely on the sleep-to-wake ratio. A device that sleeps for 4 hours and wakes for 12 seconds has a duty cycle below 0.1%. A device the network forces to wake every 54 minutes has a duty cycle roughly four times higher, and the battery life drops by roughly the same factor.

Nordic's blog documents a PSM sleep current of 3.3 µA on the nRF9160 SiP (revision 2), measured with a PPK2 in source meter mode at 3700 mV. That measurement included 1 Hz spikes from the DCDC refresh circuit. The modem shuts down the SIM card automatically during extended PSM sleep, so SIM current is typically zero - but this depends on the SIM supporting it.

The Online Power Profiler takes your requested timer values and outputs a battery estimate. It does not query the network. It does not know what the network granted. If you feed it your requested 4-hour T3412 and the network is enforcing 54 minutes, the tool's estimate is wrong by the ratio of those two numbers.

The Measurement That Matters

The only reliable battery number comes from measuring the actual device on the actual network with the actual SIM, in the actual radio conditions of deployment. The PPK2 in source meter mode captures the full current profile: sleep baseline, DCDC spikes, modem wake, RF transmission, reception, and the return to sleep. One captured cycle, with the granted (not requested) timer values read from AT+CEREG?, gives you the real duty cycle.

Even that measurement has a catch. The granted timer can change. A device that roams to a different cell may receive different T3412 and T3324 values. A firmware update that triggers a new attach may negotiate different parameters. A network configuration change on the operator side may alter what's granted - without any change on the device.

For a product shipping in quantity across multiple operators and regions, the granted timer is a variable, not a constant. The battery estimate is a range, not a number. And the lower bound of that range is set by the least generous operator, on the weakest cell, at the worst time - which is information you only get by reading the granted values from devices already deployed.

A Checklist That Fits on a Sticky Note

• Call AT+CPSMS and AT+CEDRXS before AT+CFUN=1. Timers requested after attach are not negotiated until the next TAU.
• After attach, read AT+CEREG? (mode 4 or 5) and AT+CEDRXRDP.
• Decode both granted values using the correct encoding table - Timer 3 for T3412, Timer 2 for T3324.
• If T3324 comes back 11100000, PSM was rejected. If the eDRX network-provided value differs from requested, the network substituted its own cycle.
• Log the granted values in your application. They can change on reattach, cell reselection, or TAU.
• Run one PPK2 capture of a complete sleep-wake cycle using the granted (not requested) intervals.
• Compute average current from that trace, not from the Online Power Profiler.
• If the granted T3412 is shorter than what your battery budget requires, contact the operator about a dedicated APN with longer intervals. This is a commercial negotiation, not a firmware fix.

The ten-year battery claim on the product page is a number that came out of a calculator. The five-year battery life in the field is a number that came out of a measurement. The distance between them is usually a network operator who never agreed to the timer values you assumed.