This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

NRF9160DK high baseline current

Hello!

Here is a story I am sure you have heard before. I am evaluating the NRF9160DK and seeing what is the lowest power consumtpion we can get when sending data to a server once every 5 minutes. I used the udp exmaple in the 1.4.2 SDK as a base, and updated the modem to version 1.2.2.

Using the UDP example it was very easy to get the functionality I needed, however I am not happy with the power consumption.

I am using the Otii Arc (which was recommended to me by a colleague who also uses NRF dev kits), I have it set to output 3.3v into VIN on P20. USB is not connected to the board and SW6 is set to disconnect the IFMCU. When I power on the dev kit with the UDP example programmed I can see it start up, when it sends data, then when it presumably goes to sleep.

The sleep current is 2.73mA on average, which is way off from what I expected given this blog post

https://devzone.nordicsemi.com/nordic/cellular-iot-guides/b/hardware-design/posts/measuring-psm-idle-current-on-the-nrf91-dk

those odd power spikes that occur while it is sleeping aren't always present, but even if they are gone the baseline current when it is sleeping is still quite high at 1.73mA

Just to rule out any issue with LTE or PSM configuration I modified main() to immediately go to sleep

The result is that I still have a sleep current of about 1.7mA

So now I am wondering if I am not measuring current consumption accurately or if I am missing something to configure the board for low-power mode.

Parents
  • Hi, JNitz!

    Thanks for reaching out! Are you using NB-IoT or LTE-M? 

    From your pictures it seems like the device never enters PSM, and thus stays connected to the network which will consume more power. Are you sure that your SIM provider supports PSM?

    In order to get the nRF9160 to properly sleep without PSM the modem must be turned off or set to offline mode using AT-commands. If not the modem will still draw quite a lot of current.

    Best regards,
    Carl Richard

  • Hey Carl,

    For this example I am using LTE-M using the iBasis sim card that comes with the NRF9160 dev kit. When I used the LTE link monitor software in nrf connect and I used the AT+CFUN=1 command I could see that it was connecting to a T-mobile network (I am located in California if that helps). From what I could gather the T-mobile LTE-M compatible network should support PSM. 

    For the project settings the PSM settings are as follows:

    CONFIG_UDP_PSM_ENABLE=y
    CONFIG_LTE_PSM_REQ_RPTAU="00100001"
    CONFIG_LTE_PSM_REQ_RAT="00000000"

    which is the default settings for the UDP project that comes with the 1.4.2 SDK.

    I understand that maybe the PSM is not set up correctly but in the bottom of my original post I had the MCU go to sleep right as it enters main() so I would think that the modem would not be enabled in that scenario, but still the measured current seems well above typical sleep current.

  • Hi again!

    Thanks for the information. We have an overview of iBasis' coverage details in different regions. From what I can see PSM was not supported for T-mobile in November at least. It may be supported by T-Mobile, but iBasis as a third-party SIM-distributor does not necessarily have access to that functionality.

    The PSM-settings seems correct. I missed that the modem wasn't initialized in your "straight-to-sleep" test and agree that the sleep current seems high, which is weird.  To rule out any development environment issues, could you try the following two hex files on your device? The first one is the base UDP sample, with PSM. 

    7041.udp_to_sleep.hex

    The second one sends the device straight to sleep.

     8512.udp_normal.hex


    In addition, could you tell me which version of the DK you are using and give me a diagram/picture of your setup?

    Best regards,
    Carl Richard

Reply
  • Hi again!

    Thanks for the information. We have an overview of iBasis' coverage details in different regions. From what I can see PSM was not supported for T-mobile in November at least. It may be supported by T-Mobile, but iBasis as a third-party SIM-distributor does not necessarily have access to that functionality.

    The PSM-settings seems correct. I missed that the modem wasn't initialized in your "straight-to-sleep" test and agree that the sleep current seems high, which is weird.  To rule out any development environment issues, could you try the following two hex files on your device? The first one is the base UDP sample, with PSM. 

    7041.udp_to_sleep.hex

    The second one sends the device straight to sleep.

     8512.udp_normal.hex


    In addition, could you tell me which version of the DK you are using and give me a diagram/picture of your setup?

    Best regards,
    Carl Richard

Children
  • Thanks for the link on iBasis information, I am a bit closer to San Diego than Los Angeles so I guess thats why I am connecting to the T-mobile network. Good to know as we were planning to buy verizon sim cards in the future.

    as for the sample hex files you provided the behavior is very similar to the tests I had done (with the exception that your UDP example does not have any current spikes when its trying to sleep).

    UDP with sleep:

    Straight to sleep:

    Both seem to have a sleep current of about 1.7mA.

    So this leads me to believe there is an issue with how I am doing my power measurements.

    Below is a picture of how I have the DK set up. 

    Forgive the odd wiring, I am just using whatever I have at home. Basically the + side of the Otii is connected to the VIN pin on p20, while the - side is connected to a nearby GND.

    The NRF9160DK version is shown below

  • Hi!  

    I believe this may be related to your measurement setup. Source measurement should be done by connecting to P22 and P21 as done in the diagram I've attached below. The external power supply and the USB connected to the DK can be ignored. 

    You can also read more about this in the current measurement documentation.

    Hope this yields more correct results for you!

    Best regard,
    Carl Richard

  • Interesting, I had tried connecting both pins to p21, or both to p22 but not the configuration you show above.

    I think my board may be a little different, I only have 2 pins on p22. Here is how I have it connected (yellow is connected to + on the otii, brown is -)

    if I move the yellow wire to the left it does not seem like the device works.

    unfortunately the result when using the 'udp_to_sleep' hex file you provided shows higher current consumption when I measure it this way.

  • Hi again!

    The DKs has been revisioned since I made the diagram below, but the setup should still be viable. I.e. the Otii "+" should go to the leftmost VDD_nRF and the Otii "-" should go to external supply "-". What happens when you say that it doesn't seem to work? Try to keep the IFMCU Connected by resetting SW6 aswell.

    A colleague suggested that you try with 3.7V as the source voltage, as all measurements in the Product Spec. have been done at that level. 

    Best regards,
    Carl Richard

  • I may have been mistaken, my process for trying different ways of connecting power was to turn off the DK with SW8, turn off the Otii, rewire to a new configuration, then turn the Otii back on, and finally turn SW8 back on to power the DK.

    Typically I would then see a current spike on the Otii as I switched everything on. However with the power connected as you suggest it does not seem like SW8 or the reset button does anything, so the lack of current spike made me believe nothing was running. It was in fact just sleeping. When I loaded my original software it worked as expected, and the extra 1.7mA baseline current seems to be gone.

    Additionally the sleep current between data transfers has gone down to 57uA, and those current spikes I saw once every second or so seemed to go away. Am I in PSM mode? Not sure, I think I will do some further investigation on the nearby network's capabilities, but for now I think we have a good idea for what the power requirements are to transfer data every 5 minutes and that's the main thing I wanted out of this.

    Thanks for all your help!

Related