nRF9160-DK - sometimes busy for 1 minute before entering PSM

RE: nRF9160-DK - sometimes busy for 1 minute before entering PSM

Michael Meyer — Wed, 28 Sep 2022 13:39:48 GMT

I can confirm that the manual network selection with AT+COPS prevents the HPPLMN search and therefore the additional power consumption.
Same test scenario as above, but with manual network selection:

No additional power consumption after every 2 hours any more.
Thanks for clarification!

RE: nRF9160-DK - sometimes busy for 1 minute before entering PSM

Michael Meyer — Mon, 26 Sep 2022 12:36:27 GMT

Many thanks for the additional hint!
And sorry for the late reply, I was out of office the last two weeks...

I will check if the manual PLMN selection will change the behaviour. If yes, may be it is possible to build a kind of workaround on the application level.

RE: nRF9160-DK - sometimes busy for 1 minute before entering PSM

Achim Kraus — Tue, 13 Sep 2022 09:08:05 GMT

I got an answer in an other issue, see Search indication.

If it's possible, you may chose to select the PLMN manually with AT+COPS, which prevent from HPPLMN searches.

RE: nRF9160-DK - sometimes busy for 1 minute before entering PSM

Achim Kraus — Sat, 10 Sep 2022 08:19:48 GMT

Is there a relation of %PERIODICSEARCHCONF to such HPPLMN search?

RE: nRF9160-DK - sometimes busy for 1 minute before entering PSM

Michael Meyer — Tue, 30 Aug 2022 09:19:56 GMT

Hi,

I found the same pattern for LTE-M:

The current of the "high consumption slots" is lower (about 1 minute instead of 2,5 minutes with NB-IOT), the duration is shorter, too (30mA instead of 50mA). The timing is identical.

Regards
Michael

RE: nRF9160-DK - sometimes busy for 1 minute before entering PSM

Michael Meyer — Tue, 30 Aug 2022 06:05:31 GMT

Hi,

I am experiencing a very similar behaviour:

Sending short UDP packages every 15 minutes. NB-IOT as access technology.
The modem recognizes the roaming situation (correctly).

After every 2 hours there are the same longer periods (about 2 minutes!) of a 50 mA consumption.
Modem 1.3.2., NCS 2.0.0, nrf connect for desktop 3.11.1.

I checked the USIMs in use:

The EF_HPPLMN (ID '6F31' in ADF USIM) contains 0x01. This corresponds to the two hours "high consumption slots".
I am currently checking with the operator on the USIM configuration, but this is ongoing.
The EF_HPPLMN defines the HPPLMN search period (in priciple). But there are several exceptions for the modem to be considered (defined in 3GPP TS 23.122. Too complicated for me ;-)).

So I have the same question as Armin:
Is it possible to influence the HPPLMN search time by the application side (e.g. using AT-commands) to avoid the additional power consumption due to HHPLMN search?

Regards,
Michael

RE: nRF9160-DK - sometimes busy for 1 minute before entering PSM

Achim Kraus — Mon, 15 Aug 2022 16:56:10 GMT

Thanks for analyzing the log.

Is that HPPLMN search timer configurable? Or which time is used for that?

RE: nRF9160-DK - sometimes busy for 1 minute before entering PSM

Hakon — Mon, 15 Aug 2022 11:51:08 GMT

I had the modem team look at the modem log. Here's the response;

The log shows that there is Higher Priority PLMN (HPPLMN) search initiated after one of the RRC connection releases and that caused the delay. The search has been specified by 3GPP and must be done while not in home network. The search is controlled by a timer and if the timer expires while in PSM, then the HPPLMN search must be done when waking up from PSM. But in this log the timer expired already before entering PSM which is why the search was initiated and completed before entering PSM.

RE: nRF9160-DK - sometimes busy for 1 minute before entering PSM

Achim Kraus — Sat, 13 Aug 2022 18:42:22 GMT

Maybe I miss something.

I added already such a trace in my comment 19 day ago (25. July 2022). I assumed that trace of the "additional 60s to sleep" are handed over to an expert to analyze it.

What is the result of that analysis by an expert?

A retransmission? I can't see that in this trace. A larger "inactivity time", I also can't see that.

The trace contains 3 message exchanges, where the device entered the sleep mode in time, and a forth (the last one in that trace), where it seems to miss the sleep mode. The last shows also, that it released the connection after 10s, so also the hint with the "inactivity timer" is strange to me, thought the trace shows the opposite. And the trace shows also no retransmission, which prevents the sleep mode.

Anyway, if it's not possible, that some experts have a look at the trace, that's OK for me. I'm only evaluating.

RE: nRF9160-DK - sometimes busy for 1 minute before entering PSM

JONATHAN LL — Fri, 12 Aug 2022 15:49:04 GMT

You can check the Wire Shark trace see what is going on. so if you use the nrf connect app wit the trace collector V2 you can see if any data or packets is sent, what is interesting is if there is re-transmits. With different networks the time will be different, so if the device i roaming then it is expected to change from time to time.

