Car Mileage: Why Do GLONASS and Odometer Differ? Part 2. Dataset

_

But conducting hundreds or even dozens of such experiments is problematic, at least because the technology is intended for targeted use, and not for experiments within the framework of business relationships.

Therefore, we will try to conduct a study on anonymized data from real vehicles of the southern infrastructure geozone of the Waliot fleet management platform. The south was chosen for several reasons: firstly, it is the largest Waliot cluster in terms of the number of its own monitoring objects and, accordingly, telemetry; secondly, here we will be able to assess the impact of electronic warfare and roads with significant elevation changes (passes and serpentines).

In order to estimate the mileage error by the odometer and GNSS, we will need telemetry from cars that transmit this data to the SMT. The mileage by satellites can be calculated based on data from navigation equipment. But with the odometer value it is more difficult, since obtaining data from the standard odometer of the car requires access to the on-board electronics of the car. 

Run by satellites

Transport telematics from the data point of view is a telemetry storage in the form of time series with a reference to a specific monitoring object and the time of recording data about this object. Any navigation device, including a car tracker, can be divided into the following components:

• Microcontroller with control program (firmware). This component is responsible for controlling all other components of the device and ensures correct operation of the equipment.
• GSM module with built-in or remote antenna. Almost all modern trackers use publicly available cellular communications (GPRS, 3G, LTE) to transmit data over the Internet to the telematics server. Therefore, transport telematics can be classified as the Automotive IoT.
• GPS module with built-in or remote antenna(s). High-quality modern modules work with several satellite systems at once, such as American GPS, Russian GLONASS, European Galileo and Chinese Beidou. This allows using data from different navigation systems to improve the final result of determining the location.
• “Black box” — internal memory as a temporary buffer for storing telemetry until the data is successfully sent to the telematics server. Most often, this is a regular FLASH memory soldered directly to the board, or a slot for a MicroSD card. The buffer accumulates telemetry while there is no cellular communication, and as soon as the object enters the coverage area of ​​the mobile operator’s network, the data is sent to the monitoring system.
• External interfaces for connecting additional sensors. In addition to collecting GPS data, car trackers are also designed to collect readings from all kinds of peripherals: fuel level sensors (FLS), temperature sensors, tilt angle sensors, and much more.

It turns out that from the car tracker via the Internet we receive telematics packages to the SMT server with GPS data (current coordinates, speed and direction of movement, and technical information about the conditions for solving the navigation task) and optionally with readings from additional sensors (voltage at analog inputs, value of digital outputs, temperature readings, etc.), which include the CAN bus. 

Additionally, it should be noted that equipment from different manufacturers operates using their own communication protocols. Most often, this is a binary protocol with data transmission via TCP/IP. There are also universal protocols, for example, the EGTS interserver interaction protocol (GOST 33472-2015), which is supported by most modern navigation devices certified for use in Russia.

Electronic warfare and satellite jamming

Electronic warfare (EW) and jamming of navigation satellite signals play a significant role in determining the accuracy of GPS/GLONASS tracked vehicles and can significantly impact the operation of vehicle monitoring systems.

Electronic warfare is a set of measures and technical means aimed at influencing enemy radio signals and systems to achieve tactical and strategic goals. The main goal of electronic warfare in relation to navigation systems is to disrupt or suppress the operation of satellite signals. This may include:

• Interference with navigation signals: installing jamming devices or objects that make it difficult to receive the signal.
• Navigation data corruption: creating false coordinates that lead to disorientation, also known as spoofing.
• Creating blackout zones: Blocking GPS/GLONASS signal transmission, creating “gaps” in navigation data.

In conditions of active satellite signal suppression, GPS receivers on vehicles may lose contact with satellites, which leads to jumps and losses in the calculations of the distance traveled. This affects the mileage data, and the actual distance traveled may differ from that recorded by the system.

In multipath conditions and when the signal is distorted, it is possible to obtain incorrect coordinates, due to which the route traveled by the car may appear broken or cut off on the map (“unwinding” and “flights”), which will lead to an overstatement or understatement of the mileage. For example, spoofing with the substitution of real coordinates for artificial circular trajectories is currently an acute problem in transport monitoring.

To minimize errors and increase the accuracy of mileage calculations in conditions of possible jamming, you can use filtering and data combination. Using algorithms that analyze data for anomalies and exclude “noise” caused by sharp jumps in coordinates. It is also worth noting that modern car trackers have the function of detecting jamming of GSM and GPS signals and transmit this information to the telematics server, so the use of Chinese jammers in the cigarette lighter by drivers is usually quickly detected.

