Météo: NetAtmo, Weewx, OCW et APRS

Après quelques mois d'utilisation, la station NetAtmo s'avère être bien pratique en particulier pour son anémomètre que j'ai pu installer sur le pignon du toit pour avoir une bonne idée du vent pouvant être subi par le pylône. Le seul vrai problème réside dans l'absence de toute API permettant de l'interroger localement. 

Souhaitant pouvoir enregistrer les données sur mon serveur et les publier sur le site 'aprs.fi' voire sur une gateway APRS à venir, il m'a fallu passer par une passerelle à même de requêter le serveur NetAtmo, disposant d'une base de données et d'interface vers un service à même de publier sur le site 'aprs.fi' mais aussi compatible avec FreeBSD. Après quelques recherches, le logiciel 'weewx' est apparu être le candidat idéal.

L'installation s'avère être très simple si l'on suit la documentation. Quelques modifications dans la configuration de l'installation ont été apportées afin d'être compatible avec la logique FreeBSD et l'utilisation du répertoire '/usr/local/etc' pour la configuration. L'installation du module 'netatmo.py' est requis en notant que celui-ci ne gère qu'un capteur complémentaire et uniquement en température. 

La gestion complète de la station nécessite plusieurs modifications dont l'ajout des tables ad'hoc dans la base de données, la configuration des paramètres présents dans 'weex.conf' et dans 'skin.conf'. Une lecture attentive du guide de customisation - https://www.weewx.com/docs/5.1/custom/introduction/  - est absolument requise pour éviter de modifier les mauvais paramètres. 

Il sera aussi nécessaire de modifier le code du driver NetAtmo dans le répertoire './weewx/bin/user' après l'installation de l'extension pour définir explicitement l'adresse de chacun des capteurs actifs (hors celui de la station). 

Par défaut, la recherche s'effectue sur la première adresse trouvée dans l'espace de nom 'NAModule4' qui correspond à tous les modules complémentaires (et oui, pourquoi faire compliqué ...):

  'extraTemp1': '*.NAModule4.Temperature',
  'extraHumid1':'*.NAModule4.Humidity',

Dans l'hypothèse d'une station disposant de modules complémentaires, cette configuration sera modifiée pour indiquer l'adresse de chaque module actif (ici masquée):

  'extraTemp1': '03:00:00:xx:xx:xx.NAModule4.Temperature',

  'extraHumid1':'03:00:00:xx:xx:xx.NAModule4.Humidity',

  'extraCo21':  '03:00:00:xx:xx:xx.NAModule4.CO2',

  'extraTemp2': '03:00:00:yy:yy:yy.NAModule4.Temperature',

  'extraHumid2':'03:00:00:yy:yy:yy.NAModule4.Humidity',

  'extraCo22':  '03:00:00:yy:yy:yy.NAModule4.CO2',

Ici, deux capteurs complémentaires sont déclarés par leur adresse 'MAC' qui tient lieu d'identifiant en notant l'ajout de la déclaration des capteurs de CO2 par ailleurs inscrits dans le schéma de la base de données. Après configuration des paramètres d'envoi des données sur le service OCW, les données apparaissent sur la carte APRS du site 'aprs.fi'.

Ma balise APRS a disparu du site car la passerelle APRS de la station F6KBS qui me relayait apparaît être inactive. Ce qui m’amènera à installer ma propre passerelle IP. En attendant les semaines à venir vont être bien occupées avec la suite de la remise en état du boitier de commande du FS5000, la reconstruction du MCR1 en 'kit', la reconstruction du pylône Mors et la mise à jour de mes récepteurs SDR autonomes avec la version OpenWebSdr Plus qui, si elle fonctionne bien, sera transférée sur un Raspberry Pi5.

APRS: LightAprs - suite 5

Ma balise APRS-Light m'a encore donné quelques soucis liés à une trop forte condensation dans le coffret après les pluies intenses de la seconde semaine de mai. Le perçage de quelques trous dans le coffret et le séchage de l'ensemble du circuit aura permis de redémarrer la balise jusqu'à ce que la modulation AFSK cesse d'être transmise, ceci coïncidant avec plusieurs jours de grand vent.

