Leer fallas de la ECU (DTC)

Esta nota muestra cómo configurar el equipo para que informe qué fallas tiene el vehículo —los mismos códigos que muestra un escáner de taller— y cómo integrarlos en una plataforma.

Hasta ahora el equipo informaba si el vehículo tenía fallas y cuántas: el equivalente a la luz de avería del tablero. Con el módulo DTC informa cuáles son.

Compatibilidad

Rinho Zero IoT no tiene transceptor CAN: no puede leer fallas del vehículo.

1. Qué se obtiene

Todo llega por el protocolo normal del equipo (UDP/TCP/SMS), con cola, reintentos y confirmación. No requiere hardware adicional: usa la conexión CAN que el equipo ya tiene, y funciona igual con el accesorio CANBUS Contactless (inductivo).

2. Verificar el protocolo del bus

Es el paso que más problemas evita. El protocolo configurado tiene que coincidir con el vehículo:

>QCXCAN<

3. Habilitar la lectura

Un solo comando pone todo en marcha:

>SCXDTC1,3,0,1,GP<

Verificación: >QCXDTC< → RCXDTC1,3,0,1,GP

Con el primer campo en 0 (default de fábrica) el módulo queda completamente inactivo: no reserva memoria ni toca el bus.

4. Consultar el estado

>QDTC<

En OBD2 el equipo consulta a la ECU cada 30 segundos: después de habilitar hay que esperar una vuelta antes de dar por buena una respuesta en cero. En J1939 la ECU emite las fallas por su cuenta y la lectura es inmediata.

5. Lo que recibe la plataforma

Con autorpt=1, cada vez que aparece una falla nueva o se resuelven todas llega un reporte DF:

>RDF00020826143512;2;J:00:100:1:4;J:00:1761:1:12<
     │  │      │      │
     │  │      │      └─ lista de fallas
     │  │      └──────── cantidad activa (0 = se resolvieron todas)
     │  └─────────────── fecha y hora DEL EVENTO (ddmmaa hhmmss)
     └────────────────── número de reporte

Tres cosas que simplifican la integración:

• Cada reporte es una foto completa. No hay que reconstruir estado del lado del servidor.
• La fecha y hora son las del momento de la falla, no las del envío: si el vehículo estuvo sin cobertura, el reporte espera en la cola y al recuperar señal informa cuándo ocurrió realmente.
• Cantidad en cero = resolución. Cuando desaparece la última falla llega el aviso.

También se puede pedir en cualquier momento, sin esperar a que haya una falla:

>QDF<        // respuesta directa por el canal que preguntó
>GDF00H<     // encola el reporte al destino configurado

6. Interpretar los códigos

J1939

J:00:100:1:4

La ECU de motor (00) informa que la presión de aceite (SPN 100) está por debajo del rango normal (FMI 1), y ocurrió 4 veces.

El FMI distingue el tipo de falla, y esa diferencia cambia el diagnóstico:

Presión de combustible con FMI 1 es presión baja real (filtro, bomba). Con FMI 5 es circuito abierto: se desconectó el sensor o se cortó un cable.

SPN de referencia: 100 presión de aceite · 110 temperatura de refrigerante · 94 presión de combustible · 190 RPM · 168 tensión de batería · 651-656 inyectores 1 a 6 · 1761 nivel de AdBlue/urea · 3226 sensor NOx (SCR).

OBD2

O:00:P0301:0:0

La ECU de motor (00) informa un fallo de encendido en el cilindro 1 (P0301).

Los dos últimos campos van en cero: FMI y ocurrencias son campos de J1939, OBD2 no los transmite.

7. Reaccionar en el vehículo, sin pasar por el servidor

Las fallas son disparadores del motor de eventos: se combinan con ignición, velocidad, entradas o geocercas como cualquier otra señal.

// Falla nueva → reporte inmediato al servidor
>SRL05E;TRG=DTC01+;ACC={GDF00H}<
 
// Lámpara de tablero encendida → salida a un buzzer en cabina
>SRL07E;TRG=DTC02+;ACC={SSSXP0011}<
 
// Falla nueva con la ignición puesta → aviso por SMS al supervisor
>SRL08E;TRG=DTC01+;CND=IGN;ACC={GTX01H;@SM0;TXT=Falla activa en marcha}<

Para condiciones numéricas están las funciones EVAL:

>EVAL DTCN()<          // cantidad de fallas activas
>EVAL DTCH(100)<       // 1 si la presión de aceite está en falla (J1939)
>EVAL DTC(2)<          // 1 si hay lámpara de tablero encendida

Y el token 'DTC' inserta la lista completa en cualquier reporte de usuario:

>SUC00 $ID fallas:'DTC'<

8. Si no aparece ninguna falla

En orden, lo más frecuente primero:

1. El protocolo no coincide con el vehículo — >QCXCAN<: J1939 en camión, OBDII en liviano.
2. La lectura está deshabilitada — >QDTC< responde RDTCNA. Habilitar con SCXDTC.
3. La T del firmware es anterior a la 9 y el vehículo es liviano — >QVR<. El soporte OBD2 entró en 1.09.27.T9.
4. No pasó el ciclo de 30 segundos de OBD2 — esperar una vuelta más.
5. El vehículo no tiene fallas activas — RDTC0 es un resultado correcto. Contrastar con el tablero o con un escáner.
6. La ECU no publica fallas — no todas las emiten en el bus (J1939) ni responden al Mode 03 (OBD2). Se confirma mirando si llegan otros datos del motor (RPM, temperatura) con ECU.

Si las fallas aparecen en >QDTC< pero no llega ningún reporte: revisar el 4º campo de SCXDTC (tiene que estar en 1) y el 5º, el destino. Con LOG el reporte no sale por la red: queda en el equipo y se baja con >QDL+<.

9. Alcance actual

Límites: hasta 32 fallas simultáneas en la tabla del equipo y unas 15 por trama (la cantidad informada siempre es la real). En J1939 el módulo es escucha pura y no transmite nada al bus; en OBD2 consulta cada 30 segundos, igual que un escáner conectado al conector de diagnóstico.

Ver También

• Comando CXDTC - Referencia completa de los comandos
• Reporte DF - Formato del reporte de fallas
• Comando CXCAN - Selección del protocolo del bus
• Comando ECU - Telemetría del motor