Partenaires

CNRS
RESIF
DT
UNAVCO Facility

Rechercher

sur ce site

sur web cnrs


Accueil > Documentation technique > Récepteurs > NetRS

Trimble

NetRS

par Olivier Charade - 21 février 2008 - modifié le 26 mars 2008

Récepteur dédié aux sites permanents, son interface par serveur Web est extrêmement facile àappréhender et àmanipuler. L’aide en ligne est très complète et un article « mode d’emploi » n’apporterait rien de plus.
Cet article vise àmettre en exergue certains aspects de ce récepteur qui nous semblent intéressants ou insuffisamment exploités. Il reprend en grande partie les points abordés lors de la session "nouveaux récepteurs" des journées techniques RENAG 2007.

La mise en route

Le plus difficile reste finalement le premier contact avec le récepteur pour lui donner (ou connaître) son adresse IP vers laquelle on pourra ensuite lancer n’importe quel navigateur.

La bonne façon consiste àdisposer d’un câble série droit qu’on branche entre le port série 1 du récepteur (l’unique connecteur en face avant) et le port série d’un ordinateur disposant d’un programme de dialogue avec le port série (par exemple HyperTerminal sous Windows, minicom sous Linux). La plupart des autres paramètres étant correctement configurés par défaut, il suffit de se souvenir de travailler à115 200 bauds ET sans contrôle de flux. Une erreur sur la vitesse entraîne un affichage illisible, une erreur sur le contrôle de flux empêche le dialogue par le clavier.

Le démarrage étant assez long, il est classique de louper les quelques secondes pendant lesquelles on peut prendre la main pour modifier la configuration. Cela n’empêche pas, le cas échéant, de connaître l’adresse IP prise par le récepteur comme le montre l’image suivante :

On peut alors, en utilisant un câble 10BaseT croisé, relier directement au récepteur un ordinateur dont on aura forcé l’adresse IP sur le même réseau (si l’on est pas très sà»r de ce qu’est un réseau ou sa classe, le plus simple est de prendre l’adresse IP du récepteur augmentée ou diminuée de 1 sans jamais utiliser 0 ou 255).

A remarquer que dans le cas d’une configuration dhcp où il ne trouverait pas de serveur dhcp pour lui répondre, le récepteur garde sa précédente adresse.

Une astuce valable pour d’autres équipements en dhcp est d’utiliser un « sniffer » comme wireSharck (anciennement Ethereal) pour assister en direct àla demande d’IP et àson attribution. Même sur un réseau chargé cela se voit assez bien (attention àbien se trouver sur le même réseau local, surtout pas configuré en VPN).
demande d'@IP dynamique

Lors d’une première configuration je conseillerais de mettre en place le « port advertising » vers un ordinateur du laboratoire, ce qui permettra toujours de récupérer l’IP du récepteur.

Receiver Status

La seule remarque est de se méfier de la possibilité de donner des noms àdouze caractères : au final, après les diverses conversions (T00->dat->RINEX), on se retrouve avec un nom de fichier RINEX qui ne répond plus au standard. Le fichier peut être ignoré par certains logiciels de traitement.

Attention : le nom par défaut est sur douze caractères !

Satellites

Rien àdire. La rubrique àsurveiller est Tracking.

Data Logging

L’intérêt majeur de ce récepteur réside dans la possibilité d’enregistrer simultanément plusieurs sessions sur ces espaces mémoires séparés où les plus vieux fichiers s’effacent au profit des nouveaux.

Dans la configuration initiale, seul un espace réservé global de 1Mo est préservé (sans doute pour que la gestion du système de fichiers garde ses aises). Toutes les sessions que l’on pourra créer ensuite seront en concurrence pour l’espace mémoire restant si on ne leur attribue pas spécifiquement une zone d’une certaine taille. Cela se configure dans la rubrique AutoDelete.

La gestion de l’arborescence des données en mémoire semble très diverse parmi les collègues. Notre conseil est de créer des sous-répertoires dès qu’on risque d’avoir trop de fichiers mélangés pour permettre àun opérateur de comprendre facilement ce que contient le récepteur : s’il ne produit qu’un fichier par jour, un répertoire mensuel est suffisant. Si il y a des fichiers horaires, le sous-répertoire jour se justifie. Si différentes sessions travaillent simultanément, un sous-répertoire par session clarifie les choses. Même deux sessions, une journalière à30 secondes et une horaire àune seconde, seront plus faciles àobserver avec un sous-répertoire jour qui contiendra le fichier journalier à30 secondes et le sous-répertoire de session pour les fichiers horaires àune secondes.

Nous avons vérifiés que des données à30 secondes sont produisent bien les mêmes fichiers RINEX que des données àune seconde ré-échantillonnées à30 (àl’indicateur de vérouillage de phase près). La décision de faire co-exister les deux types de sessions repose donc sur des contraintes de temps de transfert des données àune seconde, ou d’autonomie mémoire du récepteur par rapport aux périodes de visite potentielles.

