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.

  • 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!

  • I see! When wiring this way the nRF9160 is powered directly, so that the SW8 won't have any effect. Good to hear that it now works properly!

    It sounds like you are indeed entering PSM, but the 57uA current is higher than what is to be expected based on our PS. Some sims (including iBasis I think) does not turn off during PSM resulting in a current draw of ~27uA, which may be a part of what we're seeing here at least.

    Anyway, glad to help!

    Best regards,
    Carl Richard

Related