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

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

Hi Didrik,

Modem trace attached.

Tested with NRF9160DK with modem_shell, the latest modem power off take >32s.

trace-2023-04-26T02-13-34.608Z.bin

[Didrik Rokhaug]

Thanks.

In the case where the detach takes a long time, it seems like the modem is using that time to search for a cell. However, I don't know why it does that, so I've asked the modem team to have a look at it.

I'll let you know when they have reached a conclusion.

[Didrik Rokhaug]

According to the modem team, "SI reception from first found cell fails and due to that cell selection takes time."

Before the modem can turn off, it has to send a detach message to the network. In NB-IoT, this process has a max timeout of 85 seconds (i.e. the modem will at most stay active for 85 seconds).

[Tim Chao]

Got it, thanks.

So it cause by the NBIoT signal is not stable in my test env.