Regards,
Jonathan

RE: nRF9160-DK - sometimes busy for 1 minute before entering PSM

Achim Kraus — Fri, 05 Aug 2022 10:32:34 GMT

I will ask there. What irritates me is, that it occurs randomly. Therefore I wrote

> ... sometimes ...

in my first message.

Tests afterwards showed something as 2 of 3 times the sleepmode was entered within time, and once not. So one registration, one +CPSMS, and several request (PTAU 3600, Act. 8s). And after each request the modem enters the sleep mode again, but sometimes with delays.

If I look at Power Consumption Charts I see, that in the active time the consumption is larger than the 50mA (maybe I wrong at that, I will check it again, when I'm able to spend some more time into this issue.)

RE: nRF9160-DK - sometimes busy for 1 minute before entering PSM

JONATHAN LL — Fri, 05 Aug 2022 08:15:35 GMT

This could be the networks doing. Check with the network provider, aska about the inactivity timer, if the inactivity timer is on around 60 sec then that is the issue.

There is little we can do if the network has long timers as this is not something we can control.

Regards,
Jonathan

RE: nRF9160-DK - sometimes busy for 1 minute before entering PSM

Achim Kraus — Mon, 25 Jul 2022 09:30:53 GMT

devzone.nordicsemi.com/.../trace_2D00_2022_2D00_07_2D00_25T09_2D00_18_2D00_12.415Z.zip

The last message exchange results then in a 60s pause until sleep.

It's not too easy to have the Power Profile Kit also in place, but I hope the raw trace helps you to see the misery.

From the application log:

[00:01:40.092,803] <inf> COAP_CLIENT: 100 s, Thingy:91 v0.3, 0*3, 1*0, 2*0, 3*0, failures 0
[00:01:40.092,895] <inf> COAP_CLIENT: 5175 mV
[00:01:40.092,926] <inf> COAP_CLIENT: RSSI q,p: 255,255
[00:01:40.092,987] <inf> COAP_CLIENT: Network: CAT-M1
[00:01:40.093,078] <inf> COAP_CLIENT: PSM: 3600 s, Released: 11068 ms
[00:01:40.093,139] <inf> COAP_CLIENT: CoAP request prepared, token 0xeecbbfee, 148 bytes
[00:01:40.099,060] <inf> COAP_CLIENT: send_to_peer 184
[00:01:40.167,449] <inf> COAP_CLIENT: LTE modem wakes up
[00:01:40.723,602] <inf> COAP_CLIENT: RRC mode: Connected
[00:01:41.031,524] <inf> COAP_CLIENT: received_from_peer 167 bytes
[00:01:41.031,555] <inf> TINYDTLS: received message (167 bytes), starting with 'application_data', epoch 1

[00:01:41.031,616] <inf> TINYDTLS: got 'application_data' epoch 1 sequence 4 (167 bytes)

[00:01:41.032,379] <inf> TINYDTLS: ** application data:

[00:01:41.032,409] <inf> COAP_CLIENT: CoAP response received. code: 2.04, token 0xeecbbfee, 128 bytes
[00:01:41.032,409] <inf> COAP_CLIENT:   payload: 100 s, Thingy:91 v0.3, 0*3, 1*0, 2*0, 3*0, failures 0
5175 mV
RSSI q,p: 255,255
Network: CAT-M1
PSM: 3600 s, Released: 11068 ms
[00:01:41.032,531] <inf> COAP_CLIENT: 4/629ms/938ms: success
[00:01:41.032,531] <inf> COAP_CLIENT: retrans: 0*4, 1*0, 2*0, 3*0, failures 0
[00:01:41.032,562] <inf> COAP_CLIENT: rtt: 0-2s: 4, 2-4s: 0, 4-6s: 0, 6-8s: 0, 8-10s: 0
[00:01:41.032,562] <inf> COAP_CLIENT: rtt: 10-12s: 0, 12-14s: 0, 14-16s: 0, 16-18s: 0, 18-20: 0
[00:01:41.032,592] <inf> COAP_CLIENT: rtt: avg. 1s (4#)
[00:01:41.032,592] <inf> COAP_CLIENT: vbat: 5175, 5171, 5179, 5148, 0
[00:01:41.032,623] <inf> COAP_CLIENT:       0, 0, 0, 0, 0
[00:01:52.025,787] <inf> COAP_CLIENT: RRC mode: Idle after 11302 ms (10994 ms inactivity)
[00:02:00.015,563] <inf> COAP_CLIENT: LTE modem sleeps
[00:02:33.159,149] <inf> COAP_CLIENT: 153 s, Thingy:91 v0.3, 0*4, 1*0, 2*0, 3*0, failures 0
[00:02:33.159,240] <inf> COAP_CLIENT: 5175 mV
[00:02:33.159,301] <inf> COAP_CLIENT: RSSI q,p: 255,255
[00:02:33.159,362] <inf> COAP_CLIENT: Network: CAT-M1
[00:02:33.159,454] <inf> COAP_CLIENT: PSM: 3600 s, Released: 10994 ms
[00:02:33.159,515] <inf> COAP_CLIENT: CoAP request prepared, token 0xefcbbfee, 148 bytes
[00:02:33.165,405] <inf> COAP_CLIENT: send_to_peer 184
[00:02:33.236,511] <inf> COAP_CLIENT: LTE modem wakes up
[00:02:33.775,878] <inf> COAP_CLIENT: RRC mode: Connected
[00:02:34.136,352] <inf> COAP_CLIENT: received_from_peer 167 bytes
[00:02:34.136,383] <inf> TINYDTLS: received message (167 bytes), starting with 'application_data', epoch 1

[00:02:34.136,444] <inf> TINYDTLS: got 'application_data' epoch 1 sequence 5 (167 bytes)

[00:02:34.137,176] <inf> TINYDTLS: ** application data:

[00:02:34.137,207] <inf> COAP_CLIENT: CoAP response received. code: 2.04, token 0xefcbbfee, 128 bytes
[00:02:34.137,237] <inf> COAP_CLIENT:   payload: 153 s, Thingy:91 v0.3, 0*4, 1*0, 2*0, 3*0, failures 0
5175 mV
RSSI q,p: 255,255
Network: CAT-M1
PSM: 3600 s, Released: 10994 ms
[00:02:34.137,329] <inf> COAP_CLIENT: 5/615ms/977ms: success
[00:02:34.137,359] <inf> COAP_CLIENT: retrans: 0*5, 1*0, 2*0, 3*0, failures 0
[00:02:34.137,359] <inf> COAP_CLIENT: rtt: 0-2s: 5, 2-4s: 0, 4-6s: 0, 6-8s: 0, 8-10s: 0
[00:02:34.137,390] <inf> COAP_CLIENT: rtt: 10-12s: 0, 12-14s: 0, 14-16s: 0, 16-18s: 0, 18-20: 0
[00:02:34.137,390] <inf> COAP_CLIENT: rtt: avg. 1s (5#)
[00:02:34.137,420] <inf> COAP_CLIENT: vbat: 5175, 5175, 5171, 5179, 5148
[00:02:34.137,451] <inf> COAP_CLIENT:       0, 0, 0, 0, 0
[00:02:45.107,086] <inf> COAP_CLIENT: RRC mode: Idle after 11332 ms (10971 ms inactivity)
[00:03:41.611,358] <inf> COAP_CLIENT: LTE modem sleeps

Extract the "going to sleep":

[00:01:52.025,787] <inf> COAP_CLIENT: RRC mode: Idle after 11302 ms (10994 ms inactivity)
[00:02:00.015,563] <inf> COAP_CLIENT: LTE modem sleeps

(8 seconds,matchs active time, OK)

[00:02:45.107,086] <inf> COAP_CLIENT: RRC mode: Idle after 11332 ms (10971 ms inactivity)
[00:03:41.611,358] <inf> COAP_CLIENT: LTE modem sleeps

(60 seconds, drains the battery)

RE: nRF9160-DK - sometimes busy for 1 minute before entering PSM

Achim Kraus — Mon, 25 Jul 2022 08:43:46 GMT

I will try it and we will see.

But I don't think, a pending transfer is the reason. At least not one, my application does. Using CoAP/DTLS CID is one message sent, one received and then the device may sleep again. I also don't see additional logging , which indicates, that something else happens.

Also to mention: if a transmission is ongoing (see the begin of the power chart), the consumption is much higher than 50mA.

RE: nRF9160-DK - sometimes busy for 1 minute before entering PSM

JONATHAN LL — Mon, 25 Jul 2022 08:35:13 GMT

Hi,

If there is a data transfere ongoing then the device will no go in to PSM mode before it is done, even tough PSM is granted. So this can be the case, but we can not say for sure what is the reason without logs, so if you could provide a modem log then that would be great as we will then be able to see what is going on i more detail.

Regards,
Jonathan

RE: nRF9160-DK - sometimes busy for 1 minute before entering PSM

Achim Kraus — Sat, 23 Jul 2022 13:35:52 GMT

It occurred again, now for more than 2 minutes!

RE: nRF9160-DK - sometimes busy for 1 minute before entering PSM

Achim Kraus — Fri, 22 Jul 2022 12:16:21 GMT

modem 1.3.2

NCS 2.0.1

nrf connect for desktop 3.11.1, power profiler app 3.4.3

Just to mention:

My logs with PSM wakeup and sleep are matching the power consumption indicated by the PPK2. So, I guess, it's something happening in the modem, not an issue of the PPK2.

RE: nRF9160-DK - sometimes busy for 1 minute before entering PSM

JONATHAN LL — Fri, 22 Jul 2022 12:11:44 GMT

Hi,

What modem firmware are you using and what nRF Connect SDK (NCS) version are you on?

Regards,
Jonathan