Our battery powered and hard-wired devices can detect trips based upon GPS movement. Once a trip is detected the device will upload more frequently, and report that it is in trip to the server.
See Battery Powered Devices - Overview of Operations and Wired Devices - Overview of Operation for a quick run-down of how trips are detected and the device behaviour.
One of the available parameters for movement trips is Assumed Start Point Range. Default of 10 000m for battery powered devices, and 2000m for hard-wired.
It is useful to understand the function of this parameter. As evident in the parameters - there is a movement threshold to begin a trip. In the above the device is set to require 250m of movement across a few GPS samples (details in the overview articles) before a trip is started. This prevents false trip starts occuring based on small amounts of GPS 'wander'. Given fixes have a margin of error, each lat/long detected is slightly different from the previous by a few metres. Technically, this would constitute 'movement' (we've changed locations) so we have to put a bit of a filter on it - in reality the asset won't be moving.
This has the effect that the device won't decide that it is in a trip until it has crossed this trip threshold (250m). If we were to plot the trip start point on the map, it would be 250m away from where the previous trip ended. In reality this doesn't make much sense! If we are driving a car, we start the next trip from where we parked at the end of the previous trip.
The assumed start point parameter means:
- When a trip ends, the device stores this end location lat/long
- Trip detection is discussed in the overview articles, but briefly the device will be woken on accelerometer movement. Say this happens at Time A
- If it actually moves somewhere, once it crosses the movement threshold the device begins a trip - call this Time B
- The device sends these 2 logs
- Time A - Start of Trip - Lat/Long is the previous end point
- Time B - Distance Travelled - Lat/long of this point
Given we weren't actually in a trip at this point - this will just be a straight line segment. Powered devices won't be detecting corners etc as they usually do in trip.
A trip ends at this point - with log reason end of trip.
This is the beginning of the next trip. The trip was detected at 17:32:34. But because we are close enough to the previous endpoint, the Start of Trip Log is sent, with the lat/long of this endpoint. Without this feature - the trip would be starting at the point shown with the "Distance Travelled" Log reason.