Comments (9)
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.
from ubxlib.
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.
from ubxlib.
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?
from ubxlib.
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.
from ubxlib.
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?
from ubxlib.
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.
from ubxlib.
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.
from ubxlib.
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.
from ubxlib.
Change is now on master
here in d4d58a5 in case you need it; I will delete the preview branch.
from ubxlib.
Related Issues (20)
- Unable to bring up GNSS! HOT 21
- USECMNG invalid certificate/key format HOT 18
- esp32c6 i2c m10 HOT 7
- uCellInfoGetTimeUtc - AT+CCLK sometimes returns invalid date HOT 3
- esp idf i2c legacy driver issue HOT 4
- rewrite certificates after reboot HOT 2
- best way to combine device-tree interfaces with uDeviceCfg_t in zephyr HOT 3
- example to use token of location thing HOT 6
- Unable to start continuous location! HOT 11
- Compiling & building HOT 4
- Unable to create HTTP instance! HOT 11
- Build for STM32 CUBE HOT 4
- ESP32 Demo HOT 3
- Untethered Dead Reckoning and odometer use with cellular module integration HOT 11
- stm32u5 example hanging HOT 11
- Data Ready PIN HOT 4
- A good practice proposol HOT 1
- Cellular Callback for Signal Changes HOT 1
- Enable debug log HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ubxlib.