J’ai pas mal de questionnement avec RTKNavi. (tous les tests ont eu lieu à l’extérieur avec un ciel dégagé)
1/ Jusqu’à présent pour mesurer les débits avec ADCP et GNSS nous utilisions un vieux GNSS Leica connecté à Orphéon. Nous possédons un rover centipède dans le but de remplacer le vieux leica.
Pour cela, je connecte mon GNSS (rover) à mon PC et j’ouvre RTKNavi demo5b34L, je configure mon input et ma connexion NTRIP pour me connecter à la base centipède la plus proche. Je paramètre mon output sur un port COM virtuel afin de l’ouvrir dans l’applcatio de suvey (WinriverII dans ce cas)/
Le problème est que au bout de 10-15 minutes je suis toujours en FLOAT avec une précision (cf-capture écran) relativement correcte entre 0.5 et 1cm. Pas de passage en FIX.
Je peux vous joindre un fichier de commande que j’utilise (celui disponible ici Rover RTKLIB avec Interface | Centipede RTK ) . (j’ai essayé de modifier le rate measurement en le passant à 100ms, rien ne change).
2/Pour une autre application, j’ai récemment acheté une carte UM982 (nécessité d’avoir un compas + un GNSS), je pensais pouvoir utiliser RTKNavi, mais j’ai de gros problème de commande. En effet, la carte fonction très bien avec le logiciel constructeur (UPrecise) mais ne marche pas avec RTK navi (fenêtre blanche rien ne se passe alors que satellite et position avec Uprecise et même avec Ucenter). J’ai même télécharger la version 2.5 qui n’est pas une démo mais qui est la suite et qui normalement prend les récepeturs Unicore ? Est ce que quelqu’un à déjà utiliser ce genre de carte et l’utilisation via RTKNavi.
Merci d’avance à tous ceux qui prendront le temps de me répondre, si il y a besoin de plus de détail ne pas hésiter à m’en demander.
Réponse rapide :
Il vaut mieux utiliser le moteur de calcul intégré dans la puce Gnss, que celui de RTKNavi.
En gros, on récupère le flux d’une base en rtcm, on l’envoie à la puce Gnss, elle fait le calcul, et on récupère la position via en général un flux nmea qui revient de la puce.
L’application qui va faire le lien entre le réseau Centipede-RTK et la puce, c’est le client Ntrip. Sur un ordi avec Windows, ça peut être strsvr de la suite RTKLib. Sur Android, il y a des infos ici :
Pour le premier point, rtknavi doit avoir les observations du rover ainsi que les observations de la base pour calculer une solution. Il faut donc en premier lieu configurer le récepteur pour envoyer les observations brutes dans un format reconnu par rtknavi, qui peut être RTCM3.
Le récepteur doit ensuite être configuré en input stream et la base en base station (qui peut être NEAR/NEAR4 à condition d’envoyer la trame GGA via l’option “Transmit NMEA GGA to Base Station”.
Comme l’a dit Stéphane, le moteur de rtknavi est beaucoup moins bon et robuste que celui des récepteurs, le mieux serait de récupérer la trame GGA en rtk fix du récepteur.
C’est possible avec strsvr, l’entrée doit être le NTRIP client avec une base sélectionnée (pas de possibilité d’utiliser NEAR), la sortie le récepteur en ligne série et utiliser la fonctionnalité “Output Received Stream to TCP port” qui expose un serveur TCP qui peut être utilisé par d’autres applications pour récupérer le flux venant du récepteur.
Une autre option est de créer un port série virtuel ou en réseau qui permet à plusieurs clients de se connecter au même port série du récepteur : COM3 est le “vrai” port série, COM4 celui utilisé par strsvr pour envoyer les corrections au récepteur, COM5 utilisé par WinriverII pour récupérer la position corrigée via le message GGA produit par le récepteur.
Pour le second point, il faut vérifier la configuration de l’UM982 et ses messages envoyés via UPrecise. Le message GxGGA doit être activé. Le message HDT doit également être activé pour récupérer la boussole. Si WinRiver ne supporte pas un NMEA HDT fourni par le GPS il faudra ajouter un autre port série virtuel mirroir.
