GPS in motion or stationary

[shaunix]

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?

[crumble]

Depends.

The accelerometer consumes less power and will not need a GPS fix to work, so it can be used faster.

TO detect the motion, you can either parse the matching NMEA sentence or calculate the distance between two points. Calculating the distance can be tricky, but you can assume a perfect ball for simple motion detection. Don't forget to use a delta dor comparing the distance. GPS will be allway in motion, if you compare only points.

[jcaron]

@shaunix It probably depends on the accuracy you need.

Even when not moving, GPS coordinates will usually vary quite a bit. Not sure how the GPS on the Pytrack behaves in this respect, but I've routinely seen GPS receivers showing variations of over 10 meters while being perfectly still.

If you want something more precise, the accelerometer is probably a better choice, but you'll either need to poll it more often or set it up to signal on movement, otherwise you may miss actually movement between polls.

Also, you need to properly pick your thresholds, even in a car at standstill, there may be a bit of movement from passengers moving in the car for instance. Possibly even from vibrations from the engine, depending on the car and where the Pytrack is placed.

As usual, YMMV and nothing beats actual testing.

[PeterB]

@shaunix Normally a good GPS chip calculates speed based on Doppler, not by dx/dt. By Doppler is much more accurate than dx/dt due its noise on dx.
The library https://docs.pycom.io/pytrackpysense/apireference/pytrack.html does not seem to provide the speed signal from the GPS chip. Even other basic GPS infomation is not available from the standard library. But there are alternatives available reading NMEA data from the chip, including speed which will be Doppler based, as shown below. For the alternative libraries:
https://github.com/inmcm/micropyGPS
https://github.com/andrethemac/L76GLNSV4/blob/master/L76GNSV4.py

The chip seems to be very modern: https://www.quectel.com/product/l76.htm
including SBAS (WAAS/ EGNOS/ MSAS/ GAGAN) capability making it more accurate than the standard GPS
The specification https://www.quectel.com/UploadFile/Product/Quectel_L76_GNSS_Specification_V1.5.pdf shows an accuracy of velocity of 0.1 m/s (0.36 km/h), that is only possible with Doppler based speed measurement.

So if you use one of the libraries to read the speed signal from the chip and you see more than 0.36 km/h you can be quite sure the systm is on the move.

[shaunix]

@PeterB Thanks for your reply! It helped me a lot.

I started to use the library you suggested: https://github.com/andrethemac/L76GLNSV4/blob/master/L76GNSV4.py

I love how I now have access to more information but now I'm experiencing dramatic spikes.

Most of the time the data appears to be within expected ranges but I'm now seeing distances as high as 185 meters (using the haversine method for calcs) and speeds as high as 7.93km/h when stationary. And everything in between.

This is difficult to rely on.

I'm trying to figure out how to use HDOP to determine an acceptable level of accuracy so I can decide to throw away the result and try again until I get something acceptable but I'm not sure what time number represents. I've read that 1 is good. I seem to get under 1 a lot.

Do you have any other insight that may help me on my journey to achieve accurate GPS results for my pytrack?

[PeterB]

@shaunix said in GPS in motion or stationary:

@PeterB Thanks for your reply! It helped me a lot.

I started to use the library you suggested: https://github.com/andrethemac/L76GLNSV4/blob/master/L76GNSV4.py

I love how I now have access to more information but now I'm experiencing dramatic spikes.

Most of the time the data appears to be within expected ranges but I'm now seeing distances as high as 185 meters (using the haversine method for calcs) and speeds as high as 7.93km/h when stationary. And everything in between.

This is difficult to rely on.

I'm trying to figure out how to use HDOP to determine an acceptable level of accuracy so I can decide to throw away the result and try again until I get something acceptable but I'm not sure what time number represents. I've read that 1 is good. I seem to get under 1 a lot.

Do you have any other insight that may help me on my journey to achieve accurate GPS results for my pytrack?

Distances, speed? I hope you do not calculate speed bases on distance and time but get the direct speed signal from the chip via get_speed(). Only that one can be Doppler based as it is an internal calculation on the raw GPS signals.
Also changes in location of 185 m is very high. Are you inside a building? That could cause some issues with reflections in the building. Do you have some free sight to south (supposing you live on the Northern Hemisphere) to receive SBAS signals of geostationary satelites. That woud increase accuracy a lot.

[shaunix]

@PeterB

I get the speed from get_speed() I've noticed that in some testing locations I get better results so I need to start testing out on the road before I find a comfortable threshold to work with.

I use the Haversine method to calculate distance in meters between 2 locations based on the previous read coordinates. Example: Haversine([lon1, lat1], [lon2, lat2]).meters

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.

I am testing inside a building but I'm right next to large windows with a clear view of the Northern sky. I get better results when near a window that faces South.

Can you shed any light on the HDOP score? How can I use this to discard inaccurate results? discard and try again if HDOP > 2 (for example)

[PeterB]

@shaunix said in GPS in motion or stationary:

@PeterB

I get the speed from get_speed() I've noticed that in some testing locations I get better results so I need to start testing out on the road before I find a comfortable threshold to work with.

I use the Haversine method to calculate distance in meters between 2 locations based on the previous read coordinates. Example: Haversine([lon1, lat1], [lon2, lat2]).meters

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.

I am testing inside a building but I'm right next to large windows with a clear view of the Northern sky. I get better results when near a window that faces South.

Can you shed any light on the HDOP score? How can I use this to discard inaccurate results? discard and try again if HDOP > 2 (for example)

Are you sure you have the correct input for the haversine function, i.e. fully decimal degrees or radians (depending on what the function expects on input).
You can test your Haversine function with some test input: a distance of 1 degree in North-South should lead to a distance of 60 NM, or 1 minute (0.016666666 degree) in North-South direction should be 1 NM = 1852 m.

If you are inside a building that could be an issue. Being near a window does not really matter for the normal GPS satelites as they can be anywhere around you and might be masked by the non window side of the buidling, including multipath reflections.
For the geostationary SBAS sattelites being near a window on the south side (@Northern Hemisphere) will help. Then you can expect a much better result.

For HDOP the next article might be interesting: https://web.archive.org/web/20140222000521/http://www.crowtracker.com/hdop-gps-position-errors/

[Martinnn]

@PeterB Some time ago I was working with a ublox GPS module and sometimes could not even get a fix (cold start) inside a building. I had to use an active antenna to make this work. Maybe take your setup and go outside to verify it is not a signal strength issue. If you have an android phone, you can use the "GPS test" app https://play.google.com/store/apps/details?id=com.chartcross.gpstest to check signal strength and see where the satellites are.
BTW the ublox eval kit software shows an insane amount of detail on GPS operation, so if you want to learn the finer points, this might be worth looking into.

[PeterB]

@Martinnn said in GPS in motion or stationary:

... If you have an android phone, you can use the "GPS test" app https://play.google.com/store/apps/details?id=com.chartcross.gpstest to check signal strength and see where the satellites are. ...

My phone does not show the SBAS satelites on GPS test, I am not sure whether my Samsung Galaxy Note 9 has SBAS capabi;lity. It shows an accuracy of 8 meters (horizontal), which is normal for a signal without SBAS. Including SBAS I would expect 1 - 3 meteres accuracy

[crumble]

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

[PeterB]

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

[crumble]

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

[PeterB]

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

[Martinnn]

@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]

@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

[Martinnn]

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

[PeterB]

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

[jcaron]

@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]

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