Mileage on odometer

With odometer mileage it is easier from the point of view that the car itself calculates it for us, but there is a difficulty in obtaining this value with the equipment and transmitting it to the telematics server along with GPS data. Here are several basic methods that allow you to obtain odometer readings:

1. Via OBD-II connector. OBD-II (On-Board Diagnostics) is a standard diagnostic connector that is equipped with almost all modern cars. With OBD-II, you can read many parameters of the car, including mileage, if this parameter is available through the diagnostic system. A special telematics module that supports OBD-II is connected, and a request for odometer data is made via standard protocols (for example, ISO9141 and KWP2000). Such data can be read in real time and transmitted to the telematics server.
2. Via CAN bus. CAN (Controller Area Network) is the vehicle’s internal network through which data is transmitted from various sensors and systems, including the odometer. The telematics module connects to the CAN bus and reads messages that transmit odometer readings. Typically, such devices must be programmed for specific vehicle models in order to correctly interpret the data.
3. Through standard telematics systems. Many modern cars are equipped with telematics systems, such as OnStar, Ford Sync or Mercedes Me, which collect data on mileage and other vehicle parameters. Telematics systems collect data directly from the vehicle’s on-board electronics and transmit it to the manufacturer’s cloud services. Some systems allow integration with external applications via API, which can provide access to mileage data.

Using OBD-II or CAN bus are the most versatile approaches to reading odometer data. If deep integration is required, it is worth considering CAN bus, especially for large fleets where full automation is required. You can learn about setting up CAN bus reading  using Navtelecom equipment as an example at the link . 

Preparing the test dataset

Connecting a car tracker to a CAN bus is an option when providing transport monitoring services. Sometimes a business simply does not need this data, or the company is not ready to pay extra for connecting and configuring a CAN reader. In addition, modern special equipment uses several independent CAN buses, each of which must be connected to separately. There are situations when it is simply not possible to connect to a CAN bus, since a special configuration of the CAN reader is needed for operation, which, listening to the vehicle data bus, will know at what network address what data and in what format is transmitted. There are also warranty conditions that do not allow connecting to a CAN bus, since this can be regarded as interference with the operation of the vehicle.

Therefore, from the entire set of monitoring objects, we should select only those whose CAN reader is configured to receive mileage data from the odometer. It is worth considering the fact that additional telemetry from the equipment may not be received in every thematic package. For example, a CAN reader cannot receive data from the CAN bus if there is no mass on the car, and it also requires some time to start reading from the bus after turning on the ignition. Therefore, we will additionally calculate what proportion of all packages for each object contained odometer data – this can become an additional factor in selecting our dataset.

Let’s analyze all telemetry for 2024 in the Waliot database in the Southern Federal District. Let’s calculate the number of telematic records for each monitoring object, both in total and with the mileage value by odometer, and also calculate what percentage of the tracker’s telematic records contain odometer readings via CAN. Let’s execute the corresponding query on the analytical replica of the main database and save the result in a CSV file  (identifiers and other sensitive data are replaced) :

After executing the request, we get  the can_mileage_counters_2024.csv file  with more than 20 thousand lines. These are monitoring objects that sent telemetry at least once in 2024.

Let’s count how many trackers sent odometer readings via CAN bus, at least once:

Total 669 trackers. This is by the way about the fact that connection to the CAN bus is a complex process and remains at the discretion of each Client as an optional service for transport monitoring. But for analysis, we should take objects that send odometer readings quite often. Let’s look at the distribution of objects by the frequency of sending data from the odometer to the total number of their telemetry:

From this we can conclude that if engineers set up a connection to the CAN bus, it works without problems in most cases. And vehicles that send the odometer in telemetry every other time are sent to our technical support for verification 😉 For our purposes, we will take objects that send the odometer in more than 95% of their packets:

Now let’s estimate the total number of records for each of the objects in our final sample:

The histogram shows that most trackers sent less than 1 million packets in 2024. There is a strange outlier beyond 3.5 million, which most likely indicates a non-standard tracker configuration or a hardware issue – information will also be passed on to the technical department. 

Of course, when calculating the deviations of the runs, we will calculate the average error by objects, so that an object with a larger number of points does not make a greater contribution to the statistics compared to more “economical” trackers in telemetry. But for the sake of purity of the experiment, we will still exclude objects that send more than 1,000,000 packets per year:

