Modes of Operation
Digital Matter devices revolve around the concept of 'a Trip' for their tracking, and there are several ways you can commence and end a trip. There are multiple methods of beginning and ending trips; Emulated, Wired, Run detect, Jostle mode and transported trips.
All wired devices are set up for Wired ignition and Emulated ignition by default. So this means if there is no physical ignition connected, trips are still tracked.
Battery Powered Devices
For battery powered device overview of operations click here
On our powered devices with a physical ignition wire G60/62, G100/120, Dart/Dart2, Wired ignition is set up by default for the white ignition wire to set the ignition bit (Digital Input 0, DI0) and start a trip. The Eagle and Falcon units can also use a Digital Input as an Ignition wire to simulate this action.
When over 5V is applied to the ignition wire, the device will begin a trip. It will upload on the beginning of a trip, and turn on the GPS and Cellular modem. It will remain on and upload according to the Logging Parameters.
Emulated Ignition (Movement Based):
(All powered devices)
This mode works in a similar way to "Standard GPS Tracking" on our battery powered devices.
- The device waits in a low power sleep state for accelerometer activity.
- Once woken, it checks the GPS for movement over a period of a few seconds.
- If the GPS shows movement over the start threshold, a trip is started, and the the ignition bit (DI0) is set to Active.
- If this is not the case, the device then resumes sleeping, with both the GPS and mobile data off.
- Once the asset has been stationary for some time, or the GPS signal has been lost for some time, the trip is ended, and a final upload is performed.
This is the primary method for detecting trips on the Bolt (as there is no ignition line). It also means trips where an asset is towed (and the engine is not run) can be detected. (See Transported Trips below).
The gory details:
Movement trip start behaviour is controlled by these parameters:
To begin a trip, the movement and speed thresholds are ANDed together. i.e. we must be over 150m from the start point AND travelling over 15km/h to begin a trip with the above parameters. So very slow moving assets ideally should just have physical ignition hard wired, or be sure to drop the speed threshold.
>>Once woken, it checks the GPS for movement over a period of a few seconds.
In detail, this means that after some accelerometer activity is detected, the device keeps checking for movement until there has been no accelerometer activity for 36 seconds (hard coded), and no GPS movement for the Trip End Time (configurable).
The Movement Count means that we require this many fixes (the device gets a fix second by second) that all agree that the device is over the trip start movement and speed thresholds to begin a trip. Higher values means the device is more 'sure' that it is on the move, and there is less chance that a single erroneous fix will result in a false trip start.
Run Detect will put the device into trip based upon changes in the external voltage. The assumption is that when the engine is turned on, the vehicle battery voltage will increase as the alternator is turned on to charge the battery. In many cases this will work well if a wired ignition is not available. However this assumption does not always hold true. The resting/running battery voltage of a vehicle can change over time, so the thresholds below may need to be adjusted. Modern vehicles are also smart enough to turn off the alternator when the battery is fully charged, and some even will turn off the engine when stopped at traffic lights. For this reason run detect is not foolproof.
In OEM Server, Click on Parameters > System parameters and add the Run Detect tab.
- High Voltage:
- Set this number to be below the average voltage output when the engine is ON so the Run Detect is activated when the engine voltage crosses the value.
- Low Voltage:
- Set this number to be lower than the High Voltage value but higher than the average value when the engine is OFF so Run detect is deactivated when the voltage crosses the value.
- Digital Input:
- To have Run detect activate trip status, set the Digital Input to Ignition (0)
- Start Time(s):
- Amount of time for voltage to register over High Voltage i.e. engine to be running, before trip starts
- End Time(s):
- Amount of time after engine stops i.e voltage to cross Low Voltage for trip to end.
Transported Trips and Idling
If a physical ignition line is wired into a vehicle, it is possible to detect the difference between the device being used (i.e. engine on) and towed (on the move, but engine not running)
In most cases if an asset is going to be towed we do not want to increment run hours and odometer values. Settings for this use case are covered here: Transported Trips - Prevent Towing Incrementing Run Hours and ODO
Idling can be detected if the ignition is hard wired - as the device can detect the ignition line is active, but there is no GPS movement.
Multiple Trip Modes
By default, devices with an ignition input are set to start/stop trips based on both:
- Emulated Ignition (Movement Based)
This provides a good starting point as the device will detect movement if the ignition is not connected as well.
It is important to note however that if a trip starts via one method, it will only end via that method.
E.g. if an ignition trip starts, the device remains in trip until the ignition line goes low.
Heartbeats and GPS Fixes
If not in trip, and no other uploads occur (i.e. for example a vehicle is parked overnight) - by default powered devices 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
- The last logged fix
- The most recent GPS fix
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, it 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 'Supress 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.
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 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.