Nrf9160 not setting requested active time

Good day I am wondering if you can help me.

For background information.

Network - NB-iot

Firmware -  1.3.1

Software - Serial LTE Modem

Hardware - nrf9160dk

I am trying to set the requested active time down so that when I go into idle to save power and keep my IP connection that the modem doesn't stay active for 60 seconds there after.

The device is going into low power mode but only after 60 seconds. 

I will attach a screen shot of the AT-commands that I take to get to the point where I'd like to go into low power but the Requested Active Time does not change.

I came across this following link while attempting to get my power consumption down.

(+) turn off active time and go directly to power save mode - Nordic Q&A - Nordic DevZone - Nordic DevZone (nordicsemi.com)

I tried the command AT+CPSMS=1,"","","10101010","00000000" to set the periodic TAU to 10 minutes and the requested active time to 0 and to 2 (00000001) seconds.

But they had no influence on the 60 seconds of high power consumption after issuing the AT#XSLEEP=2 to put the system into idle.

If anyone has any input as to where I am going wrong I will greatly appreciate it.

Parents
  • Hello Pieter,

    PieterK said:
    Here is my terminal log and my trace file

    thanks a lot! Now that looks a lot better :-)

    PieterK said:
    Now we just need to sort out this issue of the modem not entering idle then we have a very low power solution

    Here is my analysis. Please note that the timestamps do not completely match your application log:

    • At 12:55:11.80, the modem reports that the connection to the network is established.

    12:55:11.808127 M4 TRACE_GROUP_UNASSIGNED L23_AT_STRING AT_STRING <= +CEREG: 1,"5209","09A53917",9,,,"00000000","10010100"\r\n

    • This as a consequence of completed network attach request at 12:55:11.68:

    • At 12:56:12.15, the modem reports that it has entered PSM:

    12:56:12.153189 M4 TRACE_GROUP_UNASSIGNED L23_AT_STRING AT_STRING <= %CESQ: 255,0,255,0\r\n
    12:56:12.154562 M4 TRACE_GROUP_UNASSIGNED L23_AT_STRING AT_STRING <= %XMODEMSLEEP: 1,599999\r\n

    • This as a result of that the network has released RRC at 12:56:12.03:



    Hence, the modem enters PSM immediately after it has been released from the network. There is no <Active Time> here in between. The 60s delay comes from the network not releasing RRC earlier. You should be able to confirm that by requesting a different <Active Time>. The modem should then enter PSM after <Active Time> + 60s offset. I do not have that much experience with NB-IoT networks, since they are not available here. But this behaviour might plausibly be common.

    Regards,

    Markus

Reply
  • Hello Pieter,

    PieterK said:
    Here is my terminal log and my trace file

    thanks a lot! Now that looks a lot better :-)

    PieterK said:
    Now we just need to sort out this issue of the modem not entering idle then we have a very low power solution

    Here is my analysis. Please note that the timestamps do not completely match your application log:

    • At 12:55:11.80, the modem reports that the connection to the network is established.

    12:55:11.808127 M4 TRACE_GROUP_UNASSIGNED L23_AT_STRING AT_STRING <= +CEREG: 1,"5209","09A53917",9,,,"00000000","10010100"\r\n

    • This as a consequence of completed network attach request at 12:55:11.68:

    • At 12:56:12.15, the modem reports that it has entered PSM:

    12:56:12.153189 M4 TRACE_GROUP_UNASSIGNED L23_AT_STRING AT_STRING <= %CESQ: 255,0,255,0\r\n
    12:56:12.154562 M4 TRACE_GROUP_UNASSIGNED L23_AT_STRING AT_STRING <= %XMODEMSLEEP: 1,599999\r\n

    • This as a result of that the network has released RRC at 12:56:12.03:



    Hence, the modem enters PSM immediately after it has been released from the network. There is no <Active Time> here in between. The 60s delay comes from the network not releasing RRC earlier. You should be able to confirm that by requesting a different <Active Time>. The modem should then enter PSM after <Active Time> + 60s offset. I do not have that much experience with NB-IoT networks, since they are not available here. But this behaviour might plausibly be common.

    Regards,

    Markus

Children
No Data
Related