Structure d’une trame RTCM 3
Une trame RTCM 3 commence par l’octet 0xD3. Les bits suivants annoncent la longueur de la charge utile, puis viennent le type de message et ses champs. Un CRC24Q termine la trame. Le contrôle permet de rejeter un message corrompu avant de l’utiliser.
TCP transporte un flux, pas des messages. Une lecture peut couper une trame ou en regrouper plusieurs. Le parseur conserve donc les octets incomplets, recherche le préambule, vérifie la longueur maximale, attend la trame complète et contrôle le CRC avant le décodage.
Le caster peut diffuser sans décoder. Le parseur sert au monitoring et à l’archivage, mais il ne doit pas modifier le flux. Une erreur de parsing ne doit pas interrompre les rovers si les octets reçus restent valides.
Messages de station et d’équipement
Les types 1005 et 1006 décrivent une station de référence par ses coordonnées ECEF. Les champs signés sont convertis avec leur échelle, puis transformés en latitude, longitude et hauteur. Une vérification stricte de la longueur évite les accès hors limites observés avec un paquet partiel.
Les types 1007 et 1008 décrivent l’antenne ; le 1008 peut inclure un numéro de série. Le 1033 fournit des informations supplémentaires sur l’antenne et le récepteur. La disponibilité dépend de la configuration de la base.
Ces messages facilitent la supervision, mais ne remplacent pas une fiche de station vérifiée. Une chaîne absente ou générique comme ADVNULLANTENNA indique seulement ce que le récepteur a envoyé.
MSM et constellations GNSS
Les Multiple Signal Messages représentent les observations de plusieurs satellites et signaux selon une structure commune. Des familles distinctes correspondent à GPS, GLONASS, Galileo, BeiDou, QZSS ou SBAS. Les variantes MSM4, MSM5, MSM6 et MSM7 transportent des niveaux de détail différents.
Le choix dépend de la compatibilité et du service. Un flux multi-constellations augmente le nombre de satellites disponibles dans les environnements masqués, mais aussi le débit. Les intervalles de message doivent être testés avec les rovers.
Le sourcetable peut annoncer les types et fréquences, mais l’analyse du flux confirme ce qui est réellement transmis. Une alerte peut signaler l’absence prolongée d’une famille attendue.
Transport, latence et intégrité
NTRIP encapsule le démarrage de session avec des lignes textuelles, puis transmet le RTCM brut. La frontière entre en-tête et corps doit être détectée exactement. Ajouter un saut de ligne au flux ou le décoder en UTF-8 corrompt les trames.
Windows et Debian produisent les mêmes octets lorsque le programme utilise NetworkStream et des tableaux de bytes. Les problèmes attribués à l’encodage sont souvent des erreurs de découpage, de tampon, de réponse NTRIP ou une fermeture du client.
La latence peut être observée avec les horodatages internes des messages lorsque disponibles, mais elle exige une référence de temps cohérente. Le débit et l’âge du dernier paquet fournissent des indicateurs plus simples pour l’exploitation quotidienne.
FAQ RTCM
RTCM et RINEX sont-ils équivalents ?
Non. RTCM est principalement optimisé pour la diffusion temps réel, tandis que RINEX est un format d’échange de fichiers d’observations destiné au traitement différé et à l’archivage.
Pourquoi RTCM apparaît-il illisible dans un terminal ?
Parce qu’il s’agit de données binaires. Les afficher comme du texte produit des caractères incohérents. Il faut utiliser un parseur RTCM ou un affichage hexadécimal.
Le type 1006 donne-t-il la latitude directement ?
Non. Il transporte des coordonnées ECEF X, Y et Z, plus une hauteur d’antenne. Le logiciel effectue une conversion géodésique pour obtenir latitude, longitude et hauteur ellipsoïdale.