- You are here: Home > Understanding Real-time Tracking
You are here
Understanding Real-time Tracking
The solution is only as good as the information it provides.
With all the power GSatTrack brings to any project, there are still some limitations set by the data gathering and reporting capabilities of the hardware that is chosen. There is often a disconnect between our expectations of how technology works and the reality that drives the overall capabilities and success of a project. I will review with you two different ways expectations when compared with realities should define our decisions about tracking devices.
The Definition of Real Time Tracking
Real time tracking is when software actively shows an animated icon moving in real time across the screen - Rideshare apps work like this, but they are actually not providing real time tracking; instead they are estimating possible position data. This is accomplished through the use of algorithms which estimate where vehicles are located on a predefined route between the last position reported by the vehicle and the vehicle's destination. The information is then used to animate in the app where the vehicle should be based on its speed, heading, the defined path and generate an estimated delivery time based on this information. If you have ever been stuck staring at your screen while your rideshare app shows your driver spinning in circles, you've seen first hand why this isn’t always the most accurate solution.
Real time tracking is when a tracking or telematics device sends information across a network in real time and then immediately displays the information on visualization software. Tracked devices rarely have a defined route from one destination to another. This removes the availability of a predefined route for an algorithm to build an animation.
The second reason real time tracking is defined differently than the expectations is because tracking devices all have different capabilities, reporting times, networks, and interfaces. For example, If a tracking device is sending its position once every 30 minutes, estimating which road network a device would take could vary greatly there’s even a possibility the unit took no defined roads at all. Lastly, speed information is not available on all devices. For these devices, GSatTrack will estimate the speed of a device using the formula of distance between two positions and the time it took for the device to travel that distance. This is done in a straight line method, and does not consider road ways. All of these things remove the possibility for animated displays, but rest assured that any information sent from a device containing a position or information is done immediately and in real time.
Alerts are sent the moment that a defined state or behavior occurs. - The expectation is that devices are always aware of their state and will immediately notify GSatTrack of events sent from a tracking device.. SOS and Check In buttons often will immediately initiate an event that will trigger an alert. Movement started and stop events typically also trigger events that will immediately initiate alerts. This behavior is not true of all alerts reported by a device and may vary greatly depending on the device chosen for your solution.
Most alerts are triggered when a device reports its position and is still in the undesired state. Most tracking devices go into a sleep mode between position reports in order to extend the life of the battery. This creates a situation where most devices only report Alerts and Events when the tracking unit also reports its position and is in the state defined in the Alert.
One of the simplest ways to highlight this behavior is an “Enter Geofence” Alert. The expectation is that a device would trigger an “Enter Geofence” alert when it crosses the imaginary Geofence created in GSatTrack. The reality is that for most devices, the “Enter Geofence” Alert is triggered when the unit reports a position inside the Geofence. This means that if a tracking device is set to have long periods between position reports, it is entirely possible for it to go back and forth inside a Geofence without ever triggering an Alert.
This is also true if alerts are set for “Exit Geofence.” If a unit leaves a Geofence, it does not report that it has exited a Geofence when it first leaves the Geofence. Rather, the unit will report it has exited the Geofence when it reports its first position outside of the Geofence. There are several instances where this can have a large impact on the reporting of a tracking device and how it relays information. There are other examples, such as creating a speed alert while setting a unit to report only every thirty-minutes. It is entirely possible for the unit to speed and trigger the threshold but reduce speed again before the thirty-minute position is reported.
Ultimately, because the Alert feature is driven by GSatTrack and not the device itself, the device's reporting interval plays a large role in the triggering of Alerts in real time. Unless the Alert can be initiated from the device itself (via button or forced transmission), it will require a position report from the device that triggers the condition(s) of the Alert in the software.
Clear Communication = Happy Customers
In the end, we want all of our clients to be able to make informed decisions about the technology they want to employ. There is always more involved with a project's decision making process than cost and network when choosing devices to support a project. This is why, first and foremost, GSE has always been a partner for clients to build a solution to meet their needs. We bring technical know-how and a simple way of conveying information so that everyone can be sure we are suggesting a device and reporting interval mix that meets the specific needs of each client to ensure success. Reach out to our sales team today for additional information about building the right data ecosystem for your project.