Après démontage et tests, la panne a été identifiée comme liée au module DRA818V. Le démontage du capot de celui-ci permet de suivre le signal BF jusqu'à l'un des pions, lequel paraît être bizarrement soudé. De fait, les billes de soudure s'écrasent à la moindre pression d'une pointe de test ultrafine.

L'examen à la binoculaire au plus fort grossissement dévoile un montage grossier du composant dont toutes les pattes ont été coupées au ras du boitier, la connexion avec la piste imprimée ne s'effectuant que par l'intermédiaire de ces raccords de soudure. Ceci est visible sur la photo suivant, hélas prise après que la tenue mécanique ait été renforcée avec du vernis de type 'conformal coating'.

Les vibrations sur le mât ont rompu l'une de ces liaisons fragiles puisqu'un simple ajout de soudure avec un fer à micro-pointe a permis rétablir de bon fonctionnement. Pour plus de sureté, l'ensemble du module a été 'consolidé' par une bonne couche de vernis lequel devrait, je l'espère renforcer la tenue mécanique et électrique du boiter.

Je vais cependant approvisionner un DRA818V de secours que je démonterai pour vérifier que le montage du composant est bien effectué dans les normes. J'ai du mal à imaginer que tous les DRA818 soient affectés du même défaut ...

APRS: LightAprs - suite 4

La programmation d'un code est une activité créatrice prenante d'autant qu'avec les technologies récentes tout est permis ou presque. Il est alors difficile d'admettre que le code est fonctionnel et n'a plus à être amélioré si l'on souhaite pouvoir passer à un autre projet. Je ne suis pourtant pas sûr d'y arriver avec le firmware de ma balise APRS-Light tant les possibilités sont grandes, et la mémoire disponible importante.

La fonction de collecte des indicatifs reçus s'avère bien utile quoique encore imparfaite au regard de la collecte de ce matin laquelle fait apparaître des indicatifs belges et anglais mais sans l'identification secondaire (SSID) du transmetteur.

Cette information est importante pour bien identifier la station à l'origine du paquet: Beacon fixe, Station mobile ou encore Ballon sonde; autant d'options pouvant expliquer une telle distance de réception que seul le SSID peut permettre de confirmer.

C'est désormais chose faite avec la version mise en production ce matin.

Cette balise transmet les informations suivantes selon la table ci-dessous:

- Status:       toutes les 15mn à partir de H:01
- Localisation: toutes les  6mn à partir de H:03
- Bulletin :    toutes les 30mn à partir de H:05 

Soit:
- Status:       1      16     31         46
- Localisation:  3 9 15  21 27  33  39 45  51 57 
- Bulletin :      5               35

APRS: LightAprs - suite 3

L'installation de la balise APRS sur toit m'a conduit à améliorer mon code, lequel n'a désormais plus rien à voir avec celui d'origine du tracker LightAprs, code vraiment minimaliste et non exempt d'erreurs.

La version actuellement installée permet désormais de maintenir une liste des 20 derniers indicatifs reçus sur une fenêtre de comptage de 30 minutes. Cette liste est transmise sous la forme de quatre bulletins APRS. 

Elle corrige par ailleurs un problème rencontré avec le pilotage du module DRA818V, problème dont je n'arrive pas à déterminer s'il provient d'un module défectueux ou d'un fonctionnement non documenté dans la spécification pour le moins minimaliste.

