Nouveau sur ce terrain, je cherche à acquérir du matériel pour créer base en Grèce qui servira à alimenter différents projets dont Centipède ainsi qu’un rover pour du radio mapping et plus tard Panoramax.
Pour avoir une bonne fiabilité avec un budget contenu, j’envisage la configuration suivante :
Base RTK (installée sur un toit)
Récepteur GNSS : ZED-X20P ou UM980
Unité de calcul : Raspberry Pi 3/4
Rover (d’abord à vélo, puis en voiture)
Récepteur GNSS : ZED-X20P ou UM980 (dongle USB)
Connectivité : smartphone
Unité de calcul (optionnelle) : Raspberry Pi X
Le ZED-X20P étant récemment sorti, existe-t-il des améliorations par rapport à l’UM980 ? Les fiches techniques sont très similaires ; j’opterais pour l’UM980, qui est moins coûteux, si la différence de performance n’est pas significative.
Ces antennes génériques feront-elles l’affaire ?
Je me présente je suis Jerome le fondateur de Drotek et nous sommes partenaire depuis très longtemps avec le projet Centipède. Nous travaillons actuellement sur une nouvelle gamme de produits RTK avec comme module le ZED-X20P de chez Ublox.
Nous avons terminé la production du boitier IP qui pourra être placé en extérieur par tout temps.
Côté carte électronique il nous reste le choix du SOM Linux à faire.
Si ca intéresse quelqu’un ou si vous voulez plus d’info n’hésitez pas.
Bonne journée.
Sympa de partager vos développements en cours à la communauté.
Le seul souci que je vois à cours terme c’est que les nouveaux modules ublox (gen 10 avec L5 + F20/X20) ne supportent pas GLONASS et étant donné le nombre de rovers et services PPP qui utilisent la constellation pour centipede on risque de trop limiter la compatibilité et la performance.
Le module F20P semble plus adapté à une base et certainement moins cher que les X20P, ils devraient être dispo environ 2 mois après la sortie des X20, donc d’ici novembre/décembre au plus tard (rien de fixé)
Le module bynav M10 me parait être un bon compromis pour centipede et il est bien plus accessible que les modules unicore et ublox. Au volume il est possible de les obtenir pour moins de 30 USD. La sensibilité est supérieure à celle des unicore mais inférieure à celle des ublox et probablement un moins bon multipath et filtrage global. Je trouve le support et la doc meilleure qu’unicore et quectel.
Pour le SoM une Rpi CM4 lite (version la moins chère possible, même sans wifi) permettrait une compatibilité très probablement directe avec rtkbase après intégration de la X20P. A voir comment vous connectez l’UART, par un port natif ou USB (convertisseur USB UART, pas terrible..)
Vous avez bien déporté l’antenne du boitier ?
J’émets l’hypothèse qu’à l’avenir des MCUs seuls avec une chip Ethernet comme la W5500 pourraient suffire, si l’archivage et positionnement initial se fait par le caster. Cela permettrait de réduire encore le coût des bases et leur consommation tout en améliorant la robustesse, mais le firmware n’est pas une partie négligeable.
Edit
Autre point que je viens de voir, les modules seuls ne peuvent pas émettre tous les messages que l’on émet avec la méthode actuelle sur rtkbase avec RTKLIB qui convertit le format propriétaire vers RTCM3 vers legacy+MSM7
Les messages 1004,1006,1008,1012,1019,1020,1033,1042,1046 sont manquants. Pour maximiser la compatibilité il faut que la base envoie ces messages
Tout d’abord merci pour ce retour intéressant.
Nous avons testé plusieurs marques de puces chinoises comme Quectel ainsi que d’autres comme Septentrio, Telit,…et les réultats sont meilleurs avec du Ublox.
On a été impressionné par le X20 qui semble être plus stable et robuste. A voir si la bande L6 porte un intérêt et pourquoi pas utiliser la F20 à la place.
Côté SOM on a prévu de mettre un connecteur de type CMx pour pouvoir y connecter une Raspeberry ou Radxa. Le prix reste très bas même si ce n’est pas comparable à un MCU.
Le jour où il y aura du code développé pour ce type d’architecture alors pourquoi faire une variante.
La bande L6 ne comporte pas d’autres signaux que ceux de corrections, moins précis que le RTK : Galileo HAS, MADOCA-PPP5 et CLAS, donc aucun intérêt pour une base RTK, de même pour la “bande L” qui ne contient que des données de correction de services privés (1525 MHz à 1559 MHz).
Alors dans ce cas nous allons choisir la puce ZED-F20P. Je vous tiens au courant dés la finalisation du PCB.
Nous avons déjà le boitier étanche ainsi que la partie fixation.
errata : la bande L6 contient un signal qui peut être utilisé pour du ranging, en complément du signal de données de correction HAS. Le signal Beidou B3I est également manquant sur le F20P et présent sur le X20P.
La bande L est cependant bien inutile pour une base et de toutes façons par encore normalisée ni en format démodulé ni en RTCMv3
Afin d’être le plus exhaustif et précis possible, j’ai construit un document qui regroupe toutes les informations sur les signaux des différents modules GNSS candidats pour construire des bases.Il n’y a pas de normalisation des bandes et signaux donc il devient complexe de bien comparer les signaux reçus par chaque récepteur. En sachant également que certains signaux ont des noms de bande et inversement et que certains fabricants ne détaillent pas si le signal est vraiment présent dans les messages RTCMv3 ce qui crée de la confusion.
Il a seulement été construit d’après les datasheets.
Cette première version est donc sujet à modifications basée sur des données de flux réels.
J’en avais commencé un pour le mettre dans la doc Centipede-RTK. Ce que tu as fait pourrait le compléter.
Par contre, tu indiques gnss.store comme source, et ça on ne peut pas si on veut que le résultat reste sous une licence CC BY-SA.
Ce projet est-il toujours d’actualité ?
A l’heure actuelle le meilleur module serait le ZED-X20P-10B, fourni uniquement par commande chez u-blox, sous NDA, et qui permet d’ajouter les 2 signaux civils GLONASS L1OF et L2OF. C’est très probablement le module utilisé par emlid pour le Reach RS4.
Il faut prendre les tableaux et spécifications des fabricants avec des pincettes, il arrive que certaines combinaisons de fonctionnent pas. Chez u-blox une capture d’écran provenant d’un module X20P débloqué montre ce plan de signal
