> 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, assumindo que a plataforma não está 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 consequência da lógica de continuidade de dados da plataforma, que foi projetada para evitar interpolação imprecisa entre longas lacunas de comunicação.
Este documento explica como a plataforma processa os dados do sensor, por que surgem 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 posiçã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 própria posição seja considerada inválida, os valores do sensor contidos no mesmo pacote permanecem válidos e sempre são 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 os 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 que as leituras individuais do sensor estejam 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 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 um novo intervalo começa. Consequentemente, o gráfico é dividido em segmentos independentes em vez de ser renderizado como uma 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 envio, e não pela similaridade dos valores medidos.
Como resultado, as leituras individuais do sensor continuam sendo armazenadas, processadas e incluídas em 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 objetivo principal 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 presumiria 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 reais registrados.
Durante uma lacuna de comunicação, várias situações podem ter ocorrido.
* O valor do sensor pode ter permanecido completamente estável durante todo o intervalo sem envio de dados.
* 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 roubo 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 projeto 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 revisado é a estratégia de envio de dados 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 largura 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 envio 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 fluida.
O gerenciamento de energia também deve ser considerado. Dependendo da configuração do dispositivo, ele pode entrar em Sleep, Deep Sleep ou em 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 heartbeat enquanto suspende temporariamente as transmissões do sensor. Embora o servidor ainda reconheça o dispositivo como conectado, nenhum novo valor do sensor é recebido, o que acaba criando 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 envio dos dados do sensor.
* Prioridade de transmissão do sensor.
* Envio com base em eventos versus envio periódico.
* Configuração dos modos Sleep e Deep Sleep.
* Fonte de alimentação do dispositivo e comportamento da ignição.
A otimização desses 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, ao mesmo tempo em que 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 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/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 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.