The AT+CFUN=0 take long time sometimes

[Tim Chao]

Hi,

I am developing a low-power device to periodically publish data.

I need to turn off the modem after the publishing task is completed.

And I found that sometimes the AT+CFUN=0 takes a long time to get response.

Below is the code piece for turn-off the modem.

// turn-off modem ~
int64_t start = k_uptime_get();
err = lte_lc_power_off();
int64_t end = k_uptime_get();
LOG_DBG("AT+CFUN=0 done (%5llu ms)", end - start);

And here are some logs I got.

[00:11:31.559,295] <dbg> modem: modem_power_off: AT+CFUN=0 done (  707 ms)
[00:12:35.537,811] <dbg> modem: modem_power_off: AT+CFUN=0 done ( 3034 ms)
[00:14:09.772,918] <dbg> modem: modem_power_off: AT+CFUN=0 done (37793 ms)
[00:15:29.533,721] <dbg> modem: modem_power_off: AT+CFUN=0 done (  651 ms)
[00:17:45.127,807] <dbg> modem: modem_power_off: AT+CFUN=0 done (33883 ms)
[00:18:04.649,200] <dbg> modem: modem_power_off: AT+CFUN=0 done (  681 ms)
[00:18:32.629,821] <dbg> modem: modem_power_off: AT+CFUN=0 done (  745 ms)
----
[00:22:01.609,619] <dbg> modem: modem_power_off: AT+CFUN=0 done ( 3701 ms)
[00:23:00.044,921] <dbg> modem: modem_power_off: AT+CFUN=0 done (  747 ms)
[00:24:01.036,315] <dbg> modem: modem_power_off: AT+CFUN=0 done ( 1497 ms)
[00:25:39.506,195] <dbg> modem: modem_power_off: AT+CFUN=0 done (40664 ms)
[00:26:47.982,025] <dbg> modem: modem_power_off: AT+CFUN=0 done (41370 ms)
[00:27:14.052,673] <dbg> modem: modem_power_off: AT+CFUN=0 done (  733 ms)

You can see that sometimes it takes more than 30 seconds to finish.

Is this normal behavior?

PS. I am using NCS 2.3.0 with Modem FW 1.3.3

[Tim Chao]

After further testing it seems to happen only on NBIoT.

When using LTE-M, the execution times are always in 1500~3500 ms.

[03:20:39.264,190] <dbg> modem: modem_power_off: AT+CFUN=0 done ( 1560 ms)
[03:22:39.510,986] <dbg> modem: modem_power_off: AT+CFUN=0 done ( 1891 ms)
[03:24:41.365,783] <dbg> modem: modem_power_off: AT+CFUN=0 done ( 3195 ms)
[03:26:47.712,646] <dbg> modem: modem_power_off: AT+CFUN=0 done ( 3499 ms)
[03:28:39.362,091] <dbg> modem: modem_power_off: AT+CFUN=0 done ( 1588 ms)
[03:30:39.524,414] <dbg> modem: modem_power_off: AT+CFUN=0 done ( 1807 ms)

I'm wondering, whether the modem shutdown time will be affected by the network provider?

[Achim Kraus]

Are you common with PSM, page 17? Maybe that works better than CFUN=0/CFUN=1.

I guess, to speed up an answer from Nordic about your question of that delay, you may try to provide some modem traces for cases, where the switching off takes longer.

[Tim Chao]

Thanks for your suggestion.

The PSM/eDRX did supported in my application.

But seems the feature is not so reliable (the eDRX communication reported success but did not actually work in my testing). I still need to support modem power on/off for power saving.

[Achim Kraus]

And you're sure, that switching the modem on/off every two minutes (at least your log shows that), works reliable?

AFAIK some operators may limit that.

[Tim Chao]

Thanks, you help me to clear another question.

I did notice that short power on/off interval may cause the modem stay in SEARCHING state for a long time (>10 mins) sometime. I think it may be a limitation, but not sure is limited modem or operator. I will not allow such short interval in final product.

The 1~2 minutes in previous log is just for getting more logs of this power-off time test. Increase the interval did not change result.

[Achim Kraus]

In my experience PSM works with NB-IoT in many cases. Also RAI (either CP- or AS-RAI) works pretty well, maybe not perfect, but well.

For LTE-M it isn't that easy. First PSM without RAI is only "half the story" and for LTE-M RAI comes with Rel 14 AS-RAI. Second sometimes, in old infrastructure, you may get connected to LTE (not LTE-M) and then PSM is missing.

Anyway, I go for PSM and in the left cases, where PSM isn't available, a limited off/on approach as fallback.

My experience with eDRX support isn't that good, therefore I postponed to use it. (In my use-case the calculation doubles energy consumption, so it hasn't that prio.)