nRF9160 real network power profile

[Willem21]

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

[Øyvind]

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?

[Øyvind]

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

[Øyvind]

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

[Willem21]

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?

[Didrik Rokhaug]

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