Applies to:

Our hard-wired devices make use of clever firmware features to avoid 'GPS Wander' outside of trips, such as when an asset is parked. 

The majority of users will not require any adjustment to settings as the defaults work well for most use cases.

Heartbeats and GPS Fixes

If not in trip, and no other uploads occur (i.e. for example a vehicle is parked overnight) - by default the device will send a Heartbeat upload every 60 minutes. 

Behaviour is as follows:

• Device ends it's previous trip (i.e. ignition is turned off) - it will acquire a fix and log the position AND timestamp of the fix. 
   
• When not in trip, any tiny amount of accelerometer activity will trigger a GPS fix, and the device will compare these fixes to see if any movement (above the threshold set in Movement Trips) has occurred that warrants a trip start.
   
• Additionally, every 2 hours, the device will turn the GPS on and leave it on for 5 minutes, to 'freshen' the GPS - downloading new aiding data to speed up subsequent fixes. 

So what this means is that the device effectively has 2 distinct locations in memory

1. The last logged fix 
    
2. The most recent GPS fix

Example

So in context, consider this example:

• 1000 - Device ends a trip and acquires a fix. It sends this data to the server;
  • GPS Time = 1000
  • Lat/Long = -31.947517,115.819913
  • This is the last logged fix
     
• 1020 - Someone gets into the car to grab something they left, which generates some accelerometer activity, triggering the device to get a new fix. It gets this fix 15m away from the trip end point, but it doesn't constitute a trip, so there is no need to log it. Instead this is the most recent fix. 
   
• 1100 - 60 mins passes, next heartbeat occurs. The GPS isn't turned on for a heartbeat, On the latest device firmwares, the device will send the following to the server.
  • GPS Time = 1020 (time of most recent fix)
  • Lat/Long = -31.947517,115.819913 (location of the last logged fix)

So in this way, the device's position doesn't constantly 'bounce' around - but we can still determine when a fix has failed.

Why do this? Why not get a new fix and upload this point every heartbeat?

This firmware feature is to 'Suppress GPS Wander' - and leads to better performance in the majority of applications tracking vehicles. Given every GPS fix has a position accuracy which is not perfect, if we sent a brand new fix to the server every single heartbeat, it might look like our asset is moving around the parking lot! Since each fix might be say 10-30m away from the previous. In reality we know this is not the case, so we filter out these small-scale movements.

Special Cases

There are some scenarios where we want to get a brand new fix every single heartbeat, even if we have moved a small amount. One use case is in tracking a boat. Boats may drift slightly on their moorings, maybe as little as 20m, quite slowly. This would not cause a Trip Start. So we may want the position updated every heartbeat, perhaps to trigger Geofence alerts etc. For this, we can set Suppress GPS Wander = No (default is Yes) in the parameters. This will cause the latest successful GPS fix's position to be sent on each heartbeat.

In a marine application, due to near-constant accelerometer activity (due to the bobbing of the ocean) - the device will have it's GPS on near constantly, acquiring many fixes. So when a heartbeat is logged, it will use the most recent fix time and position - which will essentially be the same time as the heartbeat.