This article is to explain some general concepts around GPS, as well as the behaviour and available settings specific to Digital Matter devices and how they acquire GPS location information. In general, most settings are best left on defaults. Examples on how to solve common issues, or adapt the parameters to certain use cases are also given towards the end of the article.
TABLE OF CONTENTS
- GNSS vs GPS
- Just how accurate is the GPS on Digital Matter Devices?
- How devices acquire fixes
- GPS Settings
- Notes on Dilution of Precision (DOP) And Specifically PDOP
- Advanced GPS Settings
- Initial Satellite Strength Configuration
- Common Issues and Use Cases
GNSS vs GPS
GPS (Global Positioning System) was originally developed by the US Military, and later released for civilian use. It is a constellation of satellites orbiting the earth, emitting signals which allow devices to locate their position on the Earth.
GNSS (Global Navigation Satellite System) is the umbrella term for ALL such systems. Though often, GPS is also used as the umbrella term (like in this article!) As other nations have also launched satellites to perform the same job. Our latest range of devices use the uBlox EVA M8 GPS module - and makes use of GPS and GLONASS satellite constellations - meaning a greater chance of getting a fix as more satellites are on offer.
Just how accurate is the GPS on Digital Matter Devices?
The answer is that 'it depends'. However most of the time, it will be accurate to within 5m, and worse near buildings, tall trees, or undercover. You can read more about this here.
High-end GPS systems use a variety of augmentation methods to provide additional information to correct errors, and increase the accuracy. Such systems can be complicated, and costly. What this means is that we cannot reliably reduce the position error on our devices below a few metres on every fix. (Many positions given will be accurate to within a few metres in good conditions).
It is important to note that despite our devices doing all they can to filter out innacurate fixes (they will not accept fixes outside of set accuracy limits) incorrect speeds and locations can still in rare circumstances be returned. Common causes of inaccuracy are:
- Satellite signal blockage due to buildings, bridges, trees, etc.
- Indoor or underground use
- Signals reflected off buildings or walls ("multi-path")
Particularly in the multi-path scenario, the device has no way to know that it has received a signal which has bounced off a wall, tall building or similar. As far as it is concerned, this fix is correct and accepted. All filtering the device is done is based upon the position accuracy estimate reported by the GPS module - which is not infallible.
How devices acquire fixes
Acquiring fixes is handled by the GPS module on the device. Our device firmware decides when the device should attempt to get a fix, and what it should do with that information. The information returned by the GPS module is
- Position (Lat/Long)
- Position accuracy estimate
- Speed Accuracy Estimate
When not in trip - hard-wired devices will turn on their GPS each heartbeat to download new aiding data - which helps acquire subsequent fixes faster.
When in trip - the GPS module is turned on and left on for the duration of the trip. It acquires second by second location fixes and calculates the speed the device is travelling and heading.
Battery Powered Devices
Behaviour in and out of trip is the same - however the logging interval is increased when in trip. When acquiring a fix, the device turns on the GPS module - which attempts to get second-by-second fixes. The device will simply logs a 'valid' fix. A valid fix is one that is within the accuracy bounds set in device parameters (see following sections). As soon as this valid fix is achieved, the GPS module will discard a set number, then log the next one. Then the GPS is switched off and the device again sleeps until the next scheduled fix/upload. If it can't find a fix for some time, it will eventually timeout after the GPS Fix Timeout Period. Slight variations to this behaviour are possible depending on the specific device and parameter setup.
This behaviour means often if the GPS had remained on a bit longer, it could have found a more accurate fix - but it simply takes one that is 'good enough' according to parameters - which leads to the optimum battery life. For most applications, we don't need 2 or 3m accuracy, 10-20m will suffice, and we need the longest battery life - so the device operation supports the excellent battery life seen with our devices.
General notes and trade-offs
How accurate a fix must be before being accepted is configurable (as per following sections). If the accuracy requirements are tightened, the impact is
- The device may need to keep the GPS on for longer to wait for a suitably accurate fix. This uses more power - reducing battery life on battery powered devices
- If thresholds are made too tight, the device may be able to get a GPS fix - but the device will never log it if it is not within the accuracy bounds set in parameters. So the end result is the position on the server will never update
Loosening fix requirements in general means fixes will be easier to obtain, and battery life is saved, but the reported and actual positions may be off by a greater amount.
In general, for the majority of applications GPS settings should not be adjusted and left on defaults. Each device is already pre-configured with sensible defaults for the most common use-cases and applications. Many parameters are made available to allow the operation of the GPS module to be adjusted to suit niche use cases. However you may need to tweak for specific requirements, or if the GPS is not performing optimally in your application.
On battery powered devices, a key parameter is the GPS Fix Timeout.
It may be in slightly different parameter sections depending on the device. This article refers to cellular devices, but our Sigfox and LoRaWAN devices generally have similar parameters, which can be configured to replicate the behaviour of the cellular devices. These are discussed in the individual device articles.
The following parameter tab is available on most devices.
- PDOP, Position & Speed Accuracy:
- These settings allow you to configure the minimum accuracy accepted for a fix. The PDOP is a measure of how imprecise a GPS fix is. This is due to the satellites that are used being too close together to triangulate effectively. Please note that values lower than 2.0 for PDOP will be difficult to achieve in practice. Default Position Accuracy is 50 metres.
- Static Hold:
- If a device is measured to be going less than this speed, it will set it to stationary and it's position fixed.
- GPS Model:
- This selects a statistical module used by the GPS hardware when filtering out noise during GPS fixes. Generally choose Automotive. This is a setting which the uBlox GPS module allows us to set, their documentation does not provide specifics on exactly how it operates
- Require 3D fix:
- A 3D fix requires at least 4 satellites to be achieved, and will return an altitude. Setting to no can help in acquiring a fix in poor signal environments, as only 3 are required for a 2D fix.
- Discard First N Fixes:
- This option discards a configurable number of valid fixes from the GPS before accepting a final fix. This gives the GPS some time to improve its accuracy, and lowers the chance of outlying GPS fixes slipping through the filters.
- Fix Fail Flag Timeout(s):
- Time in seconds of no GPS fix after which the fail flag will be set on the declared Digital Input
Notes on Dilution of Precision (DOP) And Specifically PDOP
DOP is a description of the purely geometrical contribution to the uncertainty in a position fix and has a number of specific applications. Some examples are PDOP, GDOP, HDOP, VDOP, TDOP and RDOP.
DOP is a function expressing the mathematical quality of solutions based on the geometry of the satellites.
Position Dilution of Precision (PDOP) is the most common and we use it as a useful indication of the uncertainty of the 3 dimensional position (3 coordinates) - i.e. how accurate do we expect the position to be?
PDOP has a best case value of 1, with higher numbers being less accurate. A low number of PDOP (2) is good, a high number (typically > 10) is considered to be bad. The best PDOP would occur with one satellite directly overhead and three others evenly spaced about the horizon.
PDOP could theoretically be infinite, if all the satellites were in the same plane. Most Digital Matter devices have a parameter for the maximum PDOP value to consider for a valid fix. This is generally a high value as default and you can 'tighten' up this parameter if needed. Note that this might mean that position fixes take longer resulting in higher consumption of energy which might impact on battery-powered devices, so it is a trade-off between accuracy and battery usage.
Further Reading on GPS: For more info on the details of GPS performance see this article by UBLOX
Advanced GPS Settings
The purpose of these parameters is to cater for certain use cases. The idea is that the GPS Fix Timeout (Coarse Timeout) can be increased, increasing the chance a fix can be obtained in tough signal environments. The issue with increasing this timeout is that if the device still cannot get a fix, it has just spent the entire timeout with the GPS on, wasting power, for no gain. The Advanced GPS Settings parameter tab allows the device to give up early if the signal it sees from the satellites is weak early on. Reducing the wasted effort.
- Satellite Detection Margin
- (-16 to +15 dB) This option adjusts the signal levels required for the GPS signal validator, described below. Setting it higher than 0 requires that GPS signals be stronger, setting it lower than 0 allows them to be weaker, without the signal validator giving up on a fix attempt. The default is 0 - just strong enough to work.
- Nth Satellite Timeout
- (0-1275s) These four numbers are timeouts for the GPS signal validator. The signal validator augments the GPS Fix Timeout. While the Fix Timeout is a hard deadline for a fix to succeed, the signal validator looks at the signal strength, and gives up early if the signal is too weak to expect success.
The validator is configured with four timeouts, which are the time allowed for the acquisition of the first four suitably powerful satellite signals. For instance, values of (60, 50, 40, 30) would require one strong satellite before the 60s mark, two strong satellites by the 60+50=110s mark, three by the 150s mark, and four by the 180s mark. Setting the first value to zero disables the feature. The defaults are all 1 minute. Setting the first value lower than 45 seconds is not recommended. Like the GPS Coarse Timeout, 35 seconds is an absolute minimum.
Initial Satellite Strength Configuration
These additional parameters are available on the GPS Settings Parameter tab for the Oyster2 and Yabby GPS. They were added to suit a specific use case but may have other applications outside of this.
The idea of these settings is that we can configure the device to be more certain that the fix it accepts is valid, by requiring minimum numbers of satellites and that the signal strength is above a threshold.
- Require 3D Fix:
- This requires that a position fix use 4 satellites, and calculate a height as well as latitude and longitude, before being considered valid. It is recommended, as using only 3 satellites gives less redundancy in the rare event of a satellite failure, increasing the risk of a position fix giving an erroneous result. However, disabling this option can allow fixes to proceed faster, and in adverse conditions such as urban canyons. The default is Yes.
- Discard First Fixes (0-32):
- This option discards the first few valid position fixes from the GPS module. This gives the module some time to refine and cross-check its estimate, reducing the risk of an erroneous fix in the rare event of a satellite failure. We recommend the default value of 3.
- Minimum Initial Satellites:
- This option allows you to discard all GPS positions until a certain number of satellites have been acquired at a specified signal strength. Like the Discard First Fixes option, this gives the module more time to refine and cross-check its estimate, reducing the risk of erroneous fixes. It is intended for advanced use cases that require very high position certainty (ie. mission critical geofencing). Since it can affect fix times badly, the default is zero (disabled).
- Minimum Initial Signal Margin:
- This is the minimum signal strength for the Minimum Initial Satellites option. Setting it to a low value (-20) makes the Minimum Initial Satellites function simply count the number of satellites in the fix, rather than requiring that they be high power. A value of zero requires a decent signal strength, and 5 requires a strong signal. It is generally difficulty to get more than a few satellites with strong signals, and most benefit comes from acquiring many satellites rather than a few strong ones. So if you really need the Minimum Initial Satellites features, the best place to start is with a low value.
Common Issues and Use Cases
My device location isn't updating - my device can't get a GPS fix
For GPS Troubleshooting steps, see the article here
How do I increase the accuracy of fixes I am getting?
The accuracy requirements for a valid fix can be tightened by lowering the following values:
PDOP, Position Accuracy, Speed Accuracy.
Going too low can result in the device not logging a fix at all, and battery life will be reduced. It is often useful to increase the GPS Fix timeout slightly as well in this case. Adjust slowly and test on a few devices to double check. For example try:
- Lowering PDOP to 4.0
- Lowering Position Accuracy to 35 or 40m
- Lowering Speed Accuracy Requirement to 5-7m/s
- On a battery powered device the GPS fix time may need to be increased from 60 to 90s
- Performance can be monitored by turning on additional GPS Debugging as described in the GPS troubleshooting article
There are limits to the accuracy our devices can provide - they are not suitable for applications that will regularly require sub metre accuracy. Our devices will comfortably let you know which corner/end/section of the yard an asset is in. They will not reliably and repeatedly tell you the order your cars are parked in if they are all next to each other.
I am getting false over speed alerts
Despite the GPS Settings and filters on accuracy of fixes. Devices can still report incorrect locations/speed.
The Speeding Report has flagged this speeding event, of a vehicle travelling at 171 km/h! This is quite severe. It may not be accurate. We can assess it's validity by viewing the telemetry for the asset. In TG, Assets -> Telemetry
What we notice is
- The individual record has a high position accuracy, and it has sharply increased from the logs immediately before
- Looking down the position accuracy column this is evident, this log appears to be an outlier
- The same can be said for PDOP - it is quite good (1 is near ideal) - but it suddenly increases at the time of the record in question.
We can be reasonably confident that the speed reading of 171 km/h is incorrect. It was likely due to the device driving through an urban canyon, or tall trees - we can look at the point on the map - and satellite view to see if we can spot anything.
To prevent future occurrences we can try adjusting the settings to values such as:
I am getting false geofence alerts, my device is registering movement when it hasn't moved!
Typically this can be an issue on battery powered devices, which get a new fix each heartbeat. The first step is to increase the size of the geofence slightly, to account for a small amount of variance in each new position. It should not be set to the exact boundary of a yard for example, rather extend it 50-100m on each edge. Given the default accuracy bound is 50m, a device on the edge of a site could easily register a location just outside and trigger an alert. The geofence needs to account for this.
The next step is to increase the Discard First N Fixes parameter. 5 or 6 is a good starting point. This will reduce the chance of erroneous fixes as described above.
If this does not improve the performance, we can try adjusting the Min Initial Satellites and Min Initial Signal Margin parameters.
With require 3D fix set to yes, the device will look for a fix using at least 4 satellites, if it is within the PDOP, Position and Speed accuracy requirements, it will discard the set number of discards, and then log this fix.
In poor signal environments, this might be done off 4 satellites, with a poor view, and lead to jumps in position. We can try setting such as
To enforce that 5 satellites are used for this fix. Decreasing the chance we get an innacurate position due to receiving poor information from one of them. The margin is set to accept weak fixes - as this is usually when we are getting innacurate fixes, when the signal is weak - so requiring strong fixes could lead to none actually being achieved. As always it is a balance between being super sure of the accuracy of a fix (with strict settings) and missing them entirely - it is up to the user to determine which direction to tip the balance.