> 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/es/vehicle-telematics-technology/fuel-management/understanding-gray-zones-in-fuel-level-reports.md).
# Entender las zonas grises en los reportes de nivel de combustible
Las zonas grises en los reportes de nivel de combustible provienen de la lógica de continuidad de datos, no de lecturas faltantes. Cubre la validez del GPS frente a la del sensor y cómo reducir las brechas en los reportes.
### Visión general
Los clientes ocasionalmente reportan zonas grises o líneas discontinuas en los reportes de nivel de combustible, asumiendo que la plataforma no está procesando correctamente los datos del sensor. Este comportamiento puede generar confusión porque puede parecer que faltan lecturas del sensor o que se ignoran.
En realidad, la plataforma continúa procesando correctamente los datos del sensor. Las zonas grises son una consecuencia de la lógica de continuidad de datos de la plataforma, que está diseñada para evitar una interpolación inexacta entre largos intervalos de reporte.
Este documento explica cómo procesa la plataforma los datos del sensor, por qué aparecen intervalos discontinuos y qué se puede hacer para minimizarlos.
### Datos válidos del sensor vs. datos GPS inválidos
El primer concepto que debe entender es que la validez del GPS y la validez del sensor son independientes.
Una ubicación se considera inválida cuando:
* No hay satélites GPS disponibles.
* Hay menos de tres satélites disponibles.
* La latitud o la longitud es 0.
Aunque la ubicación en sí se considera inválida, los valores del sensor contenidos en el mismo paquete siguen siendo válidos y siempre se procesan.
Por ejemplo:
Aunque la posición GPS no se puede mostrar en el mapa debido a la falta de satélites, el valor de avl\_io\_9 (sensor de combustible) sigue siendo:
* Recibido
* Almacenado
* Procesado
* Mostrado en reportes de combustible
* Usado por IoT Logic
En otras palabras, los datos GPS inválidos no invalidan los datos del sensor.
### Continuidad de los datos del sensor
Una de las preguntas más comunes con respecto a los reportes de nivel de combustible es por qué el gráfico muestra segmentos discontinuos, aunque las lecturas individuales del sensor estén presentes en el reporte.
Desde la perspectiva del cliente, este comportamiento puede parecer incorrecto porque los valores del sensor son visibles, pero el gráfico no se representa como una sola línea continua. En muchos casos, los clientes interpretan estas interrupciones como datos faltantes o procesamiento incorrecto, cuando en realidad son el resultado de la lógica de continuidad de la plataforma.
#### Lógica de continuidad
La plataforma agrupa las lecturas del sensor en intervalos continuos según la diferencia de tiempo entre registros consecutivos.
Cuando el tiempo transcurrido entre dos lecturas consecutivas del sensor supera los 30 minutos, la plataforma considera que el intervalo anterior ha terminado y comienza un nuevo intervalo. En consecuencia, el gráfico se divide en segmentos independientes en lugar de representarse como una sola línea ininterrumpida.
Este comportamiento es intencional y se aplica independientemente de si los valores del sensor antes y después del intervalo de comunicación parecen consistentes. La continuidad del gráfico la determina el intervalo de reporte más que la similitud de los valores medidos.
Como resultado, las lecturas individuales del sensor continúan almacenándose, procesándose e incluyéndose en los reportes, pero no se conectan visualmente cuando pertenecen a diferentes intervalos de continuidad.
#### ¿Por qué la plataforma no conecta los segmentos?
El objetivo principal del motor de reportes es representar solo la información que realmente ha reportado el dispositivo.
Si la plataforma conectara automáticamente dos puntos separados por un largo intervalo de comunicación, asumiría implícitamente lo que ocurrió durante el período en que no se recibieron datos. Como la plataforma no tiene información que describa el comportamiento del sensor durante ese intervalo, cualquier línea que conecte esos puntos representaría una estimación y no datos reales registrados.
Durante un intervalo de comunicación, pueden haber ocurrido numerosas situaciones.
* El valor del sensor puede haber permanecido completamente estable durante el intervalo de reporte.
* El valor del sensor puede haber aumentado gradualmente con el tiempo.
* El valor del sensor puede haber disminuido progresivamente durante el intervalo.
* Puede haber ocurrido un evento repentino, como un repostaje o robo de combustible, pero nunca se reportó debido a la ausencia de datos.
* El dispositivo mismo puede haber estado fuera de línea o detenido temporalmente, sin transmitir datos durante ese período.
Este diseño garantiza que cada línea mostrada en el reporte represente una secuencia de mediciones reales en lugar de suposiciones. Aunque este enfoque puede producir interrupciones visuales en el gráfico, preserva la integridad de los datos y evita que los usuarios saquen conclusiones basadas en información que nunca fue reportada por el dispositivo.
### Reducir los intervalos de comunicación
En la mayoría de las situaciones, los intervalos discontinuos se originan en la configuración del dispositivo más que en el motor de reportes en sí.
El primer aspecto que debe revisarse es la estrategia de reporte del sensor. Muchos dispositivos de rastreo están configurados para transmitir información del sensor solo cuando se detecta un cambio en lugar de enviar actualizaciones periódicas. Aunque este comportamiento reduce el tráfico de red y el consumo de ancho de banda, naturalmente produce largos períodos sin lecturas del sensor cuando el valor medido permanece sin cambios.
Otro factor importante es la frecuencia de reporte del dispositivo. Aumentar la frecuencia del intervalo de reporte generalmente da como resultado conjuntos de datos más continuos y, por lo tanto, una visualización de reportes más fluida.
También debe considerarse la administración de energía. Según la configuración del dispositivo, este puede entrar en Sleep, Deep Sleep u otro modo de ahorro de energía cuando se apaga la ignición. En estos estados, el dispositivo puede seguir comunicándose con el servidor mediante paquetes heartbeat mientras suspende temporalmente las transmisiones del sensor. Aunque el servidor todavía reconoce al dispositivo como conectado, no se reciben nuevos valores del sensor, lo que con el tiempo crea nuevos intervalos de continuidad.
Por esta razón, la manera más eficaz de reducir las zonas grises es revisar la configuración del dispositivo, incluyendo:
* Frecuencia de reporte del sensor.
* Prioridad de transmisión del sensor.
* Reporte basado en eventos versus reporte periódico.
* Configuración de Sleep y Deep Sleep.
* Fuente de alimentación del dispositivo y comportamiento de la ignición.
Optimizar estos parámetros permite que la plataforma reciba lecturas del sensor con mayor frecuencia, lo que da como resultado intervalos continuos más largos y una representación gráfica más completa, al tiempo que preserva la precisión y la integridad de los datos registrados.
---
# 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 by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://navixy.com/docs/expert-center/es/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 what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
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.