GPS in motion or stationary
-
@Martinnn said in GPS in motion or stationary:
@PeterB said in GPS in motion or stationary:
With SBAS it is typically 2-3 m horizontally and 1.5 m vertically.
Maybe I coult throw in a little challenge I have been thinking of:
I'd like to have a little box on my backpack/bike that permanently displays the correct altitude (above MSL), without any user interaction (like pressing "on", "refresh", "set altitude"...). A perpetual altimeter so to speak. Acceptable size would be 1-2 matchboxes, battery life in the years range.There are a number of challenges. Barometric would need frequent recalibration, GPS uses a lot of power and/or clever maintenance of almanach/ephemeris data. GPS aiding could help reduce power, but needs GSM/UMTS/LTE data connection. And then you'd need to avoid wasting power if the GPS sits inside the cellar with no reception at all.
Actually a (very difficult) exercise in GPS power management. Leaving GPS active would drain reasonably sized batteries within hours; to make them last years seems quite an effort.I do not know of any possibility to feed almanac etc data to the GNSS chip from other sources. Idem for SBAS data.
In your case I would calibrate the barometric altitude with a regular GNSS update, e.g. every 30 mins should be sufficient. That is only feasible when it is an SBAS enabled GNSS and if it gets a valid SBAS signal. Otherwise or initially use the QNH setting of nearest airport's METAR (use Google for explanation)
To get such data have a look at: https://www.aviationweather.gov/dataserver
This might alos be interesting: http://www.schwarzvogel.de/software/pymetar.html -
@PeterB hmmm. I was working with ublox receivers recently, where you have this possibility:
https://www.u-blox.com/en/solution/services/assistnow
I am aware of METARs and QNH. Experience with my barometric altimeter watch shows that you quickly have a > 100 m error - which I doubt to be a measurement error, I'd assume local pressure differences (eg. due to wind) or deviations from the ISA standard atmosphere model. -
@Martinnn said in GPS in motion or stationary:
@PeterB hmmm. I was working with ublox receivers recently, where you have this possibility:
https://www.u-blox.com/en/solution/services/assistnow
I am aware of METARs and QNH. Experience with my barometric altimeter watch shows that you quickly have a > 100 m error - which I doubt to be a measurement error, I'd assume local pressure differences (eg. due to wind) or deviations from the ISA standard atmosphere model.Local pressure differences due to wind I can not imagine if the wind is not blowing in to the pressure sensor and if hole is small.
100 m of error can not really be local pressure difference if you take the QNH from a nearby airport. Temperature difference from ISA only play a role if your altitude differs a lot from the airport used as reference and additionally temperature differs a lot from ISA behaviour relative to temperature of the airport. QNH is determined in such a way that independent of temperature an altimeter using ISA for its indications will show the correct altitude of the airport at the altitude of the airport. If above (or below) that airport the behaviour is different form ISA your atimeter at that other altitude will have a deviation. -
@Martinnn I think your challenge would keep quite a few people busy for quite a while, though it may depend a bit on a few parameters, including:
- the actual target size (matchboxes come in many different sizes)
- the frequency of the updates
- how often/how long the device is actually used
Several years of battery life is the big issue. Considering a 2500 mAh battery (which is already quite large), lasting for 5 years means less than 10 mAh per week. Let's keep 8 mAh for 8 hours of use each week, and 2 mAh for the remaining 160 hours of standby. That's all considering the battery is ideal, will actually deliver the rated capacity, will have no self-discharge at all, etc, which is probably far from reality (especially if you get outside the battery's operating temperature range).
That brings you to a maximum average power draw of 1 mA while in use, and 12.5 µA while in standby.
The lowest power sensor to detect when you start moving would probably be a cheap vibration sensor such as this one: it doesn't use any power at all until you move. So you just need to have some controller than can sleep using less than 12.5 µA while waiting for an interrupt. Should be OK.
Now for the part where the sensor is actually awake. You need a screen to display the altitude. OLEDs, color TFT LCDs, etc. will draw too much power. Black and white LCDs without a backlight are OK but they are often seriously unreadable. You probably need to go with a a small e-ink panel. That will use power only during refreshes (but the refresh process can be quite slow).
To measure the altitude, a GPS will probably eat way to much power if you keep it on all the time (while active). You probably want to use the GPS only once a while to get a reference and recalibrate, and then use a barometric sensor the rest of the time. Finding the right balance is difficult: when you shut down the GPS, it takes longer to acquire a position again.
But once you get out of the sensors and display, you have the issue of you main controller. The ESP32 when active draws way too much. If you set it to deep sleep, then it takes a little while to wake up. With an update every minute, even if you manage to wake up, read sensor, update display, and go back to sleep in 3 seconds, if you do that every minute, and you count about 50 mA average power draw during the active phase, that's still 2.5 mA, which is way over our 1 mA total budget.
So you'll probably have to switch to a different processor that eats lets power and/or wakes up faster, or at the very least program the ESP32 natively rather than using the micropython stack to reduce awake time as much as possible.
Of course, all those figures are just thrown out of the window if you tell us the device should operate longer each week, or you need to use a smaller battery, or you want updates every 5 seconds rather than every minute, etc. That's the reason you should start with those requirements first.
-
@jcaron said in GPS in motion or stationary:
@Martinnn I think your challenge would keep quite a few people busy for quite a while
My thoughts exactly. Very good analysis btw.
- Battery: I think a LiTCL AA cell would fit here. https://www.mouser.ch/Search/Refine?Keyword=667-TL5903/SBP
- Size: There's no hard limit here. As it is a non-essential item, I wouldn't want to lug around a hefty box.
- Display: I agree e-ink is fine
The main problem would be some clever activity detection. No point switching the device on when at home in a storage closet. So obviously motion detection, light level measurement, maybe wifi (switch off when at home)...
It is very unfortunate that one can't meaure receive signal strength of the GPS without letting it run for a few minutes (consuming an insane amount of energy). And probably the ESP32 is the wrong CPU - just sending a few commands to the GPS and updating an e-ink panel doesn't need that much processor power.
But do I understand PeterB correctly that there is no possibility of "aiding" for the GPy? This means that the GPS has to download almanac data from the GPS satellites (which takes 12 minutes IIRC)? It also means that if you have the GPS off for some time, you do a cold start - which takes forever (minutes) and also typically has lower sensitivity. In difficult situations (indoor) this could mean that you don't get a cold start fix at all, while a hot start is still possible. -
The L-76 GPS has a lot of power saving options. It uses an internal memory to store the almanac. The chip itself can track your route for some time. The the normal documentation does not mention the format of this data. I guess you have to pay an additional fee to use this feature.
-
This post is deleted! -
@crumble said in GPS in motion or stationary:
The L-76 GPS has a lot of power saving options. It uses an internal memory to store the almanac. The chip itself can track your route for some time. The the normal documentation does not mention the format of this data. I guess you have to pay an additional fee to use this feature.
I would indeed expect i stores the almanac data when 'switched off'. Major question is wether it is switched off nicely in the correct power save mode by pysense. The pysense is not designed to take sleepmodes seriously (e.g. ESP32 RTC disabling and OS killing instead of shutdown).
-
@PeterB from what I understand it’s not permanent storage, the L76 needs to stay powered to keep the data, however it can get to a pretty low power mode and still keep that data. You’ll have to tell the chip to move to that mode.
The Pytrack can be set to sleep while still powering the GPS chip.
-
@PeterB said in GPS in motion or stationary:
I would indeed expect i stores the almanac data when 'switched off'.
go_to_sleep has an option to power the GPS
Major question is wether it is switched off nicely in the correct power save mode by pysense.
No, you have to send the right MTK sentences to the L76. MTK sentences are used to configure the chip. There are 4 ways to start it. If you want to use the most energy and time saving mode, you have to take care about a lot of stuff. You have to ensure that the alamnac is stored in the GPS and last fix is not older than 3 hours.
Therefore you cannot use the PIC deepsleep or you need an external RTC.
It shall work. I gave up because of i2c and own errors. I can try it again this week and share my result.
-
@crumble Just to re-confirm, the only way to get the almanac on the GPy is to download it from the GPS network itself, which takes 12.5 minutes (due to the low baud rate) after a cold start:
https://stackoverflow.com/questions/16384844/is-there-a-way-to-download-the-gps-almanac
I was looking for an "assisted" version that lets you download the data, but for this GPS chip this does not seem to exist. -
@crumble said in GPS in motion or stationary:
Therefore you cannot use the PIC deepsleep or you need an external RTC.
That seems incorrect. You can set the PIC to deep sleep while keeping the GPS powered. You would have to set the GPS chip to backup mode before going to sleep (and wake it up after sleep), though.
-
@jcaron said in GPS in motion or stationary:
@crumble said in GPS in motion or stationary:
Therefore you cannot use the PIC deepsleep or you need an external RTC.
That seems incorrect. You can set the PIC to deep sleep while keeping the GPS powered. You would have to set the GPS chip to backup mode before going to sleep (and wake it up after sleep), though.
You need to know that the L76 is not sleeping longer than 3 hours, if you want to use hot start. If you can calculate the deepsleep time from the PIC its incorrect. I have always the primitive timers of my short AVR experience in mind.
-
@Martinnn said in GPS in motion or stationary:
I was looking for an "assisted" version that lets you download the data, but for this GPS chip this does not seem to exist.
The documentation mention an AGPS mode called EASY and how to set and query the mode. By default it is on. But it neither tells how to upload data nor which format is needed.
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login