GPS in motion or stationary



  • Using GPy on Pytrack in a car that collects GPS coordinates every 60 seconds.
    What is the best way to determine that the car is in motion or at a standstill?
    I assume that comparing GPS coordinates between 2 timestamps can do this...
    Is that the best way?
    Are there any libraries to use for these calcs?
    Is using the accelerometer a better way?
    Is using a combination of both even better?



  • @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.



  • @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.



  • @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.



  • @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.



  • @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.



  • @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.



  • @crumble said in GPS in motion or stationary:

    @Martinnn

    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).



  • This post is deleted!


  • @Martinnn

    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.



  • @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.

    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.



  • @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.



  • @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.



  • @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 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 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.



  • @PeterB said in GPS in motion or stationary:

    ...
    Please note that the vertical accuracy of standard GPS is much worse than horizontal accuracy. That is only solved with a good SBAS signal.
    ...

    Found some figures:
    Civilian GPS without SBAS is better than 35 m horizontally and 75 m vertically 95% of the time.
    With SBAS it is typically 2-3 m horizontally and 1.5 m vertically.



  • @PeterB

    and you have to assume that you are in the same pressure area during the series of points. And you have to deal with wind speed and other stuff. It's only the cheapest additional method.

    GPS shall be the best guessing method, if the device wakes up arbitrary without any information about the environment.



  • @crumble said in GPS in motion or stationary:

    @shaunix said in GPS in motion or stationary:

    I realize that the distance isn't going to be super accurate but 185m is way too high. I'm hoping I can get within 15 meters.

    If you do not plan to place your device high in the sky, you will run every nowe an than into the same problems as ion your building. If you need precise altitude, you have to add additional guessing methods with different errors and try to calculate a more precise value of the whole data set.

    Bycicle computers use barometric values for this. The better ones try to calibrate the values with a map.

    Inside buildings you may have to use indorr navigation by triangulating access points.

    Please note that the vertical accuracy of standard GPS is much worse than horizontal accuracy. That is only solved with a good SBAS signal.

    For barometric altitude you must know the air pressure at Mean Sea Level or the combination of air pressure and a kown altitude. If you are high above the reference plane which determined the air pressure on MSL or local, you must also know the temperature.



  • @shaunix said in GPS in motion or stationary:

    I realize that the distance isn't going to be super accurate but 185m is way too high. I'm hoping I can get within 15 meters.

    If you do not plan to place your device high in the sky, you will run every nowe an than into the same problems as ion your building. If you need precise altitude, you have to add additional guessing methods with different errors and try to calculate a more precise value of the whole data set.

    Bycicle computers use barometric values for this. The better ones try to calibrate the values with a map.

    Inside buildings you may have to use indorr navigation by triangulating access points.


Log in to reply
 

Pycom on Twitter