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]

Thanks.

Nothing in the traces stands out to me immediately, so I've asked our modem team to have a look at the traces as well.

I'll get back to you when I have more to share.

[papatel]

Thank you Didrik.  Please make this a priority as this is gating production of a high volume wearable product.

SIM shutoff is a deal breaker for many battery powered applications and I hope it is already high priority for the Nordic firmware team to track extensively and check in regression testing.  Without this feature, e-DRX feature is often negated altogether.  Most MVNO and carrier provided SIMs support this feature now (at least from our investigations) so we consider it a core feature.

Some perhaps useful information:

• SIM shutoff is working as expected with the ALT1250 chipset on the same network/SIM/configuration.
• We also couldn't get SIM shutoff with this network/sim on the 9160 working either.  Although, the floor current was good after accounting for the SIM consumption (~4uA as documented).

Thank you!

-Patrick

[Didrik Rokhaug]

According to the modem team, "it looks like the SIM card indicates support for suspend in EF-UMPC, but it does not really support the SUSPEND UICC command APDU".

Which application are you using?

If your application uses GPIO pin interrupts, could you test the current consumption of an application that doesn't, such as the udp sample?

The upd sample can be configured to use eDRX by setting CONFIG_UDP_EDRX_ENABLE to 'y' in the prj.conf. You might also have to change which eDRX parameters are requested with CONFIG_LTE_EDRX_REQ_VALUE_NBIOT (the default is "1001") and CONFIG_LTE_PTW_VALUE_NBIOT.

Also, you might want to request a longer eDRX period. With %XDATAPRFL=0, the modem will try to suspend the SIM card if it goes to sleep for longer than 1 minute. However, the trace showed that despite the eDRX interval being 81.96s, the actual sleep interval wasn't always long enough.

[mnjLC]

Didrik Rokhaug said:

"it looks like the SIM card indicates support for suspend in EF-UMPC, but it does not really support the SUSPEND UICC command APDU".

We tried the same sim on an ALT 1250 implemetion and the SIM does shut itself off during the e-DRX cycle. We believe that the SIM is capable of shutoff.

Didrik Rokhaug said:

Which application are you using?

We are using serial LTE modem application avaible from the SDK. We are using it without any modifications.

Didrik Rokhaug said:

Also, you might want to request a longer eDRX period. With %XDATAPRFL=0, the modem will try to suspend the SIM card if it goes to sleep for longer than 1 minute.

I also tried the longer e-drx cycle as as mentioned below

 +CEDRXP: 5,"1001","1001","0000"

We are getting average current of 153 uA

I am attaching the ppk trace for the same with this replyppk-20240217T135838_EDRX_1001_PTW_0000.ppk

Please let me know what else I should try

Thanks!

[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