-
Notifications
You must be signed in to change notification settings - Fork 84
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Power consumption after calling uGnssPwrOff #254
Comments
Hi there: 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. |
I'll definitively be trying |
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.
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. |
I'll ask the HW experts on my team to help me check that on Tuesday (next Monday is a public holiday here).
Then I'll try
Thank you. |
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 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 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 Does that sound OK to you? |
Should you wish to try it, find here a preview branch that provides this feature. I can't remember which platform you are running 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 |
I have not been calling
I've just been calling 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 Thank you for trying to help, and sorry for probably wasting your time. |
NP, I think having
Depends really: if you called
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. |
Change is now on |
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 whatuGnssPwrOff
is supposed to do?The text was updated successfully, but these errors were encountered: