Si tu as travaillé avec un Teltonika en production, à un moment tu t'es posé la question : quel codec j'utilise, 8, 8E ou 16 ? La réponse courte est presque toujours Codec 8E. La longue implique de comprendre comment Teltonika empaquette les données AVL, pourquoi il y a trois formats, et quand chacun convient. Ce post est la référence qu'on aurait aimé avoir quand on a intégré le premier FMC920.
Qu'est-ce qu'un codec chez Teltonika
Un codec dans le monde Teltonika n'a rien à voir avec l'audio ou la vidéo. C'est le format binaire avec lequel le dispositif sérialise les enregistrements de télémétrie (position, vitesse, IOs, événements) pour les envoyer au serveur via TCP. C'est l'équivalent du « schema » du protocole : ça définit quels champs partent, dans quel ordre, avec quel type et taille.
Quand tu configures un Teltonika pointant vers ton serveur (Traccar, Wialon, Fletaro ou un serveur maison), le codec est le contrat entre les deux. Si le serveur n'implémente pas le codec que le dispositif envoie, il ne peut pas décoder la trame.
Les trois codecs les plus utilisés aujourd'hui sont :
- Codec 8 — le classique, l'original. AVL ID de 1 octet. Limité mais compact.
- Codec 8 Extended (8E) — étend l'AVL ID à 2 octets. C'est le codec par défaut sur tous les Teltonika modernes (FMB, FMC, FMM et postérieurs).
- Codec 16 — additionnel, incorpore un generation type explicite par enregistrement. Utile pour distinguer événements et enregistrements périodiques.
Structure générale d'un paquet AVL
Avant d'entrer dans chaque codec, voici l'enveloppe TCP commune à tout paquet Teltonika :
Preamble (4 bytes) → 0x00000000 Data Field Length (4) → nombre d'octets du data field Codec ID (1) → 0x08, 0x8E, 0x10 (16 décimal) Number of Data 1 (1) → combien d'AVL records arrivent [AVL Data ...] → enregistrements AVL au format codec Number of Data 2 (1) → même nombre que le premier CRC-16 (4) → CRC de Data Field Length+Data
Le codec ID identifie le format du bloc AVL. Ce qui change entre codec 8, 8E et 16 est comment chaque AVL record se sérialise à l'intérieur de ce bloc.
Codec 8 (Codec ID = 0x08)
Le codec original. Chaque AVL record inclut :
Timestamp (8 bytes) → ms depuis epoch (UTC) Priority (1 byte) → 0=low, 1=high, 2=panic GPS Element (15 bytes): Longitude (4) → entier signé, multiplier par 10⁻⁷ degrés Latitude (4) → même format Altitude (2) → mètres Angle (2) → 0-359° Satellites (1) → nombre de satellites utilisés Speed (2) → km/h IO Element: Event IO ID (1) → AVL ID qui a déclenché cet enregistrement (0 = périodique) Total IO (1) → nombre total d'IOs dans le 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
Limitation clé : l'AVL ID se code sur 1 octet (0-255). C'est suffisant pour les IOs basiques (ignition, vitesse, tension, signal GSM) mais pas pour tous les AVL IDs qui existent dans le Teltonika moderne. Le FMC920 seul a ~190 AVL IDs déclarés. Le total de l'écosystème (avec bus CAN, capteurs externes, modules LV-CAN) dépasse 1 500. Ça ne rentre pas dans 1 octet.
Codec 8 fonctionne encore pour les cas basiques (tracking + une poignée d'IOs), mais il est déprécié. Si tu lances un nouveau projet, ne l'utilise pas.
Codec 8 Extended / 8E (Codec ID = 0x8E)
L'extension naturelle du 8 : AVL ID passe de 1 octet à 2 octets (65 535 valeurs possibles), et un champ Variable Length IO est ajouté pour les données de longueur arbitraire (nécessaire pour les capteurs qui renvoient des chaînes, des blobs binaires ou des données longues comme des mappings d'événements CAN).
Timestamp (8 bytes) → identique à Codec 8 Priority (1) → identique GPS Element (15 bytes) → identique IO Element: Event IO ID (2 bytes) → ← changement : maintenant 2 octets Total IO (2) → ← changement : maintenant 2 octets 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 est le choix par défaut recommandé pour tout dispositif Teltonika moderne. Il supporte toute la gamme d'AVL IDs actuels et futurs, supporte les payloads variables (nécessaires pour CAN-CONTROL, lecteurs 1-Wire, capteurs BLE), et toutes les plateformes sérieuses l'implémentent.
Exemple : décoder un AVL Element 8E réel
Trame exemple (en hex), prise d'un FMC920 envoyant position + 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, périodique) et Total IO (=5) 0005 ← N1 (5 IOs de 1 octet) 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 octets) 0000 ← N4 0000 ← N8 0000 ← NX 01 00007D8B ← CRC
Cette même trame en Codec 8 serait ~10 octets plus courte (parce que les AVL IDs feraient 1 octet), mais IO 181 et IO 182 ne rentreraient même pas (leurs IDs sont > 255).
Codec 16 (Codec ID = 0x10)
Codec 16 introduit un champ Generation Type pour chaque AVL record. Il est similaire au Codec 8 (AVL ID de 1 octet), mais ajoute des informations sur la cause de l'enregistrement :
Timestamp (8 bytes)
Timestamp Extension (1 byte) ← microsecondes / génération
Priority (1)
GPS Element (15)
Event IO ID (2 bytes) ← même extension que 8E
Generation Type (1 byte) ← cause du record : 0=on exit, 1=on entrance,
2=on both, 3=reserved, 4=hysteresis,
5=on change, 6=eventual, 7=periodical
N1 ... NX (identique à 8E)
Codec 16 sert pour les cas où tu dois savoir exactement pourquoi le record a été généré sans devoir l'inférer depuis l'Event IO ID. Utile sur les grandes flottes où tu veux post-traiter les événements en distinguant entre « record périodique toutes les 30s » et « record déclenché par événement » sans regarder l'AVL ID.
En pratique presque personne n'utilise Codec 16. Si tu en as besoin, tu sais déjà pourquoi ; sinon, reste sur 8E.
Quand utiliser chaque codec
| Scénario | Codec recommandé |
|---|---|
| Nouveau projet, dispositif moderne (FMB, FMC, FMM, MTB) | Codec 8E |
| Tu vas lire le bus CAN ou connecter des capteurs BLE/RS485 | Codec 8E (tu as besoin d'IDs >255 et de variable length) |
| Intégration avec un serveur ancien qui ne supporte que 8 | Codec 8 (court terme, migrer en 8E dès que possible) |
| Audit réglementaire qui requiert un generation type explicite par record | Codec 16 |
| Dispositifs FM legacy (FM1100, FM2200, FM3622) en production héritée | Codec 8 (ne supportent pas le 8E en matériel ancien) |
Règle pratique : si ton dispositif est de la famille FMB / FMC / FMM et ta plateforme est moderne (Wialon, Traccar >= 5.0, Fletaro, GpsGate, Flespi), choisis Codec 8E et oublie.
Codecs additionnels qui existent mais qu'on voit peu
- Codec 12 — commandes GPRS : le serveur envoie des commandes au dispositif (redémarrage, changement de configuration, query d'état). Utilisé par l'outil de configuration à distance et les plateformes qui envoient des commandes à distance.
- Codec 13 — réponse au Codec 12. Le dispositif répond.
- Codec 14 — commandes par IMEI / adresse directe, similaire au 12 mais avec adressage par IMEI explicite.
- Codec 7 / 7E — pour téléchargement de fichiers (typiquement tachygraphe numérique). Le FMC650 télécharge les DDDs en utilisant Codec 7E.
Ceux-ci ne sont pas en concurrence avec Codec 8/8E/16 : ce sont des canaux parallèles pour des tâches spécifiques (commandes, téléchargement de fichiers). Ton serveur les implémente probablement de façon transparente.
Comment configurer le codec sur un Teltonika
Via l'outil de configuration officiel (FM Configurator connecté par câble USB) ou via FOTA avec la plateforme FOTA Web :
- System → Codec : dropdown avec les options disponibles du firmware actuel.
- Définir GPRS Server, port, APN.
- Appliquer la configuration.
Sous-détail : sur certains firmware, le dispositif choisit automatiquement entre 8 et 8E selon le nombre d'IOs actifs. Si tu n'as que des IOs de 1 octet ID, il envoie 8 ; dès que tu en actives un >255, il bascule en 8E. Vérifie-le dans le log de la première trame reçue sur ton serveur — le Codec ID est dans l'octet 9 du paquet.
Erreurs typiques à l'intégration
1. Le serveur décode l'AVL ID sur 1 octet et tu reçois des IDs énormes. Ta trame est 8E mais ton décodeur traite le premier octet de l'AVL ID comme l'ID complet. Résultat : AVL ID 0x01B5 est décodé comme 0x01 + 0xB5 séparés. Vérifie que ton décodeur respecte le Codec ID et applique le bon format.
2. Le CRC échoue et tu rejettes la trame. Le CRC-16 de Teltonika utilise le polynôme 0xA001 (CRC-16/IBM, « IBM Bisync »), pas le CRC-16/CCITT standard. Si ta bibliothèque CRC n'est pas la bonne, tous les CRC échoueront même si la trame est correcte.
3. Le dispositif « envoie du 8E » mais des IOs manquent. Si tu as activé un IO dans la configuration mais qu'il n'apparaît pas, c'est normalement que l'IO requiert un autre IO préalable activé, ou requiert une connectivité CAN/BLE non connectée physiquement. Regarde la documentation du modèle pour voir les dépendances entre IOs.
4. Latence élevée et tu crois que c'est le réseau, mais c'est le codec. Codec 8E génère des trames plus grandes que Codec 8. Avec un plan de données très lent (2G en zones rurales) tu peux voir la différence. En 4G c'est négligeable.
Résumé
Si tu retiens deux idées :
- Codec 8E est le choix moderne par défaut : 2 octets pour AVL ID, variable length pour les capteurs, compatible avec tout l'écosystème actuel de Teltonika.
- Ton CRC est CRC-16/IBM, pas CCITT. Si ton serveur rejette des trames avec CRC invalide et que rien ne colle, commence par là.
Pour un guide officiel avec le détail byte par byte et les AVL IDs par dispositif, la wiki Teltonika a la référence complète (en anglais). Si tu te montes un décodeur maison, cette wiki + cette note devraient suffire pour une intégration propre.
Si tu as déjà du matériel Teltonika et tu veux une plateforme de gestion qui implémente déjà tous les codecs et traite les trames correctement, Fletaro est notre entreprise sœur SaaS qui le fait nativement. Ou si tu as besoin de matériel avec codecs correctement configurés d'usine, sur notre boutique nous l'envoyons préconfiguré pour une intégration standard.
