Our battery powered devices are great for 'slap and track' applications as they do not require any wiring or complicated installation. This article discusses using battery powered devices to track run hours and odometer values on assets.
In general, hard-wired devices have the benefit of having a constant power source, so we can sample and upload more frequently. This usually leads to more accurate readings.
TABLE OF CONTENTS
Run Hours
This is the number of hours that an asset has been actively operating. Traditionally, for a hard-wired device, it is calculated by wiring in a digital input to an ignition source (i.e. the ignition line on our powered devices). When the engine/asset is running, the input will detect this, and we can calculate the run hours based simply on the time the ignition is on. We are tracking via a physical input.
On a battery powered device, we can process run hours on the server in the same way. However we aren't relying on a physical ignition input. We must 'emulate' the ignition. When our battery powered devices detect they are on the move, they will start a trip, and set their ignition digital input (Digital Input 0) - active. Trips can be started based on:
- GPS movement. If we move a set distance (default >250m) away form the start point, start a trip. So if we're doing small laps back and forth in a yard, we aren't in trip accumulating hours.
- Accelerometer activity - if vibration is detected - i.e. engine/pump running (even in a fixed location) - start a trip and accumulate hours. (Recommended tracking mode) - we refer to this as "Jostle Mode"
For more detail, see Battery Powered Devices - Overview of Operations.
It is best to use jostle mode for run hour monitoring. If we use GPS movement to start/end trips - we will not be accumulating run hours on small movements.
Set Up/Parameters
Setting The Accelerometer Wake-Up Threshold
An accurate configuration of the sensitivity of the accelerometer is crucial to ensuring an accurate run hour incrementation. The Wake-Up threshold can be set to a value 1-8 which corresponds to 63mG - 504mG (in 63mG increments). The user would need to test which value is best suited to the asset on which run hours are being tracked.
Usually defaults are fine. If defaults result in too many false wakeups - just set the Wakeup Threshold and Wakeup Count to 2 and 1 as the next test.
Other Parameters
Depending on the application, we may want to adjust other device parameters.
For example, consider an Oyster2, tracking run hours on a stationary pump. The default logging parameters on the Oyster2 can be found in the getting started guide and are:
- Out of Trip: 12 hour heartbeats. This is a GPS point and an upload every 12 hours.
- In Trip:
- Start trip threshold of 250m
- Upload on trip start.
- GPS points every 2 minutes
- Upload every 30 minutes.
- End a trip after 5 minutes of no movement.
- Upload on trip end.
Changing the device to "Jostle Mode" will simply mean that accelerometer activity will begin/end trips (rather than GPS movement). But we will still get GPS positions every 2 minutes, and an upload every 30 minutes, which for a stationary asset, is likely unnecessary and a waste of battery.
For the longest battery life, to track run hours all we really need is start/end of trip logs sent to the server. So we can disable/reduce other updates.
Examples - Jostle Mode, 12hr heartbeat, upload only on start/end of trip
On the Yabby GPS and Wi-Fi, we are lucky as this is the default. The Yabby GPS however will get a fix every 15 min while in trip. So we can set this parameter to 0 to disable that if we wish.
On the Oyster2 and Remora2, once we have set Jostle Mode on, we can disable in trip uploads.
We cannot completely disable in trip fixes, but we can set it to the max allowable value which is 7620 sec = 127 minutes. We should not set the logging period this large unless we are in jostle mode. Or trip ends won't be detected properly (the device checks for movement between in trip fixes to decide when to end the trip)
It should be noted that disabling uploads during a trip may result in the device not checking in for long periods of time, if our trips are very long.
Odometer with Battery Powered Devices
To get an accurate run hour reading, all we need is the trip start/end points to be accurately determined, which jostle mode can handle with ease. For accurate run hour readings, things are more complicated.
What is the 'correct' odometer reading?
Most end users will expect the odometer reading given by the device and tracking platform to match the one on their vehicle's dashboard. However who is to say that value is 100% correct? The odometer reading here is determined by counting wheel revolutions, and assuming a set wheel size for the vehicle. If we get different tyres, they are not fully inflated, or the tolerance of the sensor is out by a bit, so will the odometer reading.
Additionally, below are the Australian regulations for speedometer/odometer accuracy, plenty of other countries are similar:
- The speedo must not indicate a speed less than the vehicle’s true speed or a speed greater than the vehicle’s true speed by an amount more than 10 percent plus 4 km/h. So if you're doing 100km/h - your speed can read 114 and be compliant!
- Odometer accuracy is no longer defined.
So even the odometer reading might not be 100% accurate. So it might not match even a hard-wired GPS! There is the potential the GPS is more accurate than the vehicle!
How do GPS Devices and Platforms calculate the odometer value?
While in trip, our devices will sample more frequently. We take all the points of the trip, calculate the distance between each of them, and add it all up. So accurate readings rely on logging enough GPS points within a trip. On a hard wired device, we can log often without needing to worry about battery life. In addition to logging every 60 seconds when the ignition is on by default, our devices will detect heading changes - so we can log additional points when going around corners, so the path plotted will follow the road, and our ODO calculation is accurate.
However if we're travelling down a perfectly straight road in one direction, sampling all the time doesn't add any more accuracy.
Where battery powered devices end up out of sync is going around corners. Consider a device sampling every 10 mins, if we do a lap around the block that takes 10 mins, the odo reading will be 0 - as the 2 points taken will be in the same spot. So we need to make sure we're getting GPS positions off enough to avoid situations like this.
Set up and Considerations
Often, certain applications mean we simply cannot install a hard wired device - but we still want to track the odometer. It can be argued that a reasonably accurate value (even if not perfect) - is better than no tracking at all! Many of our partners make use of battery powered devices to track odometer readings, and are more than happy with the results! In fact it is great for scheduling servicing for assets like trailers - which are unpowered, and have no other method of tracking the distance covered.
Rules of thumb:
- Ideally we need to log GPS points in a trip at least every 5 minutes. 2 min is the default for the Oyster2 and Remora2. We don't have to upload frequently (but we might want to for other reasons)
- Expect 90 - 95% accuracy, depending on the sort of driving (city, lots of corners vs straight roads i.e. longhaul trucks)
- We need to balance this with battery life - we can use the calculators here Battery Life, Battery Capacity Estimate & Low Battery Flag. The Remora2 is best for aggressive tracking rates.
Battery Life:
Consider an asset that drives 4 hours per day, 5 days per week. We use the default tracking settings (2 min GPS logs, 30 min uploads) - we would get over 3 years on the Remora2! Or about 6 months on the Oyster2. 