RTKLib - RTKPOST & RTKNAVI - paramétrages communs

Ces paramétrages sont identiques dans leurs définitions pour les modules RTKPOST et RTKNAVI. Pour autant, ces deux modules ont des usages distincts et stockent leurs configurations dans des fichiers séparés. Il faudra donc effectuer les paramétrages module par module.

Cette page comprend plusieurs sections. Il est conseillé de les lire dans l’ordre avant de passer à un premier calcul.

• Paramétrage initial. Le logiciel utilise un fichier de calibration des antennes. Il est indispensable de le renseigner avant tout calcul, sauf dans le cas d’une mesure de type « SINGLE » (à ne pas confondre avec PPP).
• Paramètres de la mesure. Il faut préciser ou valider le type d’antenne utilisé ainsi que la position de la station de référence dans le cas d’un positionnement différentiel.
• Export des résultats: Sélection et format des résultats à exporter.

Le calcul de position se fait au centre de phase de l’antenne, qui n’est pas confondu avec son centre géométrique ou le point dit ARP (Antenna Reference Point) situé généralement en bas de l’antenne. Par ailleurs, ce centre de phase varie en fonction du satellite utilisé  et de la position du satellite. Il est donc nécessaire de définir la position de ce centre de phase en tenant compte de toutes les variables, ce qui est fait en utilisant un fichier de calibration des antennes mis à jour périodiquement.

