> For the complete documentation index, see [llms.txt](https://navixy.com/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://navixy.com/docs/expert-center/vehicle-telematics-technology/fuel-management/understanding-gray-zones-in-fuel-level-reports.md).
# Understanding gray zones in fuel level reports
### Overview
Customers occasionally report gray zones or discontinuous lines in Fuel Level reports, assuming that the platform is not processing sensor data correctly. This behavior can create confusion because it may appear that sensor readings are missing or ignored.
In reality, the platform continues processing the sensor data correctly. The gray zones are a consequence of the platform's data continuity logic, which is designed to prevent inaccurate interpolation between long reporting gaps.
This document explains how the platform processes sensor data, why discontinuous intervals appear, and what can be done to minimize them.
### Valid sensor data vs. invalid GPS data
The first concept to understand is that GPS validity and sensor validity are independent.
A location is considered invalid when:
* No GPS satellites are available.
* Fewer than three satellites are available.
* Latitude or longitude equals 0.
Although the location itself is considered invalid, sensor values contained in the same packet remain valid and are always processed.
For example:
Although the GPS position cannot be displayed on the map due to lack of satellites, the value of avl\_io\_9 (Fuel Level Sensor) is still:
* Received
* Stored
* Processed
* Displayed in Fuel Reports
* Used by IoT Logic
In other words, invalid GPS data does not invalidate sensor data.
### Continuity of sensor data
One of the most common questions regarding Fuel Level reports is why the graph displays discontinuous segments, even though the individual sensor readings are present in the report.
From the customer's perspective, this behavior may appear incorrect because the sensor values are visible, yet the graph is not rendered as a single continuous line. In many cases, customers interpret these interruptions as missing data or incorrect processing, when in reality they are the result of the platform's continuity logic.
#### Continuity logic
The platform groups sensor readings into continuous intervals based on the time difference between consecutive records.
When the elapsed time between two consecutive sensor readings exceeds 30 minutes, the platform considers that the previous interval has ended and a new interval begins. Consequently, the graph is divided into independent segments instead of being rendered as one uninterrupted line.
This behavior is intentional and applies regardless of whether the sensor values before and after the communication gap appear consistent. The continuity of the graph is determined by the reporting interval rather than by the similarity of the measured values.
As a result, individual sensor readings continue to be stored, processed, and included in reports, but they are not visually connected when they belong to different continuity intervals.
#### Why doesn't the platform connect the segments?
The primary objective of the reporting engine is to represent only information that has actually been reported by the device.
If the platform automatically connected two points separated by a long communication gap, it would implicitly assume what occurred during the period in which no data was received. Since the platform has no information describing the sensor behavior during that interval, any line connecting those points would represent an estimation rather than actual recorded data.
During a communication gap, numerous situations may have occurred.
* The sensor value may have remained completely stable throughout the reporting gap.
* The sensor value may have increased gradually over time.
* The sensor value may have decreased progressively during the interval.
* A sudden event, such as a refueling or fuel theft, may have occurred but was never reported due to the absence of data.
* The device itself may have been offline or temporarily stopped transmitting data during that period.
This design guarantees that every line displayed in the report represents a sequence of real measurements instead of assumptions. Although this approach may produce visual interruptions in the graph, it preserves the integrity of the data and prevents users from drawing conclusions based on information that was never reported by the device.
### Reducing communication gaps
In most situations, discontinuous intervals originate from the device configuration rather than from the reporting engine itself.
The first aspect that should be reviewed is the sensor reporting strategy. Many tracking devices are configured to transmit sensor information only when a change is detected instead of sending periodic updates. While this behavior reduces network traffic and bandwidth consumption, it naturally produces long periods without sensor readings whenever the measured value remains unchanged.
Another important factor is the device reporting frequency. Increasing the reporting interval frequency generally results in more continuous datasets and therefore smoother report visualization.
Power management should also be considered. Depending on the device configuration, the device may enter Sleep, Deep Sleep, or another power-saving mode when the ignition is turned off. In these states, the device may continue communicating with the server through heartbeat packets while temporarily suspending sensor transmissions. Although the server still recognizes the device as connected, no new sensor values are received, which eventually creates new continuity intervals.
For this reason, the most effective way to reduce gray zones is to review the device configuration, including:
* Sensor reporting frequency.
* Sensor transmission priority.
* Event-based versus periodic reporting.
* Sleep and Deep Sleep configuration.
* Device power source and ignition behavior.
Optimizing these parameters allows the platform to receive sensor readings more frequently, resulting in longer continuous intervals and a more complete graphical representation, while preserving the accuracy and integrity of the recorded data.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://navixy.com/docs/expert-center/vehicle-telematics-technology/fuel-management/understanding-gray-zones-in-fuel-level-reports.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.