High eDRX current consumption on NRF9161_DK and disable the UICC interface during eDRX not working

[mnjLC]

Hello all,

We are taking our power measurements on NRF9161 DK board PCA10153 0.9.1. We are using NB-IoT for the LPWAN conection  We are supplying power to the board using the source meter mode on the NRFPPK2. To confirm that sim shut off is possible on our sim, we captured the AT+CRSM command output as below. 

> AT+CRSM=176,28589,0,0,0

+CRSM: 144,0,"01000803"

OK

According to this post, our sim is capable of sim shutodown. But still our sim is consuming 62uA of current during the eDRX cycles. Below is the screen shot of the sim current measurement of ~62uA.

Next, we tried taking current measurement for the e-DRX cycle. Cycle of 81.92s and PTW of 5.12s.

> AT%XDATAPRFL?

%XDATAPRFL: 0
> at+cedrxs=2,5,"0101"

OK
> at+cfun=1

OK

+CEDRXP: 5,"0101","0101","0011"
> at%xptw=5,"0001"

OK

+CEDRXP: 5,"0101","0101","0001"
> at#xsleep=2

OK

We see that the NRF9161 is consuming high current as compatred to NRF9160. Below is the screenshot of measured current consumption

Average measured current over a period of 10 minutes is 208uA seen in the image above.

With all the above information, we would like to report two bugs

1. Sim is not turning off during the e-DRX cycle

2. Floor current too high assuming sim is off during the edrx cycle. Currently with sim in ON state the floor current is 81uA
   
   

I am attaching the modem trace logs on this thread. Can someone from nordic look into this issue?

trace-2024-02-09T05-59-48.207Z.mtrace

[Didrik Rokhaug]

Hi,

I have started to look into this, but need some more time to do some tests on my side as well.

Could you also share the PPK traces as well?

Best regards,

Didrik

[mnjLC]

Hello Didrik Rokhaug
Attached are the requsted traces and corresponding PPK2 output
Thanks!
ppk-20240212T053013-sourcemode.ppktrace-2024-02-12T05-20-12.975Z-sourcemode.mtrace

[Didrik Rokhaug]

Did you try the udp sample?

[papatel]

Hello Didrik,

Yes, we can try the UDP example but can you please give us some commentary as to why? The AT command firmware should be more flexible and provide all necessary trace information and configuration as it is part of a release package that Nordic expects customers to consume as is.  Are we misunderstanding?

I'm totally happy to spend a day with my engineer testing with the another example application but we will not be happy if it doesn't provide you or the modem team with more information than the AT Command firmware trace and power data we provided.  We don't open tickets at the first sign of trouble; we've been at this issue for several weeks.  We are confident this is either a bug with Nordic's release package or incorrect/incomplete documentation.  But, we are Happy to be wrong on this point as long as we resolve the problem.

Here is the reality, the SIM is on JIO's network in India.  We've confirmed that there are at least 2 other nb-iot implementations properly executing on SIM shutoff for this exact configuration.  We've involved Jio's network engineers and they assure us the SIM and network have enabled the appropriate features and point to these real world working examples. 

Whether the SIM is adhering to specification/commands/protocols correctly or not, I need Nordic teams to help us track this issue down and resolve it!  Jio is the second? largest NB-IoT network on the planet covering over a billion people.

Happy to take a call on the subject or facilitate a live debug session, but we need to see real progress in the next 48 hours.

-Patrick.

[Didrik Rokhaug]

papatel said:

Yes, we can try the UDP example but can you please give us some commentary as to why?

The UDP sample probably won't help with the SIM card current draw, but it might help with the floor current of the nRF9161 itself.

While doing some (unrelated) current meassurements, I've noticed that there is some difference in how the GPIO pins affect current consumption on the nRF9160 DK vs the nRF9161 DK. However, I haven't quite gotten to the bottom of the difference yet, which is why I don't have many details yet. As the UDP sample doesn't use the GPIO pins at all, it should not be affected by this difference, so it would be a way to check if the elevated floor current is caused by the GPIO pins or not.

As for the SIM card, I got some more information from the modem team: To reduce the current consumption of a SIM card, it can either be suspended (if supported) or shut down. In your case, the SIM card indicates that is supports suspension, but when the modem tries to suspend it, nothing happens. According to the spec, if the SIM card supports suspension, that is what should be used. However, there is some room for interpretation, so it might be that other manufacturers use shutdown regardless.

We also have an AT command on the nRF9161, which controls which SIM card deactivation features will be used. Can you try to send "AT+SSRDA=0,1,0"?

This will tell the modem to not try to suspend the SIM card, just to shut it down.

[papatel]

Thank you, this is extremely helpful Didrik regarding SIM suspend.  We will investigate further regarding how the other implementations are behaving.  This seems like a reasonable assumption that other manufacturers are forcing shutdown and not attempting the suspend command.

My engineer confirmed that the AT+SSRDA=0,1,0 command does shutoff the sim between eDRX cycles and the current consumption drops as expected.

We did end up trying the UDP example, we get exactly the current consumption we expect with sim suspend not executing (as we know doesn't work).

So we assumed GPIO problem on DK just as you did.  We set all GPIOs to HIGH/LOW values with no effect on current consumption.

As a last ditch, we just compiled the latest SLM example from source, programmed, and boom, the mystery ~50uA of consumption is gone!

So the bug is, whatever SLM firmware is being programmed from the wizard below is introducing ~50uA more of floor current as compared to documentation and the SLM compiled from the nrfConnect SDK.

Your team should probably remedy this immediately.

Thank you!

-Patrick

[Didrik Rokhaug]

papatel said:

My engineer confirmed that the AT+SSRDA=0,1,0 command does shutoff the sim between eDRX cycles and the current consumption drops as expected.

I'm glad to hear that it worked.

papatel said:

As a last ditch, we just compiled the latest SLM example from source, programmed, and boom, the mystery ~50uA of consumption is gone!

Thanks, this is very useful information!

I looked a bit into the image in the Quick Start, and it has modem tracing enabled. This is what causes the extra current consumption.

I'll discuss with the team if we can make this clearer.

[papatel]

Awesome! Thank you for the excellent support.  I didn't mean to get too saucy on this thread, but we were in a time crunch that you helped us get out of.  So thank you again Didrik!

Just a simple note in the quick start about the increased current consumption due to modem tracing would be sufficient.  This would have saved us a few days of panic.  A better option would be to give the user the choice between modem trace enabled or disabled with a quick note explaining the difference.

In our actual production we want to order our nrf91x1 with the SLM release firmware pre-programmed for security and simplicity.  This is why we were worried why the SLM firmware provided was consuming more current than expected.