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

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

[Didrik Rokhaug]

Hi,

Are you using LTE-M or NB-IoT, and how are the signal conditions?

Detaching from the network involves some communication with the network, so it could be that there are some problems communicating with the network.

Also, how often do you attach and detach to the network? Most network don't like devices doing that too often, so it could be that the frequency of the tests themselves are causing a problem.

But, as Achim Kraus said, a modem trace would be very helpful in finding the cause of the delay.

Best regards,

Didrik

[Tim Chao]

Thanks for reply.

I don't have the signal strength value right now, around -10X dBm think. But normally the connect and publish (MQTT or HTTP) task can be done without error.

In my current test result, increase the attach & detach interval did not change the result. But short interval may cause the modem stay in SEARCHING state for a long time. I will avoid it in final product.

Cause I am develop on our customized board w/o uart1, I cannot get modem trace right now. I will try to make a test sample on DK next week to get the trace. 

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