The AT+CFUN=0 take long time sometimes

RE: The AT+CFUN=0 take long time sometimes

Tim Chao — Thu, 04 May 2023 03:31:05 GMT

Got it, thanks.

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

RE: The AT+CFUN=0 take long time sometimes

Didrik Rokhaug — Wed, 03 May 2023 12:54:17 GMT

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

RE: The AT+CFUN=0 take long time sometimes

Didrik Rokhaug — Wed, 26 Apr 2023 15:07:33 GMT

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.

RE: The AT+CFUN=0 take long time sometimes

Tim Chao — Wed, 26 Apr 2023 02:26:25 GMT

Hi Didrik,

Modem trace attached.

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

devzone.nordicsemi.com/.../trace_2D00_2023_2D00_04_2D00_26T02_2D00_13_2D00_34.608Z.bin

RE: The AT+CFUN=0 take long time sometimes

Tim Chao — Tue, 25 Apr 2023 05:26:12 GMT

You are right. 🙂

I feel worried because that ticket.

It's lucky that I meet the issue when developing. That will be a nightmare if the issue happen on other country after product launch. And it is not possible to ask end user to provide modem trace for us.

RE: The AT+CFUN=0 take long time sometimes

Achim Kraus — Mon, 24 Apr 2023 14:59:51 GMT

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

RE: The AT+CFUN=0 take long time sometimes

Didrik Rokhaug — Mon, 24 Apr 2023 13:19:10 GMT

[quote user="Tim Chao"]

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.

[/quote]

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.

RE: The AT+CFUN=0 take long time sometimes

Tim Chao — Sat, 22 Apr 2023 02:07:09 GMT

Many thanks.

I really learn a lot from your sharing.

RE: The AT+CFUN=0 take long time sometimes

Achim Kraus — Fri, 21 Apr 2023 12:27:45 GMT

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.

RE: The AT+CFUN=0 take long time sometimes

Tim Chao — Fri, 21 Apr 2023 12:17:53 GMT

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.

RE: The AT+CFUN=0 take long time sometimes

Tim Chao — Fri, 21 Apr 2023 11:54:19 GMT

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.

RE: The AT+CFUN=0 take long time sometimes

Didrik Rokhaug — Fri, 21 Apr 2023 11:34:53 GMT

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

RE: The AT+CFUN=0 take long time sometimes

Achim Kraus — Fri, 21 Apr 2023 11:28:04 GMT

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

RE: The AT+CFUN=0 take long time sometimes

Tim Chao — Fri, 21 Apr 2023 11:02:22 GMT

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.

RE: The AT+CFUN=0 take long time sometimes

Achim Kraus — Fri, 21 Apr 2023 09:35:34 GMT

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.

RE: The AT+CFUN=0 take long time sometimes

Tim Chao — Fri, 21 Apr 2023 07:48:09 GMT

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.

RE: The AT+CFUN=0 take long time sometimes

Achim Kraus — Fri, 21 Apr 2023 07:28:17 GMT

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.

RE: The AT+CFUN=0 take long time sometimes

Tim Chao — Fri, 21 Apr 2023 05:37:20 GMT

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?