Au relâchement du signal PTT (actif à l'état bas), la porteuse est modulée durant 400ms par une séquence a priori aléatoire. L'observation de la transmission à l'oscilloscope numérique ne permet pas d'identifier cette séquence mais confirme qu'un délai de 100ms existe entre l'activation du signal PTT et l'apparition de la porteuse. Le seul moyen de supprimer cette modulation, mais pas le délai de 400ms après le relâchement du signal, est de basculer le module en position stand-by (signal PD) durant 1ms avant de le réactiver.

Ce problème est bien visible sur le sonagramme suivant obtenu par une succession de transmissions d'une seconde avec l'un et l'autre mode de fermeture. Ces mesures ont ainsi permis d'optimiser le temps de transmission d'une trame.

 

Ce problème ne semble pas avoir été rencontré avec les autres implémentations APRS utilisant le module DRA818 mais aucune d'entre-elles n'implémente la fonction de réception, le module est donc systématiquement basculé en stand-by après l'émission de la trame.

Je vais donc devoir approvisionner quelques DRA818 pour déterminer si ce problème provient de mon module ou de son utilisation par les concepteurs du LightAPRS, lesquels n'ont jamais publié leur schéma...

Durant les tests, un signal provenant probablement de réflexion d'une transmission sur un avion ou un bolide a été reçu mais je n'ai pas eu le réflexe de noter la vitesse de déplacement du signal ...

Antennes: Nettoyage de printemps

Le beau temps de ce week-end a été l'occasion d'engager quelques travaux de réfection sur les antennes avec tout d'abord le déplacement de l'anémomètre un peu plus haut sur le mât. La position n'est pas idéale dans l'absolu mais l'objectif est ici de disposer d'une indication du vent s’exerçant sur les paraboles de ce coté de la maison.

Deux brins de la discone qui s'étaient détachés avec les tempêtes de cet hiver ont enfin pu être remontés avec utilisation de colle frein filet pour renforcer le maintien. La balise APRS jusqu'alors installée sur un rebord de fenêtre a trouvé sa position définitive sur un déport de mat. Elle est en dégagement sur l'horizon Nord mais pourra être remontée si besoin pour disposer d'une couverture à 360°.

APRS: LightAprs - suite 2

Le module LightAprs s'avère finalement être assez décevant tant sur le plan du firmware fourni par défaut que sur celui de la conception électronique. Du moins dans un fonctionnement autre que celui envisagé par les concepteurs, une balise de suivi pour ballons.

Si le source du code est bien disponible, il n'en est pas de même avec le schéma ce qui pose problème quand il s'agit de modifier le code et d'étendre les fonctionnalités matérielles.

Le capteur BMP085 est ainsi très rapidement tombé en panne à la suite d'un problème de qualité de soudure. Son remplacement par un BMP280 bien plus performant (et non obsolète) à permis de résoudre un second problème, celui du biais dans la mesure introduit par la proximité du capteur avec deux composants ayant tendance à chauffer: le régulateur de tension et le module DRA818.

Ce dernier chauffant bien trop en utilisation usuelle a été testé pour découvrir une probable erreur dans la conception (le schéma n'est pas disponible rappelons-le) la broche PTT étant positionnée à un niveau indéfini en mode réception (1.83V pour une alimentation sous 3.3V). L'ajout d'une résistance de rappel a immédiatement résolu le problème de chauffe.

Après donc un certain temps passé à réécrire le firmware et à modifier le matériel, l'ensemble a été intégré dans sa configuration définitive. Il va maintenant passer quelques semaines sur le rebord d'une fenêtre avant de rejoindre son emplacement définitif sur le pylône.

APRS: LightAprs - suite 1

La refonte du firmware du LightAprs est presque terminée avec un code parfaitement fonctionnel et désormais capable de gérer la réception des trames APRS. 

La platine d'origine est désormais dotée d'une carte fille supportant un bouton de réinitialisation, un capteur d'hygrométrie, une sortie audio et l'adaptateur de niveau permettant le raccordement de la sortie du module d'émission/réception au convertisseur analogique/digital de l'AVR.

La partie la plus compliquée du code concerne la gestion simultanée de deux convertisseurs, l'un géré par la remarquable librairie LibAPRS, l'autre destiné à relever la tension de la batterie et tous deux multiplexés sur le processeur AVR1284p. Un peu d’astuce dans la gestion des registres ad'hoc et le résultat est là sans aucune modification de la librairie et avec un décodage très correct des trames à l'exception, bien sûr, de celles reçues durant la transmission ou durant la lecture de la tension de la batterie.

Trois types de trames sont actuellement transmises:

- une trame de status indiquant la puissance d'émission (0.5W ou 1.0W), la tension d'alimentation, l'état du tracker, et la version du logiciel ;

- une trame de localisation pouvant prendre deux formes: la première indiquant l'altitude, le nombre de trames émises depuis le démarrage, la température et pression mesurés par le capteur d'origine  et enfin le nombre de satellites GPS vus; la seconde indiquant l'altitude, le nombre de trames reçues depuis le démarrage, la température et l'hygrométrie mesurées par le capteur le capteur additionnel, la tension de batterie et le nombre de satellites GPS vus. Les champs d'indication de la vitesse et direction du vent sont actuellement positionnés à 0.

APRS: LightAprs - suite

La réécriture du firmware du LightAprs se poursuit non sans difficultés car, si le logiciel est ouvert et accessible, il n'en est pas de même avec le schéma non disponible. Quoiqu'il en soit, une première version stable est désormais finalisée qui corrige les défauts de jeunesse de la version originale. 

Les trames transmises avec cette version depuis le shack ont bien été relayées par F6KBS sur le plateau du Moulon puis retransmises sur le réseau APRS-IS par la gateway F4GUK au Nord-Est de Paris. Il reste quelques réglages à faire mais la base fonctionne.

Parmi les principales modifications effectuées:
- ajout d'une condition de sortie sur temps de garde dépassé dans toutes les boucles de lecture,
- gestion de l'interface avec le GPS sous interruption en lieu et place du polling,
- réorganisation complète du code en factorisant toutes les portions communes,
- adaptation pour gérer aussi bien un beacon mobile que fixe.

La suite va consister à compléter les deux capteurs météos - le BMP085 (pression/température) embarqué et le DHT11 (hygrométrie/température) - en y ajoutant les données de vitesse et orientation du vent en provenance de capteurs Crouzet en cours de réfection. Il me faudra aussi découvrir pourquoi l'ensemble ne reçoit pas les trames APRS malgré les modifications effectuées dans le code.

APRS: LightAprs - premières modifications

Le tracker LightAprs est très bien conçu mais certaines entrées/sorties utiles ne sont hélas pas rendues accessibles. De fait, seuls les signaux correspondants aux bus I2C et SPI sont disponibles sur un header. Pourtant, il eut été pertinent de pouvoir utiliser les signalisations d'activité prévues dans la librairie APRS, voire même de câbler la sortie audio du récepteur pour éventuellement surveiller l'activité APRS. 

Souhaitant étendre l'utilisation de ce module pour en faire une mini-station fixe, il m'a fallu extraire les signaux les plus utiles, à savoir PB1, PB2 pour la signalisation LED, PA0 pour la réception des trames, PA3 et PA4 pour le raccordement de capteurs de vent et de direction, PD0 et PD1 pour accéder à la liaison série en mode TTL.

 La binoculaire s'avère être bien utile ici. Du fil à wrapper Teflon est utilisé et maintenu à l'aide de vernis de conformance. Les signaux sont amenés sur des broches qui viendront se connecter sur une plaque d'extension. L'ensemble devrait être assez solide pour résister aux nombreuses manipulations requises par les tests et le développement d'un nouveau code.

APRS: LightAprs - quelques idées d'utilisation

Le module 'LightAprs' est enfin arrivé. Un petit module livré dans une grande boite qui embarque un GPS, un module émission/réception de 1W et un ATMEL AVR1284 qu'il conviendra de programmer avec le logiciel accessible en OpenSource. Celui-ci s'appuie sur MightyCore exploitable depuis l'IDE Arduino mais aussi depuis mon environnement de développement préféré 'Visual Studio Code'.

Le logiciel d'origine est conçu pour transmettre des trames APRS de position avec les informations utiles pour suivre un ballon. Contrairement à d'autres projets, le code doit être recompilé pour configurer l'indicatif de la station, la fréquence d'émission et autres paramètres spécifiques. J'ai donc prévu de reprendre le code afin d'ajouter quelques capteurs météo et transmettre la direction et la vitesse du vent en lieu et place de la direction et vitesse de déplacement du mobile.

Je compte en effet installer le module en position statique en tête du mât supportant l'antenne ADS-B, de l'alimenter via une batterie et un panneau solaire mais aussi de retransmettre les paramètres méteo sur une interface WEB accessible en Wifi, ceci via l'un module ESP8266 que j'ai en stock. 

Bref, encore quelques heure de programmation et de test pour obtenir la configuration idéale: une balise APRS doublée d'une station méteo totalement autonome. 

A suivre ...