Galileo High Accuracy Service goes live!
Nécessite des récepteurs compatible avec le signal E6-B
Faq : FAQ | European GNSS Service Centre
Documentation : Programme Reference Documents | European GNSS Service Centre
Ou une connection internet et un client NTRIP 2.0 
https://www.gsc-europa.eu/galileo/services/galileo-high-accuracy-service-has/internet-data-distribution
1 Like
Il faut aussi que le récepteur GNSS soit capable d’utiliser ce type d’informations…
Un récepteur basé sur RTKLib oui.
Il existe probablement d’autres puces que le F9P qui permettent de le faire.
Une piste sur le forum U-Blox ?
Support for Galileo High Accuracy Service (HAS)
Le service HAS en phase 1 fournit 3 types de corrections, pour l’ensemble des satellites GPS et Galileo : position du sat, horloge du sat et phase du sat (nombre de cycles d’onde effectivement sortis du sat). Ces informations sont valables n’importe où sur la planète. Un calcul de type PPP (positionnement ponctuel précis) doit permettre d’obtenir une précision de 20 cm en horizontal et de 40 cm en vertical en 300 secondes.
La future phase 2 du service HAS fournira en plus une grille de correction ionosphérique. La durée de convergence devrait être réduite à 100 s pour la même précision.
La précision peut paraître limitée. Néanmoins, dans une présentation de 2021, on voit les figures suivantes :
Ceci suggère qu’on pourrait atteindre des précisions bien meilleures, jusqu’à quelques centimètres, sur des temps plus courts ou équivalents.
Quand on regarde les graphiques ci-dessus, on voit que l’objectif 20-40 cm, c’est uniquement en utilisant les satellites Galileo avec un algorithme PPP sans résolution des ambiguïtés entières (AR : Ambiguity Resolution). La résolution des ambiguïtés entières consiste à déterminer à moins d’une longueur d’onde radio (~20 cm sur la fréquence L1) la position du rover par rapport à une référence. D’habitude, le calcul est fait par rapport à une station de référence à proximité (<50 km). Dans le cas du PPP-AR, c’est par rapport à chaque satellite lui-même. La difficulté est alors de déterminer les ralentissements dus à l’atmosphère (ionosphère et troposphère=humidité de l’air). Dans la phase 1 de HAS, sans informations sur la ionosphère ni la troposphère, on voit qu’avec GPS+Galileo et algorithme PPP-AR, on pourrait atteindre 3 cm en horizontal en 2 minutes.
Les corrections de HAS sont dite de type SSR (State State Representation). Explications sur rtklibexplorer. Comme elles sont de nature différente des corrections d’une base terrestre, elles ne transmettent pas les mêmes informations et ne sont pas nécessairement supportées par les récepteurs.
Il y a plusieurs formats pour transmettre les corrections SSR. Le premier est le format RTCM où des séquences sont prévues pour ces corrections. Les séquences ne sont pas supportées par la puce F9P de U-blox. Galileo utilise le format compact SSR (cSSR). C’est déjà le format utilisé par le Japon pour les corrections QZSS. Le F9P supporte ce cSSR mais il semble y avoir de légères différences avec le cSSR de HAS (forum ublox). Il faudrait faire une moulinette pour passer de l’un à l’autre. Enfin, il faut évoquer le format SPARTN soutenu par u-blox. Pareil, il faudrait un convertisseur depuis le cSSR de HAS vers SPARTN.
Il y a un point qui est rarement précisé, c’est si la précision annoncée est valide aussi bien pour du positionnement statique que dynamique.
J’imagine néanmoins qu’il faut conserver la continuité de réception en dynamique. Si on passe sous des arbres, on risque plus ou moins de réinitialiser la convergence.
Sinon, dans les réalisations pratiques du QZSS, on trouve:
- la puce D9C de U-Blox reçoit par radio les corrections QZSS et génère la séquence qui va bien pour le F9P. On aimerait bien la même pour HAS.
- le module Drogger VRSC qui reçoit les corrections QZSS et les utilise pour générer une station virtuelle sur terre, à proximité du rover. Pour le moment, en l’absence de corrections atmosphériques, je ne sais si le principe serait efficace avec HAS.
RTKLib supporte les corrections SSR à travers le format RTCM mais pas le cSSR. Par contre, un portage le fait : CSSRlib. Un commit récent ajoute le support de Galileo HAS. Un volontaire pour tester ? 
Il est beaucoup question de PPP.
Donc c’est en statique ??
Non, le PPP (Precise Point Positioning) n’implique pas d’être statique. Par contre, ça a besoin de capter les satellites en continu pour converger vers une bonne précision. En dynamique style voiture, à chaque passage sous un pont, un arbre, au pied d’un immeuble… l’incertitude risque de bien réaugmenter et ne jamais atteindre de très bonnes valeurs. En terme de vitesse de convergence, je pense qu’on ne sera jamais au niveau du RTK terrestre. Mais pour de l’agriculture en terrain dégagé, ça pourrait être suffisant.