nRF9160 real network power profile

I trying to match the nrf9160DK current consumption measured with the "power Profiler kit II" with the "online power profiler".

I watched the nordic youtube video "How to power profile your cellular IoT application".

In the video a total average current of 83uA is archived for the UDP example.

When I execute the same UDP example on the nrf9160DK I get a total average current of 579uA. See picture with the red circle.

Maybe the difference is due the part within the red circle which is much longer than the "cDRX inactivity timer" from the video.

What is the name of the part within the red circle and how can I enter this part in the "online power profiler"?

 

nRF9160DK PCA10090 1.1.0

Modem firmware: mfw_nrf9160_1.3.4.zip

Measured PSM floor current: 3.73uA

NRF Connect SDK V2.2.0

Parents
  • Hello, 

    Are you able to provide any log output from the device during the measurements, along with a modem trace? This will tell us what is going on in the background. What SIM card are you using? What is you location?

    Note that there are several settings that differ from network to network, e.g. is the roaming SIM allowed on the network. 

    Thanks!

    Kind regards, 
    Øyvind

  • Hello, 

    Below you can find the log output and modem trace file.

    I'm using the IBASIS eSIM (I get simular results with a simpoint SIM)

    My location: The Netherlands, Drenthe, Emmen, 7812VA

    [2023-02-16 13:45:35.841] I: Trace thread ready
    [2023-02-16 13:45:35.851] I: Trace level override: 2
    [2023-02-16 13:45:35.853] *** Booting Zephyr OS build v3.2.99-ncs1 ***
    [2023-02-16 13:45:35.857] UDP sample has started
    [2023-02-16 13:45:37.216] LTE cell changed: Cell ID: 4152588, Tracking area: 33201
    [2023-02-16 13:45:37.298] RRC mode: Connected
    [2023-02-16 13:45:37.884] Network registration status: Connected - home network
    [2023-02-16 13:45:37.890] PSM parameter update: TAU: 3600, Active time: 0
    [2023-02-16 13:45:37.895] Transmitting UDP/IP payload of 38 bytes to the IP address 8.8.8.8, port number 2469
    [2023-02-16 13:45:48.572] RRC mode: Idle
    [2023-02-16 13:45:48.574] 
    
    trace-2023-02-16T12-45-32.766Z.bin

    Kind regards, 

    Willem

  • I've tried with three different SIM cards to have a comparison. Was your modem trace done with an iBasis SIM?

  • Also, could you please try to do a full erase of your board and then a factory reset of the modem?

    Thanks

  • I believe I did use the Ibasis SIM in the previous uploads.

    I've done the following:
    -I did a full erase of the nRF52 and programmed "nrf9160_dk_board_controller_fw_2.0.1.hex"
    -I did a full erase of the nRF91 and programmed "mfw_nrf9160_1.3.4.zip" and "nrf9160dk_at_client_2022-12-08_188a1603.hex"
    -I connected the "LTE Link Monitor" and send the factory reset command AT%XFACTORYRESET=1 which responded with an "OK"
    -Made sure that the iBasis SIM was installed
    -Flashed the UDP example with Visual Studio Code
    -Run the power profiler and trace collector again, below you find the results
    Result: The long part within the red circle still exist

    trace-2023-02-21T16-32-49.016Z.bin

  • Today I tried a "telenor" SIM.
    With this simcard the udp sample behaviour is as expected, see screenshot below.

    With the "telenor" SIM the serial log shows "Network registration status: Connected - roaming".
    With the "iBasis" SIM the log shows "Network registration status: Connected - home network".

    But the question still remains: What is happening with the iBasis" SIM within the red circle in previous reply?

  • Øyvind,

    Unfortunately the Telenor SIM doesn't always use cDRX intervals within the red circle.
    When it does use cDRX intervals it keeps using it and when it doesn't it keeps not using it.
    Below you find the modem trace and wireshark capture.

    1. How can I find out what is happening within the red circle?
    2. How can I detect it and force the modem back to using cDRX intervals?

    Thanks for you reply in advance.

    With best regards,

    Willem

    trace-2023-03-02T10-20-20.139Z.bin

    trace-2023-03-02T10-20-20.139Z.pcapng

Reply Children
  • Willem, sorry for the late reply. I was out of office due to Mobile World last week. 

    The initial answer is that this is an issue with the network provider. I will have a look at the last trace. Does any of your traces use Telenor? 

    Where is the kit located? I.e. inside a normal house, a concrete building, a cellar? Just trying to figure out why this is happening. Have you tried to test this at other locations? How far are you from the nearest cell tower?

    Could you run the AT Client and provide the log output when running in LTE Link Monitor?

  • Here is the XMONITOR response from your device. The RSRP is mid ranged, which could be possible answer to this.

    %XMONITOR:

    <reg_status>

    <full_name>

    <short_name>

    <plmn>

    <tac>

    <AcT>

    <band>

    <cell_id>

    <phys_cell_id>

    <EARFCN>

    <rsrp>

    <snr>

    <NW-provided
    _eDRX_value>

    <Active-Time>

    <Periodic
    -TAU-ext>

    <Periodic-TAU>

    %XMONITOR

    5

    " "

    " "

    20408

    81B1

    7

    20

    "003F5D0C"

    425

    6400

    45

    29

    " "

    "00000000"

    "00100001"

    "01001001"

    Registered,
    roaming

    -95 dBm

    5 dBm

    0

    1 hour

    90 hours

     
  • Hi Øyvind,

    Thanks for the response.
    My last trace is with the Telenor SIM.
    The kit is located in a brick building at the second floor.
    I didn't try other locations and I don't know how far I'm from the nearest cell tower.
    I didn't try the AT Client because I found the cause:


    After adding the "AT+COPS?" command to the UDP example I found out that it was due the operator.
    My Telenor SIM is a roaming SIM and it sometimes switches between the operators.
    When it connects to "T Mobile Netherlands" I get cDRX.
    When it connects to "KPN" I don't get cDRX.
    After contacting Telenor I found out "KPN" doesn't support cDRX.

    My goal is to archive very low power consumption, so I think I need cDRX.
    Is there a firmware command to find out if the connected operator supports cDRX?
    Is it possible to automaticaly select an roaming operator which supports cDRX when available?
    Or can this be added in the firmware?

  • Hi, Øyvind is out of office, so I have taken over this ticket.

    Willem21 said:
    Is there a firmware command to find out if the connected operator supports cDRX?
    Is it possible to automaticaly select an roaming operator which supports cDRX when available?

    Unfortunately, I don't think that is possible.

    After connecting to a network, you could try to use %CONEVAL to get an estimate of how much power it will take to send something. However, I am not sure if it takes into account the cDRX (I belive it will, though I couldn't see it listed as a parameter in the response).

    Willem21 said:
    My goal is to archive very low power consumption, so I think I need cDRX.

    You could also try to use Release Assistance Indication, to not stay in RRC Connected longer than you have to.

    This will let the device tell the network that it is done sending, and whether or not it is expecting to receive any data. This will then let the network release the device faster, if the network supports it.

    It is a release 14 feature, and not all networks supports it yet.

    Unfortunately, we don't have any good samples that show how to use RAI yet (the UDP sample supports only supports a different variant of RAI, which is only supported on NB-IoT). However, a colleague of mine has made a modified version of the UDP sample that you can look at: https://github.com/charlieshao5189/udp_sample_with_buttons_control

    Another thing you should keep in mind when using RAI is that it doesn't work very well with TCP. This is because you don't know when you will have to send or receive retransmissions, and therefore cannot know when you will send or receive the last packet.

    Best regards,

    Didrik

Related