nRF9151 asset tracker dies in 15–93 days vs expected ~1 year — need help isolating field-vs-lab power gap

[Akshay]

Dear Nordic Team,

We are seeking assistance in resolving a significant power consumption gap observed in our nRF9151-based asset tracker. While our lab testing suggests a battery life of approximately one year, units in the field are failing much earlier.

Setup

- Hardware: nRF9151, mfw 2.0.4, 2× EVE ER34615 in parallel (38 Ah Li-SOCl₂). Note: Two pilot units include a supercap; one does not.

- Network: T-Mobile USA, LTE-M Band 12, PSM enabled (T3324=20s, T3412=60 min granted), eDRX disabled, Onomondo APN.

- Workload: GNSS uplink every 5 minutes and shadow-delta poll every 30 minutes.

- Firmware: UART and modem traces disabled for production, IPv4-only PDN.

Observations

- Lab: Average current of 4–5 mA, with an expected battery life of 1 year. sleep current is less than 40uA.

- Field (with supercap): Battery life lasted approximately 93 days across two units.

- Field (without supercap): Battery life lasted approximately 15 days on one unit, which also experienced intermittent failures.

Questions

1. Do you have any guidance on how to identify whether this discrepancy originates from the modem side or specific network behavior?

2. What is the recommended debugging approach for this issue? Should we focus our efforts on modem traces, network signaling analysis, or both?

We would appreciate any insights you can provide to help us isolate this field-vs-lab power gap.

Best regards,

Akshay

[Øyvind]

Hello Akshay, 

1. Do you have any guidance on how to identify whether this discrepancy originates from the modem side or specific network behavior?

We will modem traces from the failing devices in regards to possible bad connection/coverage. Looking at the battery it does not seem to support the possible current consumption the device can pull. Have you done measurements out in the field?

2. What is the recommended debugging approach for this issue? Should we focus our efforts on modem traces, network signaling analysis, or both?

Both would be good in this situation.

Kind regards,
Øyvind

[MidhunSqt]

Hi Oyvind ,

  Thank you for the quick response. Myself Midhun I am working with Akshay on this Project. The battery is supported with supercap to mitigate such Burst pulse handling, that is how we designed it. Does that suffice? or do you have any suggestion for other battery chemistries that support such pulse current handling capability while has good capacity (10-20Ah). 

Unfortunately, we don't have modem trace log of the failed products with us we only have signaling logs. In our application we can't integrate complete modem trace as the RAM limit is crossed. Can we check it through AT commands to find any abnormal behavior of the modem which consumes more current than expected like abnormal RRC Connection counts or session creation counts ..etc ?

[Øyvind]

MidhunSqt said:

Unfortunately, we don't have modem trace log of the failed products with us we only have signaling logs.

What information does the signaling logs provide? 

MidhunSqt said:

Can we check it through AT commands to find any abnormal behavior of the modem which consumes more current than expected like abnormal RRC Connection counts or session creation counts ..etc ?

Signal conditions would be a good indication. I.e. one of the combinations that quickly kills product battery life is the combination of bad coverage and a battery that does not suffice. This is often why lab vs field will give that much difference in expected life time. How do you know that the device is in PSM? Where are you testing?

MidhunSqt said:

or do you have any suggestion for other battery chemistries that support such pulse current handling capability while has good capacity (10-20Ah). 

I will query internally of what could be a sufficient battery for 1 year battery life.