La rubrique Power Saving ne sera sans doute pas utilisée dans nos applications qui cherchent au contraire en enregistrer le plus de données possibles.

Receiver Configuration

Le point utile souvent ignoré est ici la rubrique Configuration Files. Lorsqu’on a passé du temps àconfigurer son récepteur, il est agréable de pouvoir sauver cette configuration dans un fichier qui se trouvera non seulement àl’intérieur du récepteur (si on doit déconfigurer temporairement le récepteur pour lui faire faire autre chose ailleurs, il sera facile de le ré-installer sur son site d’origine) mais qu’on aura également téléchargé sur un ordinateur. Non seulement il sera quasi-immédiat de remplacer le récepteur en cas de panne (au moins pour l’aspect configuration), mais il sera assez aisé de propager la configuration si l’on est en train d’installer tout un réseau (il n’y aura que le nom de site et peut-être l’adresse IP àchanger).

Internet

Si tout l’intérêt du récepteur NetRS réside dans son interface Web, il ne faut pas oublier qu’il est par défaut ouvert « Ã tous vents » et, sans sombrer dans la paranoïa, toute personne ayant accès au réseau sur lequel se trouve le récepteur peut effacer des données ou carrément en changer la configuration.

La mesure la plus simple réside dans la rubrique IP Filtering qui propose de rejeter toutes les tentatives de connexion qui ne proviennent pas d’adresses IP pré-définies. Pour éviter toute mauvaise surprise, lorsqu’on amorce la procédure (Add New Range), c’est l’adresse IP de la machine àpartir de laquelle on travaille qui est proposée par défaut comme adresse autorisée !

On peut ensuite définir des comptes et des mots de passe (rubrique Security) pour n’autoriser l’effacement des données ou le changement de configuration qu’àcertains comptes (ce qui n’empêche pas de laisser libre l’accès en lecture aux données). Mais dès qu’il y a des mots de passe, il faut passer àdes connexions sécurisées sans quoi ces mots de passe sont des secrets de Polichinelle (voir le « sniffer » plus haut). Il convient, avant de passer en https, de vérifier que tout le routage réseau entre vous et votre récepteur est configuré pour laisser passer ce protocole, sous peine de ne plus pouvoir accéder du tout àson récepteur une fois le bouton OK cliqué ! C’est en particulier la triste expérience sur j’ai faite sur une connexion par satellite où je n’étais absolument pas maître des routers.

Input/Output Configuration

C’est la première rubrique àregarder lorsqu’on a un problème de connexion sur des ports série de ce récepteur qui ne sait dialoguer que sur IP. Par défaut les ports série 2 et 4 (prévus plutôt pour une connexion directe àun ordinateur) ainsi que le port série 3 (prévu plutôt pour une connexion via modem) sont configurés en PPP (Point to Point Protocol) : très bien décrite dans la documentation Trimble, la procédure d’établissement d’une liaison PPP sur la liaison série permet d’attribuer àl’ordinateur une adresse IP. L’utilisateur peut alors lancer son navigateur sur l’adresse IP du serveur PPP.
configuration PPP NetRS
Si le récepteur a servi àdifférents essais, il peut être dans une configuration qui ne permet plus la liaison PPP dans la configuration que l’on est en train d’essayer, d’où l’utilité d’accéder àcette rubrique.

Une possibilité que je trouve très intéressante réside dans la rubrique Port Advertising : il s’agit de définir une machine vers laquelle le récepteur va automatiquement, et àintervalle régulier, envoyer les informations réseaux qui permettent de communiquer avec lui.
listening to NetRS
L’intérêt est de récupérer l’adresse IP d’un récepteur configuré en DHCP. Il peut être plus facile, selon la politique de l’administrateur réseau, d’installer le récepteur en DHCP que d’obtenir une IP fixe. Cela permet également, dans le cas d’un accès Internet par un fournisseur d’accès grand public, de récupérer l’adresse IP publique du router en tête du réseau local privé où se trouve le récepteur. Mais il faut avoir déjàconfiguré la redirection de port sur le router pour que, par exemple, un accès sur son port 8081 renvoie sur l’adresse IP fixe mais privée du récepteur NetRS.
Enfin, àdéfaut d’avoir accès au récepteur (IP dynamique sur un réseau privé), cet outil permet au moins de savoir qu’il est « vivant ».

Security

C’est ici qu’on crée les comptes avec mot de passe et niveaux d’accès dont nous avons parlé àla rubrique Internet. Si on se contente de créer un contrôle d’accès en laissant tel quel le compte sysadmin, tout le monde (àcommencer par les moteurs de recherche), sait que le mot de passe associé est netrs !

Firmware

Comme tout récepteur, il propose la possibilité de mettre àjour son « firmware ». Comme pour un fichier de configuration, cela se passe le plus simplement possible en deux étapes : d’abord le chargement depuis l’ordinateur sur lequel tourne le navigateur vers le récepteur, puis l’installation àproprement parler. La simplicité ne doit pas faire oublier la dangerosité de l’opération en cas de problème (qui ne devrait pas exister mais bon...). il vaut mieux d’abord être sà»r qu’on a besoin des avantages de la mise àjour et mettre en balance ces avantages avec l’éventuel aller-retour pour échanger le récepteur.

