Power consumption after calling uGnssPwrOff

[KjartanOli]

I've just finished an experiment where we measured the power consumption of a ZED-F9P before and after calling uGnssPwrOff. While the power consumption certainly decreased significantly it remained ~3mA, which is higher than the 0mA we were hoping for. Is there a reason the module still consumes power when supposedly powered off, or am I misunderstanding what uGnssPwrOff is supposed to do?

[RobMeades]

Hi there: uGnssPwrOff() sends a UBX-CFG-RST message, 0x06 0x04, with resetMode 0x08, "controlled GNSS stop", so the GNSS system, which is the only thing that ubxlib switches on, should be switched off. There are other sources of current draw, I guess: for instance, something is powering the active antenna, and I don't know whether that is switched off when the GNSS system goes off or not; you might, I guess, have to call uGnssCfgSetAntennaActive() to stop it (you could, at least, try this as an experiment to see if it makes any difference). Which interface as you using: UART, SPI or I2C?

But I'm not an expert in this area, I will have to ask my colleagues in Positioning about this on Monday. Where do you purchase our devices from? There should be an "official" line to our positioning support people through that route.

[KjartanOli]

I'll definitively be trying uGnssCfgSetAntennaActive, thanks for that. I'm using I2C. I'll have to ask the person who did the purchasing about where they did but I'll probably not get a response until Tuseday. Are there any other functions like uGnssCfgSetAntennaActive I could try/use?

[RobMeades]

I'm using I2C

Someone who knows HW should probably check that the pull-up resistors aren't doing something, or that the GNSS chip isn't somehow drawing current through the comms interface (I have seen something like this before in another context). But I'm no HW expert.

Are there any other functions like uGnssCfgSetAntennaActive() I could try/use?

Not that I can think of: there are remarkably few power-related commands to control the GNSS device; the current consumption is mostly dictated by the GNSS system and my understanding is that with it stopped there shouldn't be anything doing anything, IYSWIM.

But as indicated, this is not something I know a lot about so I shall ask for some education on Monday and will hopefully be pointed at a public document describing how to power-optimise our GNSS system that I was not previously aware of.

[KjartanOli]

I'm using I2C

Someone who knows HW should probably check that the pull-up resistors aren't doing something, or that the GNSS chip isn't somehow drawing current through the comms interface (I have seen something like this before in another context). But I'm no HW expert.

I'll ask the HW experts on my team to help me check that on Tuesday (next Monday is a public holiday here).

Are there any other functions like uGnssCfgSetAntennaActive() I could try/use?

Not that I can think of: there are remarkably few power-related commands to control the GNSS device; the current consumption is mostly dictated by the GNSS system and my understanding is that with it stopped there shouldn't be anything doing anything, IYSWIM.

Then I'll try uGnssCfgSetAntennaActive and hope it does the trick. The board with the ZED-F9P is a SparkFun GPS-RTK2 which includes some status LEDs, it is possible these are responsible for all of the power consumption we are seeing. Thankfully I discovered a few minutes ago how to disable them so we should be able to prove/disprove that hypothesis next week.

But as indicated, this is not something I know a lot about so I shall ask for some education on Monday and will hopefully be pointed at a public document describing how to power-optimise our GNSS system that I was not previously aware of.

Thank you.

[RobMeades]

I have talked to the relevant experts now and they point out that the way to minimise power consumption is to use the "backup" modes. We support this in ubxlib through the uGnssPwrOffBackup() command but it is not what the uDeviceClose() function calls when asked to power the device down (as you know, it calls uGnssPwrOff()).

The reason for this arrangement is that the way to restore the GNSS device from back-up mode is via toggling the comms lines and the I2C pins are not included in the list of pins that will perform the wake-up so, if the GNSS device is connected via I2C, the application would need to toggle the reset line, or a chosen GPIO line, to wake the GNSS up; all getting a bit beyond what ubxlib can do, this has to be much more an application thing.

But of course, once uDeviceClose() has returned you can no longer do anything with the GNSS device so that's not much use. I think the best thing to do would be for me to add a new Boolean item to the uDeviceCfgGnss_t structure called something like powerOffToBackup. You could then set this to true and uDeviceClose() would call uGnssPwrOffBackup() instead of uGnssPwrOff(); since the application code will have set the variable to true it will be prepared for whatever mechanisms are required to bring the GNSS device up from back-up mode again (in the comments I will point the user at the GNSS integration manual section on backup modes for advice).

Does that sound OK to you?

[RobMeades]

Should you wish to try it, find here a preview branch that provides this feature. I can't remember which platform you are running ubxlib on but you can either populate the field powerOffToBackup in your uDeviceCfgGnss_t structure with true or, if you are using Zephyr, you have the option of setting the flag power-off-to-backup in the u-blox,ubxlib-device-gnss structure of your .overlay file for your GNSS device.

Remember that you will need to figure out how to get the GNSS device to return from back-up mode in your particular situation though.

If this works for you I will push it to master here.

[KjartanOli]

I have not been calling uDeviceClose, I've been calling uGnssPwrOff directly (is that something I shouldn't do?)

Remember that you will need to figure out how to get the GNSS device to return from back-up mode in your particular situation though.

I've just been calling uGnssPwrOn, which has seemed to work fine in my tests. I have the RESET line connected, so that probably has something to do with it.

But none of that matters any more. Disabling the status LEDs on the SparkFun board didn't result in any noticeable power savings and neither did uGnssCfgSetAntennaActive. As a result the hardware people have decided that we're going to be using an external regulator to control power to the GNSS module, which will allow us to cut power to it completely when not in use. (Are there any reasons why we shouldn't do this?)

Thank you for trying to help, and sorry for probably wasting your time.

[RobMeades]

Thank you for trying to help, and sorry for probably wasting your time.

NP, I think having uDeviceClose() [not] being able to call uGnssPowerOffBackup() was a real issue, so I will still make the change.

I've been calling uGnssPwrOff directly (is that something I shouldn't do?)

Depends really: if you called uDeviceOpen() then at some point you should call uDeviceClose(), otherwise memory won't be tidied up, but you can call uGnssPwrOff() and uGnssPwrOn() as much as you like in-between.

the hardware people have decided that we're going to be using an external regulator to control power to the GNSS module, which will allow us to cut power to it completely when not in use. (Are there any reasons why we shouldn't do this?)

Definitely a good way to get your power consumption under control, all you need to bear in mind is that, when wired up to power-off-to-backup the GNSS device can maintain time and some data, whereas if you disconnect power entirely it will be coming up from a cold start each time and so will take an absolute minimum of 30 seconds, even with clear sky, to get a fix.

[RobMeades]

Change is now on master here in d4d58a55d5c7525009bde0be966db0ad4d29f692 in case you need it; I will delete the preview branch.