Ce fichier (igs20.atx en 2024), produit par l’IGS est disponible sur le site de la NOAA (https://www.ngs.noaa.gov/ANTCAL/LoadFile?file=ngs20.atx) ou dans le répertoire du logiciel (version récente de RTKLib Demo5).

Depuis l’onglet Options / Files du module RTKPOST ou RTKNAVI, il faudra le sélectionner pour les 2 lignes (numérotées 1 et 2 sur le graphique de gauche), éventuellement sauvegarder la configuration (3) et valider (4). Pour que le fichier soit effectivement pris en compte, il faudra quitter le logiciel et le relancer. En principe, cette configuration sera conservée lors des utilisations ultérieures.

Rappel important: c’est à faire depuis le module RTKPOST et RTKNAVI si on utilise les deux modules.

Type et hauteur d’antenne: Le paramétrage s’effectue de la même façon sur le mobile (Rover) et la base (Base Station), quand une base est utilisée depuis l’onglet Options / Positions du module RTKPOST et du module RTKNAVI.

• En sélectionnant * dans la liste déroulante (première entrée de la liste), le logiciel ira chercher automatiquement le type d’antenne et la hauteur d’antenne dans le fichier RINEX. C’est la méthode la plus simple.
• Sinon, on peut dérouler la liste pour chercher l’antenne et la sélectionner, sans omettre de renseigner la hauteur d’antenne. Cela peut être nécessaire si le fichier RINEX est mal formaté ou si l’antenne ne porte pas un nom conforme à celui figurant dans le fichier ATX.

Depuis le module RTKNAVI, il n’est pas obligatoire de fixer les coordonnées exactes de la station de base dans l’onglet Positions. Cependant, il peut y avoir deux cas de figure:

• La position a été fixée précisément sur le récepteur de base. Dans ce cas, les positions calculées pour le mobile par RTKNAVI seront exactes.
• Cela n’a pas été fait et les positions seront inexactes dans l’absolu mais homogènes entre elles. Cela peut être suffisant pour certaines applications.

Format de la solution: Plusieurs solutions possibles, quel que soit le type de calcul

• Coordonnées Latitude / Longitude  / Hauteur. Ces valeurs utilisent l’ellipsoïde WGS84, aucun autre ellipsoïde n’étant disponible dans cette version du logiciel sauf à recompiler le code source.
• Coordonnées ECEF (XYZ). C’est le format de sortie que nous privilégions du fait de l’impossibilité de sélectionner un autre ellipsoïde que le WGS84 et en particulier IAG-GRS80.
• Vecteur de la ligne de base E/N/U (East / North / Up) sur l’ellipsoïde WGS84 (pour un calcul différentiel).
• NMEA0183. Une trame $GPRMC et une trame $GPRMC par position calculée (fichier avec extension .nmea)

Output Header/ Process Option / Velocity:

• Nous recommandons de garder au minimum l’affichage de l’entête du fichier résultat (header) et les options de calcul sur ON, ne serait-ce que pour vérifier les configurations d’antenne.
• L’affichage de la vitesse est fonction des besoins de l’utilisateur. Il peut être utile pour repérer les moments ou le récepteur était en mouvement ou immobile.

Time Format / nombre de décimales: C’est l’heure de mesure de chaque époque.

• ww ssss GPST.
  • ww est le numéro de la semaine GPS (GPS Week Number), la semaine 0 débutant le dimanche 6 janvier 1980 à 00:00:00 UTC.
  • ssss est le Temps écoulé en secondes depuis le début de la semaine GPS (qui commence au dimanche).  Ce nombre varie de 0 à 604799 (7 jours × 24 heures × 3600 secondes)
  • GPST : Système de temps GPS (GPS Time). Le temps GPS est un système temporel continu utilisé par le système de positionnement GPS. Il est lié au Temps universel coordonné (UTC), mais ne contient pas de secondes intercalaires (le GPS Time est en avance sur l’UTC d’environ 18 secondes en 2025, en raison des secondes intercalaires ajoutées à l’UTC).
  • NB: La notion de seconde intercalaire devrait disparaitre d’ici à 2035, ce qui probablement posera des soucis de mises à jour des logiciels et récepteurs GNSS.

• Heure / Minute / Seconde en temps GPS (hh:mm:ss GPST) ou en temps UTC (hh:mm:ss UTC)
• Heure / Minute / Seconde en temps japonais (hh:mm:ss JST). C’est une donnée spécifique formatée pour correspondre aux usages locaux du Japon d’ou est originaire ce logiciel (par exemple, la gestion des fichiers GNSS japonais, comme QZSS).

Lat / Long format : Degrés centésimaux ou DMS, avec la possibilité d’insérer un caractère séparateur entre les champs (par défaut, c’est un espace)

Output Single if Sol Outage / Max Sol Std (m).

• Lorsque Output Single if Sol Outage est activé, RTKlib essaie en priorité de calculer une solution différentielle fixe ou flottante. Si cela échoue (par exemple, en cas de manque de corrections différentielles ou d’observations insuffisantes), il bascule automatiquement sur une solution Single. La solution Single est beaucoup moins précise car elle est basée uniquement sur les données brutes GNSS, sans corrections externes. Il est déconseillé  de laisser cette option activée, sauf besoin spécifique car les erreurs peuvent atteindre plusieurs mètres. Pour limiter cette dérive métrique, on peut limiter l’utilisation de cette solution en fixant une valeur maximale à Max Sol Std (écart type maximum accepté pour cette solution).
• Si l’option est désactivée, alors en cas d’absence de solution différentielle, RTKlib ne génère aucune solution pour les périodes concernées, ce qui peut entraîner des interruptions dans les résultats.

Datum / Height:

• Cette version logicielle ne permet que l’utilisation de l’ellipsoïde WGS84. Il n’y a donc pas d’autre choix possible (sauf à recompiler la source).
• Il est possible de fournir des résultats en hauteurs ellipsoïdales ou en altitudes normales (appelée géodétiques par RTKLib). Dans ce cas, RTKLib utilise par défaut (Internal) le modèle EGM2008 et propose également les modèles EGM96-BE (15″), EGM2008-SE (2.5″), EGM2008-SE (1″) et GSI2000 (1×1.5″) qui est un modèle de géoïde du Japon.

Solution for static mode

• All : dans ce cas, le résultat sera un ensemble de toutes les positions calculées, ambiguïtés fixées ou non.avec les facteurs de qualités suivants: Q=1:fix,2:float,3:sbas,4:dgps,5:single,6:ppp. Faire sans précaution une moyenne de l’ensemble de ces positions peut s’avérer hasardeux.
• Single : Seule la dernière position est affichée.

NMEA Interval

• C’est l’intervalle en secondes entre chaque message NMEA qui sera généré.Pour générer des messages NMEA, il faut spécifier un fichier de sortie NMEA ou un port série où ces messages seront envoyés. Si cette configuration n’est pas faite, le champ de l’intervalle restera grisé.

Et pour finir, différentes possibilités de contrôle (résidus, tracs, …) qui ne demandent qu’à être testés.