Programmatic Interface

Nous abordons ce que je considère comme la possibilité la plus intéressante de ce récepteur (point de vue de l’ingénieur) mais qui est généralement totalement ignorée car documentée uniquement DANS le récepteur. De plus cette rubrique ne sert àrien dans le fonctionnement du récepteur et n’est làqu’àtitre de démonstration des possibilité de dialogue en ligne de commande avec l’appareil : tout ce qu’on obtient comme information sous une forme texte rébarbative en cliquant sur les différentes commandes proposées a déjàété vu sous une forme bien plus conviviale dans les autres rubriques. Mais justement, ce qu’on trouve ici correspond exactement aux besoin d’opérations automatiques effectuées par un programme script et non d’un « opérateur » humain.

La documentation en ligne propose des exemples en Perl, mais ce sont les exemples en ligne de commande Unix qui sont, àmon avis, le plus utile dans la communauté, car tout le monde a déjàécrit un shell-script pour éviter de taper trop souvent le même enchaînement de commandes. Un script Perl est beaucoup plus délicat d’approche.

L’utilisation en ligne de commande est basée sur la commande curl disponible sur la plupart des systèmes Unix (si elle ne l’est pas encore, l’administrateur de votre machine peut très facilement l’installer). Les captures d’écran suivantes montrent le cheminement depuis la démonstration d’une commande dans la rubrique Programmatic Interface jusqu’àla ligne de commande curl dans un terminal Unix, avec l’étape intermédiaire pédagogique de la réponse àtravers un navigateur classique de l’URL qu’on emploie avec le navigateur en mode texte curl.

initiation aux commandes curl

Voici maintenant un exemple où je fais lister les répertoires àla racine du serveur depuis un terminal sous bash :

charade@gpscope:~$ curl "http://200.0.1.2/prog/Show?LoggedFiles&directory=/"
<Show LoggedFiles directory=/>
Directory name=200712
Directory name=200801
Directory name=200802
<end of Show LoggedFiles directory=/>
charade@gpscope:~$

On remarque la syntaxe XML de la réponse. A partir de ce résultat, j’en déduis la commande bash pour faire lister d’un coup tout ce que contiennent les répertoires de premier niveau du serveur (j’ai remplacé les listes trop longues par des points de suspension) :

charade@gpscope:~$ for dd in `(curl "http://200.0.1.2/prog/Show?LoggedFiles&directory=/" | awk -F= '/^D/{print $NF}') 2>/dev/null`;do
> curl "http://200.0.1.2/prog/Show?LoggedFiles&directory=/$dd"
> done
<Show LoggedFiles directory=/200712>
LoggedFile name=INSU200712280000b.T00 size=3837437
LoggedFile name=INSU200712290000b.T00 size=6774576
LoggedFile name=INSU200712300000b.T00 size=6768348
LoggedFile name=INSU200712310000b.T00 size=6775210
<end of Show LoggedFiles directory=/200712>
<Show LoggedFiles directory=/200801>
LoggedFile name=INSU200801010000b.T00 size=6773845
...
LoggedFile name=INSU200801310000b.T00 size=6844807
<end of Show LoggedFiles directory=/200801>
<Show LoggedFiles directory=/200802>
LoggedFile name=INSU200802010000a.T00 size=539593
...
LoggedFile name=INSU200802200000b.T00 size=6722210
<end of Show LoggedFiles directory=/200802>
charade@gpscope:~$

La redirection des messages d’erreur ( 2>/dev/null ) évite l’affichage des barres de progression.
Nous sommes ici àla limite de ce qu’il est raisonnable de faire en ligne de commande. Il vaut mieux ensuite passer àun shell script. Mais on voit déjàcomment automatiser l’exploration de tous les niveaux de sous-répertoire éventuellement présents en testant si la ligne de réponse commence par « Directory » ou « LoggedFile ».
Trimble a prévu le téléchargement d’un fichier avec une commande du genre :

curl "http://200.0.1.2/prog/Download?LoggedFiles&path=/200802/INSU200802010000a.T00 > INSU200802010000a.T00

Il est, àpartir de là, assez simple de compléter la boucle précédente pour effectuer un téléchargement systématique de tous les fichiers de données présents sur le récepteur. Bien sà»r on préfèrera généralement filtrer le nom des fichiers en fonction d’une session particulière. Le cas classique est d’avoir un script automatique de récupération de la session a qui produit des fichiers journaliers a 30 secondes, script qui sera lancé tous les jours (et qui supprimera les fichiers côté serveur au fur et àmesure de leur transfert -après vérification de la taille a l’arrivée- pour éviter de tout re-télécharger chaque jour) et de garder sous le coude un script pour la récupération d’un jour donné (ce sera celui du séisme) de la session b qui produit des fichiers horaires àune seconde.

Mots-clés

NetRS