nrf9160 gnss power saving mode

[ncvasil]

Hi all,

I am trying to develop an application that frequently gets location info using gnss and also needs to work with battery.

In the Product Specification v2.2 I found that in continuous mode and power saving enabled - the average current consumption can be around 10 mA:

I decided to try the "nrf/samples/cellular/gnss" example on the nrf9160dk board and measure the current using jumper P22.

I configured the project to use power saving mode like so:

Then build and flashed. While the application was running and the board was trying to get a fix - the measured current was around 38-40 mA, and not the expected 9-10 mA.

I expected the consumption to drop, but it did not. Am I missing something?

I tried the other modes too and they were all the same (around 40 mA as if no power saving mode was selected).

I also checked https://docs.nordicsemi.com/bundle/ncs-latest/page/nrfxlib/nrf_modem/doc/gnss_interface.html#power_saving_mode which summarizes the info from above about gnss power saving mode, but I can not find out why the duty cycling does not kick in. Any advice will be appreciated.

Thanks.

[Simonr]

Hi

Did you make sure to do a pristine build after enabling the power saving mode? Also, what nRF Connect SDK version are you using here, so I can do a test on my end? Is the initial fix completed or do you just measure the current consumption initially? As i think the current consumption here refers to the tracking after an initial fix has been established.

Best regards,

Simon

[ncvasil]

Hi, Simon,

Yes, I made sure that the changes from the Kconfig are saved to prj.conf and then rebuild. The 

nrf_modem_gnss_power_mode_set(...) gets called with parameter 

NRF_MODEM_GNSS_PSM_DUTY_CYCLING_POWER.

I tried that on nRF Connect SDK v2.5.0 and v2.6.2 - same result: current consumption is around 40mA before first fix and remains the same after the first fix - no change. I left it like that for a few minutes - no change (while it keeps getting more fixes from satellites).

The LTE is not used, only GNSS, so I can't see what else can draw current.

EDIT: After leaving it on for a while, I noticed that very rarely the consumption drops to 1-2 mA and in the serial terminal I see the message "Sleep period(s) between PVT notifications" which means that indeed the duty-cycling is engaged, but it happens very rarely. For example the consumption stays around 40 mA for 20-30 seconds, then drops below 10mA for 3-4 seconds and so on. But definitely the average consumption for the whole period is closer to 40mA.

Best regards,

Vasil

[Michal]

Hello Vasil,

I took over the case from my colleague Simon.

I assume that you are only testing this inside? What happens if you would for example put the device outside (for example outside the window)?

I wonder if it's behaving like this, because it takes so long to get a GNSS fix while inside.

Best regards,

Michal

[ncvasil]

Hi, Michal,

Michal said:

I assume that you are only testing this inside? What happens if you would for example put the device outside (for example outside the window)?

The nRF9160dk is indoors, but right by the window.

After the application "cellular/gnss" boots up (continuous mode and power saving enabled as described above) the average consumption hovers around 40mA - I guess it is due to the constant listening and downloading the necessary data from the satellites.

Since the dk board is close to a window - it has little trouble getting first fix - a few seconds to a minute.

Observing the uart output I get a fix every second from this moment on (still indoors, close to window) and the current consumption is 40mA on average, and very rarely dropping down to 1-2 mA (when this happens, the uart log also displays "Sleep period(s) between PVT notifications" as expected)

However, if I handle the dk board and move it no more than 1 meter, slightly outside the window - then it gets the best 'view' of the satellites and the consumption drops as expected (5-6 seconds it is 1-2 mA, 1-2 seconds it goes back to 40 mA, around 10 mA on average) which is great.

In both cases I get a fix. And only when the conditions are perfect - I also get the desired ~10 mA consumption.

My question is: is there a way to constantly force the duty-cycling that will give me ~10 mA (after firs fix)? That will probably come at a cost - lowered accuracy I guess, but still it would be acceptable in my case.

NOTE: I also tried to use "A-GNSS" in order to minimize the satellite communication but the result was the same.

Michal said:

I wonder if it's behaving like this, because it takes so long to get a GNSS fix while inside.

After the device obtains first fix - the consumption remains high ~40 mA - I get a fix every second, but the consumption is ~40 mA. Only in perfect conditions the consumption drops down - but I am ok to have 'close to perfect' conditions and get a lower accuracy fix, as long as the current consumption is low.

Best regards,

Vasil

[Michal]

ncvasil said:

My question is: is there a way to constantly force the duty-cycling that will give me ~10 mA (after firs fix)? That will probably come at a cost - lowered accuracy I guess, but still it would be acceptable in my case.

So the desired result is for the duty-cycling to timeout after the first fix, right?

But then, should it always timeout if it cannot get the fix in time (and risk potentially never getting a fix), or maybe every nth try it should still try for longer time?

[ncvasil]

Michal said:

So the desired result is for the duty-cycling to timeout after the first fix, right?

Yes

Michal said:

But then, should it always timeout if it cannot get the fix in time (and risk potentially never getting a fix), or maybe every nth try it should still try for longer time?

The second approach sounds like a better trade-off: we accept getting a fix less frequently and have lower power consumption.

If that frequency of getting a fix gets too low (like you said - after nth try we fail) - then it is ok to go back to normal continuous mode with higher power consumption.

That was my understanding while I read this:

https://docs.nordicsemi.com/bundle/ncs-latest/page/nrfxlib/nrf_modem/doc/gnss_interface.html#power_saving_mode

I could be wrong.

It would fit very well in my application. because in case there are no healthy satellites (even on cold start, before first fix) for a certain period of time - I will stop the gnss for a while and not waste any energy while the conditions for a fix are not good.

Hope there is some approach I can use constant (forced) duty-cycling after first fix. Thanks.

Best regards,

Vasil

[Michal]

Thank you for the answers Vasil.

I will have to look more into it and check how exactly it is implemented. Worst case there may be some development needed.

Best regards,

Michal