Long-running connections fail due to low-battery

RE: Long-running connections fail due to low-battery

dan_opito — Sun, 16 Mar 2025 21:09:32 GMT

Yes, I should be clear - I am using `lte_lc_normal()` to run `AT+CFUN=1` to re-enable the modem. If that call fails for some reason, my firmware will reboot. I have watched this code run, in the logs, and seen that the connection comes back and my application continues running.

I wouldn't say it's a fix as much as a work-around!

RE: Long-running connections fail due to low-battery

Achim Kraus — Sat, 15 Mar 2025 07:25:49 GMT

> I catch the low battery event, read the battery voltage with `AT%VBAT` for my logs, and then call `AT+CFUN=1` to reenable the modem.

So, if you have verified, that it is simply a glitch of the power rail and not the "new zephyr" codebase, `AT+CFUN=1` helps well.

Just to mention:

Using `AT+CFUN=1` will require to reenable some events or modem configs. That is usually done with "lte_lc_normal()" and the standard callbacks added by the nrf-library. For some custom stuff, a "LTE_LC_ON_CFUN" handler helps.

RE: Long-running connections fail due to low-battery

dan_opito — Sat, 15 Mar 2025 01:49:39 GMT

Hi Achim. Thanks for your insights. I have been working with a Nordic engineer on this issue - and he, like yourself, suspected power supply issues. Our design, unfortunately, has a flaw that means the VDD rail of the modem can drop - and this is due to a ferrite bead we have in series. I haven't been able to capture it on an oscilloscope, but by raising the `AT%XPOFWARN` to a higher voltage, I can more readily produce the same fault.

My fix is necessarily in software. The asset tracker is designed to catch the PDN context going down (I'll be honest, I'm not familiar with what a PDN context is) - however in this fault the modem doesn't include any further notifications. I catch the low battery event, read the battery voltage with `AT%VBAT` for my logs, and then call `AT+CFUN=1` to reenable the modem. The specific low-voltage event is only caused by large current draw (such as low signal strength like you said) - so we can be confident that event has passed.

The correct fix is updating our circuit by adding a capacitor on the VDD pin (instead of through a ferrite bead) - but we also need to make what we have work and I think this fix will do so.

One other change I made was the reconnection logic. Rather than using exponential back off, I just try every minute for an hour before deciding it's never going to work and reboot the device. For our application - where devices are supposed to be online all the time - this logic will work fine.

RE: Long-running connections fail due to low-battery

Achim Kraus — Fri, 14 Mar 2025 06:32:15 GMT

I'm not that sure, that the "battery low" event should be ignored.

Even if your 7.4V battery will hardly go down to the 3V, I guess, that 7.4V are not connected directly to the nRF9151 VDD, or? So there is a component in the power rail, which may cause that drop. You may check the voltage at VDD using an AT cmd "AT%XVBAT".

> However, we notice all our devices running our "new zephyr" codebase are less stable

There are many factors that pays in to this topic, e.g. varying radio signal strength, other MNO and so on. So I would not expect, that the "zephyr codebase" (running on the app mcu) has a that large effect on the power consumption of the modem on the SoC. What may have changed is the handling of the "battery low" events and how the "battery OK" is detected afterwards. But I'm not common to the asset tracker, so that's out of my knowledge.