This way we get the final list of masked tracker IDs that we will work with:

To unload such a volume of telemetry, we will write a bash script, which we will execute directly on the analytical replica in a separate terminal session via the screen utility:

We get the final file  can_mileage_telemetries_2024.csv  with 194882659 lines and a size of 16 GB. Since CSV is a text file, it is easy to compress. We use gzip with a standard compression level and get a file of 3.8 GB at the output, which is more convenient to transfer over the network:

Let’s look at the contents of our dataset by the columns of the CSV file:

• tracker_id  – artificial tracker identifier
• fix_time  – GPS data fix time in ISO 8601 format
• latitude  – WGS84 latitude in decimal format
• longitude  – WGS84 longitude in decimal format
• altitude  – height above sea level in meters
• speed  – speed of movement in km/h
• course  – direction of movement in degrees (azimuth)
• valid  – GPS data validity flag (determined by the tracker’s internal algorithms)
• satellites_count  – the number of visible satellites when solving a navigation problem
• hdop  – horizontal precision reduction
• can_total_mileage  – total mileage according to odometer from CAN-bus

Data in transport telematics can be divided into 3 main categories:

1. Business data that is related to the subject area and is most often part of the primary key and/or search criteria.
2. GPS data (fix_time, latitude, longitude, altitude, speed, course, valid, satellites_count, hdop), which are formed based on the readings of the GPS module in the tracker.
3. Data from additional sensors. In our case, this is only the odometer readings from the car’s CAN bus. This will include all data from the periphery (external connections).

Let’s go through the fields and analyze each of them. The tracker_id field is the identifier of the device whose telemetry we are studying – I think everything is clear here. The combination of the fix_time, latitude, longitude and altitude fields are the results of the GPS module in the navigation device. It is important to understand that GNSS does not participate in calculating the speed and direction of movement, all this is done on the GPS tracker side, so speed and course are calculated values ​​​​on the equipment side. The number of visible satellites (satellites_count) and HDOP are auxiliary information that allows you to evaluate the accuracy of the GPS data. The valid flag is the result of assessing the validity of the GPS data on the side of the tracker itself, the value of this flag is determined by an internal algorithm, and often the parameters of this algorithm can be configured. Well, can_total_mileage is the actual odometer value in the car, received via the CAN bus.

Since this work is initially devoted to the issue of the discrepancy between the mileage on the odometer and satellite navigation, i.e. about the comparison of errors in these values, we will try to evaluate the dataset from the point of view of errors at this stage.

There is no error in the tracker_id field, since this is the identifier of the navigation equipment.

The fix_time field is the time of GPS data fixation. Time accuracy in GNSS is the determining factor of accuracy, since the distance from the satellite to the receiver is determined by the time delta between sending and receiving the signal. All satellites are equipped with an atomic clock standard. The stability of atomic clocks is about 10^-14, which means that an error of 1 second will be achieved only after millions of years. However, installing an atomic clock in the user’s receiver is impossible due to its incredible cost.

Therefore, GNSS receivers use a quartz generator, the stability of which is 10^-7, and the error is 3-5 seconds per year. To compensate for this, the parameters of the time polynomial are transmitted in the service messages of satellite signals, which are used to bind the receiver’s time scale to the satellite system scale with an accuracy of 20 ns (in geodetic class receivers).

In this work, we use real telemetry from car trackers and cannot influence the error of GPS receivers in any way. Our company actively uses Navtelecom SMART S-2433, the technical characteristics of which can be found at the link:  https://wiki.navtelecom.ru/ru/home/devices/characteristics/s243x . In this tracker, SimCom SIM868E is used as a universal GNSS/GSM/Bluetooth module, a very popular combined solution that is ideal for a navigation device.

The latitude, longitude and altitude fields are obtained as a result of solving a navigation problem based on data from visible GPS, GLONASS and Beidou satellites. We can estimate the error of this data through the number of visible satellites and the value of the accuracy reduction in the horizontal plane.

The accuracy of altitude above sea level is usually much lower than that of latitude and longitude readings. Only according to the passport in ideal conditions we get ±5 meters of error in altitude, in reality the altitude according to GNSS has a much larger spread.

In the next article,  we will try to analyze the altitude readings in our dataset and evaluate the impact of taking altitude into account in mileage calculations in transport telematics.

_

_