Si has trabajado con un Teltonika en producción, en algún momento te has topado con la pregunta: ¿qué codec uso, 8, 8E o 16? La respuesta corta es que casi siempre Codec 8E. La larga implica entender cómo Teltonika empaqueta los datos AVL, por qué hay tres formatos, y cuándo conviene cada uno. Este post es la referencia que nos hubiera gustado tener cuando integramos el primer FMC920.
Qué es un codec en Teltonika
Un codec en el mundo Teltonika no es de audio ni de vídeo. Es el formato binario con el que el dispositivo serializa los registros de telemetría (posición, velocidad, IOs, eventos) para enviarlos al servidor por TCP. Es el equivalente al "schema" del protocolo: define qué campos van, en qué orden, con qué tipo y tamaño.
Cuando configuras un Teltonika apuntando a tu servidor (Traccar, Wialon, Fletaro o uno propio), el codec es el contrato entre los dos. Si el servidor no implementa el codec que el dispositivo envía, no puede decodificar la trama.
Los tres codecs más usados hoy son:
- Codec 8 — el clásico, original. AVL ID de 1 byte. Limitado pero compacto.
- Codec 8 Extended (8E) — extiende AVL ID a 2 bytes. Es el codec por defecto en todos los Teltonika modernos (FMB, FMC, FMM y posteriores). Los modelos con bus CAN nativo como el FMC150 y los trackers de camión FMC650 usan Codec 8E por defecto.
- Codec 16 — adicional, incorpora un generation type explícito por registro. Útil para diferenciar eventos de registros periódicos.
Estructura general de un paquete AVL
Antes de entrar en cada codec, esta es la envoltura TCP común de cualquier paquete Teltonika:
Preamble (4 bytes) → 0x00000000 Data Field Length (4) → número de bytes del data field Codec ID (1) → 0x08, 0x8E, 0x10 (16 decimal) Number of Data 1 (1) → cuántos AVL records vienen [AVL Data ...] → registros AVL en formato codec Number of Data 2 (1) → mismo número que el primero CRC-16 (4) → CRC de Data Field Length+Data
El codec ID identifica el formato del bloque AVL. Lo que cambia entre codec 8, 8E y 16 es cómo se serializa cada AVL record dentro de ese bloque.
Codec 8 (Codec ID = 0x08)
El codec original. Cada AVL record incluye:
Timestamp (8 bytes) → ms desde epoch (UTC) Priority (1 byte) → 0=low, 1=high, 2=panic GPS Element (15 bytes): Longitude (4) → entero firmado, multiplica por 10⁻⁷ grados Latitude (4) → mismo formato Altitude (2) → metros Angle (2) → 0-359° Satellites (1) → número de satélites en uso Speed (2) → km/h IO Element: Event IO ID (1) → AVL ID que disparó este registro (0 = periódico) Total IO (1) → número total de IOs en el record N1 (1) + [IO ID (1) + Value (1 byte)] × N1 N2 (1) + [IO ID (1) + Value (2 bytes)] × N2 N4 (1) + [IO ID (1) + Value (4 bytes)] × N4 N8 (1) + [IO ID (1) + Value (8 bytes)] × N8
Limitación clave: el AVL ID se codifica en 1 byte (0-255). Eso es suficiente para los IOs básicos (encendido, velocidad, voltaje, GSM signal) pero no para todos los AVL IDs que existen en Teltonika moderno. El localizador FMC920 solo tiene ~190 AVL IDs declarados. El total del ecosistema (con bus CAN, sensores externos, módulos LV-CAN) supera los 1.500. No caben en 1 byte.
Codec 8 sigue funcionando para casos básicos (tracking + un puñado de IOs), pero está deprecado. Si vas a empezar un proyecto nuevo, no lo uses.
Codec 8 Extended / 8E (Codec ID = 0x8E)
La extensión natural del 8: AVL ID pasa de 1 byte a 2 bytes (65.535 valores posibles), y se añade un campo Variable Length IO para datos de longitud arbitraria (necesario para sensores que devuelven cadenas, blobs binarios o datos largos como mapas de eventos CAN).
Timestamp (8 bytes) → idéntico a Codec 8 Priority (1) → idéntico GPS Element (15 bytes) → idéntico IO Element: Event IO ID (2 bytes) → ← cambio: ahora 2 bytes Total IO (2) → ← cambio: ahora 2 bytes N1 (2) + [IO ID (2) + Value (1)] × N1 N2 (2) + [IO ID (2) + Value (2)] × N2 N4 (2) + [IO ID (2) + Value (4)] × N4 N8 (2) + [IO ID (2) + Value (8)] × N8 NX (2) + [IO ID (2) + Length (2) + Value (Length)] × NX ← variable length
Codec 8E es la elección por defecto recomendada para cualquier dispositivo Teltonika moderno. Soporta toda la gama de AVL IDs actuales y futuros, soporta payloads variables (necesarios para CAN-CONTROL, lectores 1-Wire, sensores BLE), y todas las plataformas serias lo implementan.
Ejemplo: decodificar un AVL Element 8E real
Trama ejemplo (en hex), tomada de un FMC920 enviando posición + 5 IOs:
00000000 00000089 8E 01 00 0001 87B2 33BE 00 00 01D6CC9F 4F35EAD2 0064 0000 0F 09 00 0005 0000 ← Event IO ID (=0, periódico) y Total IO (=5) 0005 ← N1 (5 IOs de 1 byte) 0015 03 → IO 21 (GSM signal) = 3 0001 01 → IO 1 (Digital Input 1) = 1 0042 5C → IO 66 (Battery voltage centiV) = 92 → 9.2V 00B5 0F → IO 181 (GNSS HDOP) = 15 00B6 0B → IO 182 (GNSS PDOP) = 11 0000 ← N2 (0 IOs de 2 bytes) 0000 ← N4 0000 ← N8 0000 ← NX 01 00007D8B ← CRC
Esa misma trama en Codec 8 sería ~10 bytes más corta (porque los AVL IDs serían 1 byte), pero IO 181 y IO 182 ni cabrían (sus IDs son > 255).
Codec 16 (Codec ID = 0x10)
Codec 16 introduce un campo Generation Type por cada AVL record. Es similar a Codec 8 (AVL ID de 1 byte), pero añade información sobre la causa del registro:
Timestamp (8 bytes)
Timestamp Extension (1 byte) ← microsegundos / generación
Priority (1)
GPS Element (15)
Event IO ID (2 bytes) ← misma extensión que 8E
Generation Type (1 byte) ← causa del record: 0=on exit, 1=on entrance,
2=on both, 3=reserved, 4=hysteresis,
5=on change, 6=eventual, 7=periodical
N1 ... NX (idéntico a 8E)
Codec 16 sirve para casos donde necesitas saber exactamente por qué se generó el record sin tener que inferirlo del Event IO ID. Útil en flotas grandes donde quieres post-procesar eventos discriminando entre "registro periódico cada 30s" y "registro disparado por evento" sin mirar el AVL ID.
En la práctica casi nadie usa Codec 16. Si lo necesitas, ya sabes por qué; si no lo necesitas, sigue con 8E.
Cuándo usar cada codec
| Escenario | Codec recomendado |
|---|---|
| Nuevo proyecto, dispositivo moderno (FMB, FMC, FMM, MTB) | Codec 8E |
| Vas a leer bus CAN o conectar sensores BLE/RS485 | Codec 8E (necesitas IDs >255 y variable length) |
| Integración con un servidor antiguo que solo soporta 8 | Codec 8 (corto plazo, migrar a 8E cuanto antes) |
| Auditoría regulatoria que requiere generation type explícito por record | Codec 16 |
| Dispositivos FM legacy (FM1100, FM2200, FM3622) en producción heredada | Codec 8 (no soportan 8E en hardware antiguo) |
Regla práctica: si tu dispositivo es de la familia FMB / FMC / FMM y tu plataforma es moderna (Wialon, Traccar >= 5.0, Fletaro, GpsGate, Flespi), elige Codec 8E y olvídate.
Codecs adicionales que existen pero que ves poco
- Codec 12 — comandos GPRS: el servidor manda comandos al dispositivo (reinicio, cambio de configuración, query de estado). Lo usa la herramienta de configuración remota y plataformas que mandan comandos a distancia.
- Codec 13 — respuesta a Codec 12. El dispositivo responde.
- Codec 14 — comandos por IMEI / dirección directa, similar a 12 pero con direccionamiento por IMEI explícito.
- Codec 7 / 7E — para descarga de archivos (típicamente tacógrafo digital). El FMC650 descarga DDDs usando Codec 7E.
Estos no compiten con Codec 8/8E/16: son canales paralelos para tareas específicas (comandos, descarga de archivos). Tu servidor probablemente los implementa transparentemente.
Cómo configurar el codec en un Teltonika
Vía la herramienta de configuración oficial (FM Configurator conectado por cable USB) o vía FOTA con la plataforma FOTA Web:
- System → Codec: dropdown con las opciones disponibles del firmware actual.
- Establecer GPRS Server, puerto, APN.
- Aplicar configuración.
Sub-detalle: en algunos firmware el dispositivo elige automáticamente entre 8 y 8E según el número de IOs activos. Si solo tienes IOs de 1 byte ID, manda 8; en cuanto activas uno >255, salta a 8E. Compruébalo en el log de la primera trama recibida en tu servidor — el Codec ID está en el byte 9 del paquete.
Errores típicos al integrar
1. El servidor decodifica AVL ID en 1 byte y recibes IDs gigantes. Tu trama es 8E pero tu decodificador trata el primer byte del AVL ID como el ID completo. Resultado: AVL ID 0x01B5 se decodifica como 0x01 + 0xB5 separados. Verifica que tu decodificador respeta el Codec ID y aplica el formato correcto.
2. CRC falla y descartas la trama. El CRC-16 de Teltonika usa polinomio 0xA001 (CRC-16/IBM, "IBM Bisync"), no el CRC-16/CCITT estándar. Si tu librería CRC no es la correcta, todos los CRC fallarán aunque la trama esté bien.
3. El dispositivo "manda 8E" pero faltan IOs. Si activaste un IO en la configuración pero no aparece, normalmente es que el IO requiere otro IO previo activado, o requiere conectividad CAN/BLE que no está físicamente conectada. Mira la documentación del modelo para ver dependencias entre IOs.
4. Latencia alta y crees que es la red, pero es el codec. Codec 8E genera tramas más grandes que Codec 8. Con un plan de datos muy lento (2G en zonas rurales) puedes notar diferencia. En 4G es irrelevante.
Resumen
Si te quedas con dos ideas:
- Codec 8E es la elección moderna por defecto: 2 bytes para AVL ID, variable length para sensores, compatible con todo el ecosistema actual de Teltonika.
- Tu CRC es CRC-16/IBM, no CCITT. Si tu servidor descarta tramas con CRC inválido y nada cuadra, empieza por ahí.
Para una guía oficial con el detalle byte a byte y los AVL IDs por dispositivo, la wiki de Teltonika tiene la referencia completa (en inglés). Si te montas un decoder propio, esa wiki + esta nota deberían bastar para una integración limpia.
Si ya tienes hardware Teltonika y quieres una plataforma de gestión que ya implementa todos los codecs y procesa las tramas correctamente, Fletaro es nuestra empresa hermana SaaS que lo hace nativo. O si necesitas hardware con codecs correctamente configurados desde fábrica, en nuestra tienda los enviamos pre-configurados para integración estándar.
¿Necesitas un Teltonika para tu integración?
Stock real en España, envío 3-5 días, soporte técnico ES para configuración inicial. Todos compatibles con Codec 8, 8E y 16 desde fábrica.
¿No sabes cuál encaja con tu integración? Selector en 30 segundos → o escríbenos a info@trackiber.com.
Guías relacionadas
- Cómo configurar APN en un Teltonika (FMC, FMB, TAT): guía completa 2026
- FMC150 vs FMC130: CAN nativo vs CAN-CONTROL
- Bus CAN en flotas: qué parámetros lee cada modelo
- TAT240 antirrobo: remolques, contenedores y maquinaria
