Cellular UDP on nRF9151 DK does not enter PSM

[_rd]

Hello,

I am trying to measure nRF9151 current using Power Profiler Kit II, running Cellular UDP project on EVK and following the steps in:

https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/samples/cellular/udp/README.html

Added the following lines to prj.conf:

CONFIG_SERIAL=n

CONFIG_TFM_LOG_LEVEL_SILENCE=n

CONFIG_UDP_DATA_UPLOAD_FREQUENCY_SECONDS=30

It seems the modem doesn't enter PSM mode in the image below:

Thanks in advance for your comments and insight to help resolve this issue.

Roya

[Elfving]

I see you've also gotten a great reply by Achim here, have a look at that.

Monkeytronics said:

1) Is the approach the OP uses by setting the LTE paramaters in prj.conf the correct way to set up the paramaters? Or are there any differences / pros / cons in configuring things directly in code like this?

That looks correct. You can do this.

Monkeytronics said:

2) Interesting comment regarding cell provider: assuming we are 99% confident that we have configured things as intended, are there any ways in which we can check what has been implemented (with the modem library - not AT commands)?

Have a look at the modem library and devacademy for more on this.

Monkeytronics said:

I do not know this industry. Is it common for network providers to either not support or disable certain features or, worse still, only provide them at their discretion?

Yes, but I would say it's understandable in. Extremely short PSM values doesn't really make much sense for instance. 

Regards,

Elfving

[_rd]

Hi,

Thank you both for helpful comments.

- It makes sense to use PSM for longer sleep intervals, 30 s was just for testing.

- I will check it again with different network providers, if not generally supported may be turning off the modem for long intervals would be a solution.

- Interesting note about setting LTE parameters, I guess setting directly in the code is better in low level development and setting by AT commands for applications such as SLM?

Regards,

Roya

[Achim Kraus]

_rd said:

- It makes sense to use PSM for longer sleep intervals, 30 s was just for testing.

Let me recommend then, that you use something as 300s to see, if it then enters the psm sleep after a longer RRC active and idle period,

_rd said:

- I will check it again with different network providers, if not generally supported may be turning off the modem for long intervals would be a solution.

PSM is widely support, but as I already wrote Spark NZ has used different base stations (1.5 years) ago, and it toke some month to have them fixed the old/broken ones in the test area. So, if you test, you will need to track the base-station and see, if the result depends on that. Hope this is now generally fixed, but you will see.
If "switching on/off" helps is something you will also need to discuss with Spark NZ, some operators will block too frequently network registrations. But with 1h I guess you will be save.

[Achim Kraus]

_rd said:

Interesting note about setting LTE parameters, I guess setting directly in the code is better in low level development and setting by AT commands for applications such as SLM?

Isn't the point more, that you need to know, what happens in your device-cloud communication?

Very first question: TCP/TLS for MQTT? Then you may get disappointed. UDP/DTLS 1.2 CID/CoAP, then you may construct your message exchange and setup the parameters accordingly. E.g. if the device sends the most messages as coap-oneway (no-server-response-option), then RAI last message is your friend. If you want then once a day a response, then "CP-RAI one-response" or "AS-RAI no data" works.
Did you need to retransmit such a request with response, because the response wasn't received in time? Then be careful that usually also means, that you not longer control the possible messages. Luckily that's pretty rare. So in that case you may stop using RAI and see, if the response is received twice.

So, I don't think, that there are general parameters, especially for RAI. So, first check, how you want to exchange messages. Then you may optimize the parameters.