How the data from trackers reach the Navixy platform
At Navixy, our mission is to empower businesses by providing them with the tools they need to closely monitor their vehicles and assets. Our main priority is getting trackers' data and transferring it to businesses with valuable telemetry insights.
The Telematics platform's core of the ecosystem are the trackers, compact devices outfitted with GPS receivers, sensors, and communication modules. These devices are designed to be deployed across various vehicles, where they can collect a wide range of information, including the vehicle's location, speed, fuel consumption, and engine diagnostics.But their utility doesn't stop with vehicles. These trackers are also perfect for monitoring cargo, tracking the performance characteristics on a construction site (Fuel generators, crans etc.), and even overseeing your pet by attaching the tacker to the collar. Essentially, trackers act as the sensory and informational backbone of the telematics system, ensuring that businesses have all the data they need at their fingertips to make informed decisions.
Subsequent to data collection, trackers relay information to the telematics platform using wireless communication technologies. Widely utilised communication methods include cellular networks such as 2G, 3G, or 4G, which are favoured for their extensive coverage and rapid data transfer rates. Satellite communication ensures a consistent data flow in areas with limited cellular coverage or remote locations.
Although it's described as a GPRS connection with specific commands, it essentially utilises cellular or mobile internet connections. The process of transmitting telematics data involves several key steps:
- Initially, the GPS tracker gathers location information from GPS satellites.
- The tracker then converts this information into structured packets following manufacturer-specific protocols, assigning each data item to a specific field.
- Next, the device communicates with a GSM base station, sending the encoded data to the Navixy platform. This includes essential details like the IP address and port of the Navixy platform. The first message typically introduces the tracker, requesting permission to transmit data to the specified IP and port.
- The GSM base station forwards this message to the platform, which, after confirming the device ID is registered with the provided IP and port, communication begins.
At this stage, a link is created between the device and the platform, highlighting that the platform cannot initiate a connection to the device; the process must always start from the device side.
The subsequent phases in transmitting telematics data include:
- Once a connection is established, the device sends a packet filled with telematics data to the platform, which acknowledges receipt. This ensures the device knows the data has been successfully transmitted.
- On the platform side, specific handlers for different ports process the incoming data. These handlers understand the protocols and how to process data from various tracker models, decoding information such as latitude, longitude, speed, and fuel levels.
- The platform can recalibrates the data and organises it systematically in a database if needed.
- Finally, various user interface components retrieve and display the data in a user-friendly manner for end-users.
This clarifies the complex communication process between the platform and the device. But how can you know the status of this connection?
Importance of connection state
Understanding the correct connection state is essential in navigating this complex communication process between the platform and the device. This is where Customisable Timeout settings come into play. These settings address a common challenge faced in asset tracking and management systems, particularly in sectors like Construction, Automotive Sales, and Car Rentals. They mitigate false alarms, ensuring accurate operational status and security alerts within the Navixy ecosystem.
In Navixy, our product team is faced with use cases in which the fixed default value of connection timeout of 10 minutes for switching from Online to Offline was unsuitable for some of our customers. According to the old logic, the Green indicator came on after a recently connected device updated its location with valid coordinates and time. Then, after 5 minutes without receiving any data, the blue status came on. If the device did not connect or send valid coordinates and time, the Red indicator automatically came on as offline status.
Old logic for changing Connection status
Construction Sector Use Case
Wired trackers are installed on fuel pumps and are required to maintain a continuous online presence to respond immediately to automatic GPRS commands issued by managers. Previously, if the Wired trackers were configured to send their data within 10 minutes, they were deemed offline after 10 minutes, so automatic and semi-automatic control within GPRS commands wasn’t available during offline status. Managers were supposed to wait until the device woke up and send data to the platform to be able to operate with a fuel pump.
Construction Sector Use Case
For operational efficiency, stationary energy generators are outfitted with wired trackers that relay crucial operational data daily. Although these trackers are programmed to communicate with the server once every day, the high cost associated with network traffic means they are marked as offline if no data transmission is detected within a default 10-minute window. This discrepancy means that while the device is actually online and functioning as intended, it is registered as offline in our monitoring system due to outdated packets of data, GPS/Time etc. Maintaining an accurate, true connection state is crucial for an uninterrupted power supply and for facilitating the early detection of potential equipment breakdowns.
Car Rental Service Use Case
Car Rentals usually install dual tracking systems in vehicles for enhanced security measures. The main tracker updates the server every 10 minutes, ensuring constant monitoring. A secondary tracker only sends updates once every 24 hours, which helps the longevity of the battery. In theft situations, it's critical to maintain a continuous connection to shift the tracker swiftly into a high-frequency update mode. The stealthy asset tracker is updated only once daily. After a default timeout of 10 minutes, it will be considered offline. Also, it couldn't receive GPRS commands to switch tracking modes quickly, undermining its effectiveness in emergencies.
Based on all user cases, we decided to implement a "Customisable Connection Timeout" feature. This innovative functionality empowers clients to configure device timeout settings in alignment with their specific operational requirements, thereby augmenting control and efficiency in device management.
Also, we got feedback from our customers that the Blue indicator confuses users, and that's why we decided to change the blue indicator to a green indicator with a white outline, which means the same logic that GPS has not been updated.
Recent update: The change in statuses from Blue indicator to Green-GPS hasn’t been updated
How statuses work on the Navixy platform
In the "Customisable Connection Timeout" feature, we address challenges in displaying accurate connection states. This new functionality allows clients to adjust device timeout settings according to their unique operational needs, enhancing control and efficiency in device management. But before we talk about the feature, let’s better understand how connection states display. We have the following status breakdown in Navixy:
- Not activated:
The device was added to the system but has not yet been connected. Awaiting initial server connection. - Connected and Visible:
The device is actively connected with fresh location data (e.g. clear sky conditions with strong GPS signals) - Connected, but Invisible:
The device is connected but has outdated location information. This is common in areas with poor GPS reception, like underground parking, though GSM connectivity remains stable. - Connection lost:
The device’s data connection is interrupted. Unable to transmit location or date to the server.
New logic for changing Connection state’s
The sequence of connection state is as follows:
- The device transitions between “Connected established” and “Connection lost” statuses based on the received packets:
- When the device sends a packet with accurate coordinates and time, it's considered “Connected”, shown by a green light.
- If the device sends a packet with incorrect coordinates or time, it becomes invisible with the status “Connected, but Invisible” (indicated by green with white outline).
- The transition from “Connected, but Invisible” to “Connection lost” occurs if no further packets are received during the connection timeout:
- After achieving the “Connected” visible status, if 5 minutes elapse without updates, the device will shift to the “Connected, but Invisible” status to account for location uncertainty.
- After the specified connection timeout minus 5 minutes, the device transitions from “Connected, but Invisible” to “Connection lost”.
To understand this logic better, please get familiar with the example below:
When a vehicle enters a tunnel, it loses its GSM connection, causing the device to transmit messages with valid GPS coordinates before entering the tunnel. After driving for 5 minutes without a satellite connection, the device sends messages without valid coordinates inside the tunnel. It automatically switches its status from “Connected and Visible” to “Connected, but Invisible”. If there is no GSM connection, the tracker cannot send data to the platform. The device is marked “Connection lost” after a set connection timeout (e.g., 60 minutes) without data transmission. Once the vehicle exits the tunnel and reconnects to GSM and satellites, it sends a new packet with valid coordinates, returning to the "Connected and Visible” status.
Illustration of example with vehicle in a tunnel
How to customise connection timeout status on devices
Adjusting the connection timeout settings for your devices is an easy task that can be done in a few simple steps. Here's how to customise these settings to fit your needs:
- Go to the "Devices and Settings" area within the user interface.
- Pick the device for which you want to modify the timeout settings.
- Look for the "connection state" section and select your preferred timeout duration, which can vary from as short as 1 minute to as long as 3000 days, based on your specific needs.
- Once any changes are made, the platform will alert you to unsaved modifications. Make sure to save these adjustments. Your new timeout settings will be applied right away.
- If you want to uniformly adjust the connection timeout for multiple devices at once, simply use the copy feature. After clicking the copy button, choose the target devices and apply your preferred timeout settings to them all in one go.
- For users inclined to revert to standard settings, the "RESET TO DEFAULTS" button lets you quickly set the timeout to its original configuration.
Benefits of connection timeout settings tool
Experience a new level of control with our latest feature, granting you unparalleled authority over device timeout periods. Move beyond the standard 10-minute limit and customise timeout settings precisely, aligning each device with exact operational needs.
- Define timeout periods according to your operational rhythm, creating a finely tuned system that mirrors real-time operations. This ensures that device statuses are in sync, optimising overall efficiency.
- Say goodbye to unnecessary checks and maintenance with reduced false offline status alerts. Our feature keeps you informed without inundating you with needless notifications.
- Enjoy a seamless, user-friendly experience as you tailor configurations to meet the unique demands of your operations.