> 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/pt-br/vehicle-telematics-technology/fuel-management/understanding-gray-zones-in-fuel-level-reports.md).
# Compreensão das zonas cinzentas nos relatórios de nível de combustível
As zonas cinzentas nos relatórios de nível de combustível resultam da lógica de continuidade dos dados, não de leituras ausentes. Abrange a validade do GPS em comparação à do sensor e como reduzir lacunas nos relatórios.
### Visão geral
Clientes ocasionalmente relatam zonas cinzas ou linhas descontínuas em relatórios de nível de combustível, supondo que a plataforma não esteja processando corretamente os dados do sensor. Esse comportamento pode gerar confusão porque pode parecer que as leituras do sensor estão ausentes ou sendo ignoradas.
Na realidade, a plataforma continua processando corretamente os dados do sensor. As zonas cinzas são uma consequência da lógica de continuidade de dados da plataforma, que foi projetada para evitar interpolação imprecisa entre longas lacunas de relatório.
Este documento explica como a plataforma processa os dados do sensor, por que aparecem intervalos descontínuos e o que pode ser feito para minimizá-los.
### Dados válidos do sensor vs. dados inválidos de GPS
O primeiro conceito a entender é que a validade do GPS e a validade do sensor são independentes.
Uma localização é considerada inválida quando:
* Nenhum satélite de GPS está disponível.
* Menos de três satélites estão disponíveis.
* A latitude ou a longitude é igual a 0.
Embora a localização em si seja considerada inválida, os valores do sensor contidos no mesmo pacote permanecem válidos e são sempre processados.
Por exemplo:
Embora a posição de GPS não possa ser exibida no mapa devido à falta de satélites, o valor de avl\_io\_9 (sensor de nível de combustível) ainda é:
* Recebido
* Armazenado
* Processado
* Exibido em relatórios de combustível
* Usado pelo IoT Logic
Em outras palavras, dados inválidos de GPS não invalidam dados do sensor.
### Continuidade dos dados do sensor
Uma das perguntas mais comuns sobre relatórios de nível de combustível é por que o gráfico exibe segmentos descontínuos, mesmo quando as leituras individuais do sensor estão presentes no relatório.
Do ponto de vista do cliente, esse comportamento pode parecer incorreto porque os valores do sensor estão visíveis, mas o gráfico não é renderizado como uma única linha contínua. Em muitos casos, os clientes interpretam essas interrupções como dados ausentes ou processamento incorreto, quando na realidade elas são o resultado da lógica de continuidade da plataforma.
#### Lógica de continuidade
A plataforma agrupa as leituras do sensor em intervalos contínuos com base na diferença de tempo entre registros consecutivos.
Quando o tempo decorrido entre duas leituras consecutivas do sensor excede 30 minutos, a plataforma considera que o intervalo anterior terminou e que um novo intervalo começa. Consequentemente, o gráfico é dividido em segmentos independentes em vez de ser renderizado como uma única linha ininterrupta.
Esse comportamento é intencional e se aplica independentemente de os valores do sensor antes e depois da lacuna de comunicação parecerem consistentes. A continuidade do gráfico é determinada pelo intervalo de relatório, e não pela semelhança dos valores medidos.
Como resultado, as leituras individuais do sensor continuam sendo armazenadas, processadas e incluídas nos relatórios, mas não são conectadas visualmente quando pertencem a diferentes intervalos de continuidade.
#### Por que a plataforma não conecta os segmentos?
O principal objetivo do mecanismo de relatórios é representar apenas as informações que realmente foram reportadas pelo dispositivo.
Se a plataforma conectasse automaticamente dois pontos separados por uma longa lacuna de comunicação, ela assumiria implicitamente o que ocorreu durante o período em que nenhum dado foi recebido. Como a plataforma não tem informações que descrevam o comportamento do sensor durante esse intervalo, qualquer linha que conecte esses pontos representaria uma estimativa, e não dados registrados reais.
Durante uma lacuna de comunicação, muitas situações podem ter ocorrido.
* O valor do sensor pode ter permanecido completamente estável durante toda a lacuna de relatório.
* O valor do sensor pode ter aumentado gradualmente ao longo do tempo.
* O valor do sensor pode ter diminuído progressivamente durante o intervalo.
* Um evento repentino, como um abastecimento ou um furto de combustível, pode ter ocorrido, mas nunca foi reportado devido à ausência de dados.
* O próprio dispositivo pode ter ficado offline ou parado temporariamente de transmitir dados durante esse período.
Esse design garante que cada linha exibida no relatório represente uma sequência de medições reais, em vez de suposições. Embora essa abordagem possa produzir interrupções visuais no gráfico, ela preserva a integridade dos dados e impede que os usuários tirem conclusões com base em informações que nunca foram reportadas pelo dispositivo.
### Reduzindo lacunas de comunicação
Na maioria das situações, os intervalos descontínuos se originam da configuração do dispositivo, e não do próprio mecanismo de relatórios.
O primeiro aspecto que deve ser verificado é a estratégia de reporte do sensor. Muitos dispositivos de rastreamento são configurados para transmitir informações do sensor apenas quando uma alteração é detectada, em vez de enviar atualizações periódicas. Embora esse comportamento reduza o tráfego de rede e o consumo de banda, ele naturalmente produz longos períodos sem leituras do sensor sempre que o valor medido permanece inalterado.
Outro fator importante é a frequência de reporte do dispositivo. Aumentar a frequência de envio geralmente resulta em conjuntos de dados mais contínuos e, portanto, em uma visualização de relatório mais suave.
O gerenciamento de energia também deve ser considerado. Dependendo da configuração do dispositivo, ele pode entrar em modo de suspensão, suspensão profunda ou outro modo de economia de energia quando a ignição é desligada. Nesses estados, o dispositivo pode continuar se comunicando com o servidor por meio de pacotes de sinal de presença, enquanto suspende temporariamente as transmissões do sensor. Embora o servidor ainda reconheça o dispositivo como conectado, nenhum novo valor de sensor é recebido, o que eventualmente cria novos intervalos de continuidade.
Por esse motivo, a maneira mais eficaz de reduzir as zonas cinzas é revisar a configuração do dispositivo, incluindo:
* Frequência de reporte do sensor.
* Prioridade de transmissão do sensor.
* Reporte baseado em eventos versus reporte periódico.
* Configuração de suspensão e suspensão profunda.
* Fonte de alimentação do dispositivo e comportamento da ignição.
Otimizar esses parâmetros permite que a plataforma receba leituras do sensor com mais frequência, resultando em intervalos contínuos mais longos e em uma representação gráfica mais completa, enquanto preserva a precisão e a integridade dos dados 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 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/pt-br/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.