Partenaires
Rechercher
Accueil > Documentation technique > télécommunications > nouveau programmateur synchronisé sur le GPS
nouveau programmateur synchronisé sur le GPS
par -
A partir de l’idée de Patrice Ulrich décrite dans l’article précédent, un nouveau modèle aux fonctionnalités élargies a été conçu par Senthuran Anton, élève ingénieur électronicien en apprentissage à la DT, en collaboration pour la partie mécanique avec Louis Rey-Grange, également apprenti au sein de notre Bureau d’Etudes.
La fonction de base reste de n’activer l’alimentation des équipements de télécommunication que sur des périodes pré-programmées pour diminuer les besoins énergétiques globaux de la station. L’avantage par rapport aux programmateurs du commerce est d’éviter toute dérive horaire par synchronisation sur l’heure GPS du récepteur GPS pour lequel la station a été créée (le récpetur GPS doit émettre un message NMEA de type ZDA toutes les secondes sur le port série raccordé au programmateur).
La première évolution par rapport au prototype de Patrice Ulrich a été la flexibilité dans le choix de la plage d’émission et l’accessibilité de la modification : avec 7 roues codeuses en face avant, deux pour les heures, deux pour les minutes et trois pour la durée en minutes, les possibilités vont largement au-delà des cas de figure que nous avons rencontrés dans la réalité.
Dans l’établissement du cahier des charges nous nous sommes souvenus de cas particuliers : lorsque l’Observatoire Volcanologique de la Soufrière en Guadeloupe a installé une station permanente sur La Désirade, la qualité du lien télécom ne permettait pas de garantir la transmission d’une journée entière de données en une fois. Les données étaient découpées en trois fichiers de six heures par jour. Nous avons donc également prévu de pouvoir émettre plusieurs fois dans la journée, en utilisant les valeurs de la dizaine de l’heure supérieure à 2.
| chiffre des dizaines de l’heure | nombre d’émissions journalières |
| 3 | 2 (00h et 12h) |
| 4 | 3 (00h, 08h et 16h) |
| 5 | 4 (00h, 06h, 12h et 18h) |
| 6 | 6 (00h, 04h, 08h, 12h, 16h et 20h) |
| 7 | 8 (00h, 03h, 06h, 09h, 12h, 15h, 18h et 21h) |
| 8 | 12 (00h, 02h, 04h, 06h, ...) |
| 9 | 24 (00h, 01h, 02h, 03h, ...) |
Dans le cas de ces émissions répétées, le nombre des minutes indique un décalage par rapport à l’heure ronde. Par exemple, l’affichage de 30:05 provoquera la mise sous tension des équipements à 00:05 et 12:05.
Mais on peut vouloir un décalage négatif. C’est le cas si le pc de terrain a besoin de cinq minutes pour démarrer avant de pouvoir récupérer les données du récepteur GPS et qu’on veut commencer ce transfert aussi rapidement que possible après la fermeture du fichier. C’est pourquoi, dans le cas d’activations multiples dans la même journée (chiffre des dizaines de l’heure supérieur à 2), le chiffre des unités de l’heure est interprété comme un signe moins dès qu’il est différent de zéro. Ainsi, l’affichage de 31:05 provoquera la mise sous tension des équipements à 23:55 et 11:55 [1].
La seconde évolution concerne l’ajout d’une horloge interne qui maintient « du mieux possible » le suivi de l’heure en cas d’absence de message horaire en provenance du récepteur GPS. Il existe plein de possibilités que nous n’imaginons même pas pour que ce signal horaire disparaisse alors que le récepteur GPS acquiert toujours des données (déconnexion par erreur lors d’une visite, câble grignoté par un rongeur, etc.). Il ne faut donc pas conditionner l’activation des équipements à la présence de ce signal. Dans cette configuration dégradée, la dérive d’horloge devrait rester acceptable pour nos applications (par rapport à la fréquence de visite) : 2 minutes par an à 25°C selon la fiche du fabricant.
Nous avons également choisi d’ajouter un bouton poussoir pour forcer un passage « en mode manuel » ainsi que pour valider une nouvelle programmation :
lorsqu’un opérateur visite la station, il peut avoir besoin d’activer les appareils qui sont derrière le programmateur. Il serait risqué de modifier toute la programmation pour ça. Un appui de deux secondes (retour sonore du beeper avec un bip long lorsque l’appui est pris en compte) force le relais en mode passant pour une heure, quelque soit la programmation. L’opérateur peut interrompre l’alimentation avant que cette heure ne soit écoulée, par un second appui long sur le même bouton (retour sonore de deux bips brefs lors de la prise en compte). S’il oublie de repasser en mode programmé avant de quitter le site (le mode programmé est signalé par un flash rouge toutes les 8 secondes), l’appareil s’y remet tout seul au bout de cette heure de mode manuel. Si au contraire l’opérateur n’a pas fini son travail durant ce laps de temps, un signale sonore « insistant » (un bip toutes les deux secondes) le prévient dans les dernières trente secondes que l’alimentation va se couper. Durant cet intervalle de 30 secondes, un appui long sur le bouton relance une heure de mode manuel.
la lecture des roues codeuses se fait au passage du mode manuel vers le mode programmé. Ainsi, même si l’opérateur ne souhaite pas travailler sur les équipements en aval du programmateur, sa nouvelle programmation ne sera prise en compte qu’après deux appuis longs sur le bouton poussoir. Il peut contrôler la prise en compte de sa programmation par le clignotement des LED verte (pour l’heure de démarrage) et orange (pour la durée) qui reproduit les chiffres indiqués (1 flash pour 1, 2 pour 2, etc sauf pour 0 qui est codé en 4 clignotements rapides _afin que ça ne dure pas trop longtemps).
Lorsque le relais est passant (donc que les appareils en aval du programmateur sont sous tension) la LED verte clignote lentement (un flash toutes les 8 secondes). Lorsque le relais est ouvert, rien ne signale la présence d’une tension en entrée du boîtier (pour éviter de consommer de l’énergie). La consommation du programmateur dans ce mode est de 5mA sous 12V.
La dernière indication qui nous a paru pertinente pour l’opérateur sur le terrain concerne la réception effective d’une indication temporelle en provenance du GPS. Après l’information sur la valeur des roues codeuses lue par le boîtier (clignotement des LED verte et rouge), le programmateur indique qu’il a reconnu une trame NMEA de type ZDA [2] depuis le passage en mode manuel (premier appui sur le bouton poussoir) par deux bips longs (doublés de flashes synchrones de la LED verte). Sinon quatre bips brefs (doublés de flashes synchrones de la LED rouge) sont émis et signifient qu’aucun message n’a été reçu. Six bips brefs (doublés de flashes synchrones de la LED rouge) signifient que le message reçu n’est pas celui attendu (l’opérateur doit revoir sa programmation du récepteur GPS).
La lecture des roues codeuses et les retours vers l’opérateur se font non seulement au passage en mode programmé mais également à la mise sous tension du boîtier. Dans le cas où un opérateur trouverait une station totalement hors tension et rétablirait l’alimentation générale, il ne serait pas anormal d’entendre les bips d’alerte sur l’absence de trame NMEA puisque le boîtier démarre plus vite que le récepteur GPS qui fournit cette trame.
Le boîtier retenu nous a intéressé en dépit de son poids parce qu’il garantissait une bonne protection de l’électronique aux conditions difficiles du terrain (poussière, humidité, fuites d’eau, animaux, etc.) tout en autorisant un accès facile à la programmation. Le couvercle sur charnière avec sa vitre permet de voir les roues codeuses et les LED sans ouvrir le boîtier. Ces mêmes éléments mis directement en face avant nous auraient posé de nombreux problèmes d’étanchéité, d’autant que les roues codeuses n’ont aucune étanchéité intrinsèque. Même si nous ne garantissons pas d’avoir maintenu l’IP66 d’origine du boîtier, nous estimons que le produit final devrait faire bonne figure sur le terrain.
Les entrées (alimentation 9-72V et DB9 femelle pour la liaison série 9600bd 8N1 pour le message NMEA ZDA) sont à gauche de la fenêtre. La sortie est à droite. Il s’agit d’une paire d’embases banane sur lesquelles on peut, outre enficher des prises banane, insérer un fil dénudé ou une cosse plate latéralement.
Enfin, une clef est livrée avec le boîtier pour déverrouiller le couvercle, mais cela peut parfaitement se faire avec un tournevis plat.
post scriptum :
Ce projet a bénéficié du soutien de nombreuses personnes de la DT. D’abord les maîtres d’apprentissage de Senthuran et Louis, respectivement Nadir Amarouche et Nicolas Geyskens, qui ont jugé le projet adapté à l’apprentissage ; ensuite Oualid Aoudji s’est occupé de l’implantation effective des composants CMS sur les cartes électroniques, et Benoît Arnold du câblage et de l’intégration finale des boîtiers. Comme toujours depuis que l’activité GPS est arrivée à la DT, l’atelier de mécanique a rendu des menus services au projet qui lui ont fait gagner beaucoup de temps.
[1] Le chiffre des dizaines de minutes pour l’heure de départ est considéré comme nul au-dessus de 5, ce qui se vérifie sur le retour lumineux des roues codeuses.
[2] nous avons eu la surprise de constater la coexistence de deux entêtes différentes pour un même message NMEA : $GPZDA et $GNZDA. Les deux premiers caractères après le $ indiquent le type d’appareil qui fournit le message. Avec le temps, le GPS a fait place au GNSS. Du coup, nous avons imaginé que ce programmateur pouvait intéresser d’autres équipements capables de donner l’heure. Le test d’entête ne se fait donc que sur le $ et les trois caractères d’identification du message. En ultime précaution, le message ZDA n’est pris en compte que si l’année indiquée est supérieure à 2010 : un récepteur GPS sans antenne peut se croire en 1981, origine du temps GPS.
