Ler falhas da ECU (DTC)

Esta nota mostra como configurar o equipamento para que informe quais falhas o veículo tem —os mesmos códigos que um scanner de oficina mostra— e como integrá-los a uma plataforma.

Até agora o equipamento informava se o veículo tinha falhas e quantas: o equivalente à luz de avaria do painel. Com o módulo DTC ele informa quais são.

Compatibilidade

O Rinho Zero IoT não tem transceptor CAN: não consegue ler falhas do veículo.

1. O que se obtém

Tudo chega pelo protocolo normal do equipamento (UDP/TCP/SMS), com fila, retentativas e confirmação. Não requer hardware adicional: usa a conexão CAN que o equipamento já tem e funciona igual com o acessório CANBUS Contactless (indutivo).

2. Verificar o protocolo do barramento

É o passo que mais evita problemas. O protocolo configurado precisa coincidir com o veículo:

>QCXCAN<

3. Habilitar a leitura

Um único comando coloca tudo em funcionamento:

>SCXDTC1,3,0,1,GP<

Verificação: >QCXDTC< → RCXDTC1,3,0,1,GP

Com o primeiro campo em 0 (padrão de fábrica) o módulo fica completamente inativo: não reserva memória nem toca o barramento.

4. Consultar o estado

>QDTC<

Em OBD2 o equipamento consulta a ECU a cada 30 segundos: depois de habilitar é preciso esperar uma volta antes de dar por boa uma resposta em zero. Em J1939 a ECU emite as falhas por conta própria e a leitura é imediata.

5. O que a plataforma recebe

Com autorpt=1, cada vez que aparece uma falha nova ou todas são resolvidas chega um relatório DF:

>RDF00020826143512;2;J:00:100:1:4;J:00:1761:1:12<
     │  │      │      │
     │  │      │      └─ lista de falhas
     │  │      └──────── quantidade ativa (0 = todas resolvidas)
     │  └─────────────── data e hora DO EVENTO (ddmmaa hhmmss)
     └────────────────── número do relatório

Três coisas que simplificam a integração:

• Cada relatório é uma foto completa. Não há estado para reconstruir do lado do servidor.
• A data e a hora são as do momento da falha, não as do envio: se o veículo esteve sem cobertura, o relatório espera na fila e, ao recuperar sinal, informa quando ocorreu de fato.
• Quantidade em zero = resolução. Quando some a última falha chega o aviso.

Também pode ser pedido a qualquer momento, sem esperar que haja uma falha:

>QDF<        // resposta direta pelo canal que perguntou
>GDF00H<     // enfileira o relatório no destino configurado

6. Interpretar os códigos

J1939

J:00:100:1:4

A ECU do motor (00) informa que a pressão de óleo (SPN 100) está abaixo da faixa normal (FMI 1), e ocorreu 4 vezes.

O FMI distingue o tipo de falha, e essa diferença muda o diagnóstico:

Pressão de combustível com FMI 1 é pressão baixa de verdade (filtro, bomba). Com FMI 5 é circuito aberto: o sensor foi desconectado ou um cabo se rompeu.

SPN de referência: 100 pressão de óleo · 110 temperatura do líquido de arrefecimento · 94 pressão de combustível · 190 RPM · 168 tensão de bateria · 651-656 injetores 1 a 6 · 1761 nível de Arla/ureia · 3226 sensor NOx (SCR).

OBD2

O:00:P0301:0:0

A ECU do motor (00) informa uma falha de ignição no cilindro 1 (P0301).

Os dois últimos campos vão em zero: FMI e ocorrências são campos do J1939, o OBD2 não os transmite.

7. Reagir no veículo, sem passar pelo servidor

As falhas são disparadores do motor de eventos: combinam-se com ignição, velocidade, entradas ou cercas eletrônicas como qualquer outro sinal.

// Falha nova → relatório imediato ao servidor
>SRL05E;TRG=DTC01+;ACC={GDF00H}<
 
// Lâmpada do painel acesa → saída para um buzzer na cabine
>SRL07E;TRG=DTC02+;ACC={SSSXP0011}<
 
// Falha nova com a ignição ligada → aviso por SMS ao supervisor
>SRL08E;TRG=DTC01+;CND=IGN;ACC={GTX01H;@SM0;TXT=Falha ativa}<

Para condições numéricas existem as funções EVAL:

>EVAL DTCN()<          // quantidade de falhas ativas
>EVAL DTCH(100)<       // 1 se a pressão de óleo está em falha (J1939)
>EVAL DTC(2)<          // 1 se há lâmpada do painel acesa

E o token 'DTC' insere a lista completa em qualquer relatório de usuário:

>SUC00 $ID falhas:'DTC'<

8. Se não aparecer nenhuma falha

Em ordem, do mais frequente ao menos:

1. O protocolo não coincide com o veículo — >QCXCAN<: J1939 em caminhão, OBDII em leve.
2. A leitura está desabilitada — >QDTC< responde RDTCNA. Habilitar com SCXDTC.
3. O T do firmware é anterior ao 9 e o veículo é leve — >QVR<. O suporte OBD2 entrou na 1.09.27.T9.
4. Não passou o ciclo de 30 segundos do OBD2 — esperar mais uma volta.
5. O veículo não tem falhas ativas — RDTC0 é um resultado correto. Conferir com o painel ou com um scanner.
6. A ECU não publica falhas — nem todas as emitem no barramento (J1939) nem respondem ao Mode 03 (OBD2), o mesmo que acontece com o VIN. Confirma-se olhando se chegam outros dados do motor (RPM, temperatura) com ECU.

Se as falhas aparecem em >QDTC< mas não chega nenhum relatório: revisar o 4º campo de SCXDTC (precisa estar em 1) e o 5º, o destino. Com LOG o relatório não sai pela rede: fica no equipamento e é baixado com >QDL+<.

9. Alcance atual

Limites: até 32 falhas simultâneas na tabela do equipamento e cerca de 15 por trama (a quantidade informada é sempre a real). Em J1939 o módulo é escuta pura e não transmite nada no barramento; em OBD2 consulta a cada 30 segundos, igual a um scanner conectado ao conector de diagnóstico.

Veja Também

• Comando CXDTC - Referência completa dos comandos
• Relatório DF - Formato do relatório de falhas
• Comando CXCAN - Seleção do protocolo do barramento
• Comando ECU - Telemetria do motor