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.)

[Tim Chao]

Thanks for your sharing.

May I ask how you check if PSM is available?

I am wondering if check the <Active-Time> and <TAU> value in +CEREG notification enough, or I need to monitor the "Enter sleep" event to make sure the PSM works.

[Achim Kraus]

I record the most events to ensure, what actually happens. That includes the events RRC Connected, RRC Idle and Sleeping events. I also add the times and relate these event times with the time of the last sent or received data.

Time "last data" to RRC Idle indicates the RRC Active Timer or effective RAI function.

Time "RRC Idle" to "Sleeping" indicates in a couple of cases extra HPPLMN searches (among other cases, so this is not really that clear).

In some other discussion I also requested more events, which reports the actual situation. Last week we tried to discus reporting about RAI . Unfortunately it seems the for Nordic the "best possible way" is to swallow requested functions and not to report the outcome. That is extremely time intensive on the user's side. Especially, if you consider that from time to time Nordic "breaks" the behavior. The same happens for events about HPPLMN searches, for Nordic this is not required, and for users this extra drains the battery.

[Tim Chao]

Many thanks.

I really learn a lot from your sharing.

[Didrik Rokhaug]

Tim Chao said:

May I ask how you check if PSM is available?

I am wondering if check the <Active-Time> and <TAU> value in +CEREG notification enough, or I need to monitor the "Enter sleep" event to make sure the PSM works.

If you have an Active-Time (i.e. it is not "1110000"), you have PSM, and you can see the sleep period in the TAU parameter.

[Achim Kraus]

> If you have an Active-Time (i.e. it is not "1110000"), you have PSM,

I guess, the doubts are based on the experience with eDRX and the Enable eDRX seems not work discussion.

Yes,in my experience the assigned Active-Time indicates, the PSM is available in the network. But if the device goes to sleep or not is then signaled by the event LTE_LC_EVT_MODEM_SLEEP_ENTER. Overall, it's in my opinion a good practice to check, whats actually happen. On "the desk" even with the PPK II. In "the wild" with the events.