APRS: Traqueur et iGate Lora

La modulation LORA est de plus en plus utilisée pour la transmission des paquets APRS (sur 433.775MHz). Ceci principalement grâce à la mise à disposition de modules performants intégrant un modem Lora en 432MHz ainsi qu'un processeur de type ESP32. Disposant d'un T-Deck en 432Mhz, j'ai décidé de tester le fonctionnement de celui-ci en traqueur et d'installer une passerelle iGate sur la base d'un module Heltec ESP V3.

L'installation du logiciel est simple à condition de bien configurer le dispositif dans le bon mode (appui sur le track ball lors du reset pour le T-Deck, appui sur le bouton Prgm puis reset pour le Heltec). La programmation du firmware se fait ensuite via le navigateur au moyen d'un utilitaire dédié accessible sur le site de l'auteur du code dont CA2RXU

Il faut ensuite disposer d'un équipement disposant du Wifi (téléphone ou portable par exemple) pour se connecter sur le point d'accès Wifi d'adresse 192.168.4.1 proposé par le dispositif. Ceci après s'être connecté sur ce point d'accès: LoRa-APRS-iGate ou LoRa-APRS-AP. La configuration s'effectue alors via l'interface WEB présente à la dite adresse.

Il me reste à raccorder la passerelle à une antenne ad'hoc et à installer l'ensemble dans un boitier avec probablement une alimentation solaire.

A suivre doc ...

APRS: Test d'une 5/8 Lambda

L'antenne GP 1/4 d'onde de la balise APRS est parfaitement taillée mais son efficacité reste discutable comparée à l'antenne colinéaire 144/432 actuellement utilisée comme référence en réception APRS. J'ai donc décidé de tester une 5/8 d'onde.

Plusieurs essais ont été nécessaires pour trouver un compromis sur le poids et la solidité. Le plan de masse constitué d'un carré d'époxy double face est soudé sur le haut d'une prise SO239. Sur celui-ci viendront se souder quatre radians en laiton.

Pour le reste, j'ai d'abord imprimé en PETG une forme devant se visser dans la prise coaxiale. Il s'avère rapidement que la solidité n'est pas au rendez-vous. Un essai avec du Nylon n'est guère plus satisfaisant.  La bonne solution a consisté à tourner un rond de Teflon aux bonnes dimensions pour s'insérer dans la prise. Celui-ci servira de noyau porteur d'une forme en PETG sur laquelle sera réalisé l'enroulement. 

Deux formes sont imprimées pour test: l'une permettant 4,5 spires raccordées en série avec le brin actif et l'autre autorisant 10,5 spires avec un prise 4 spires avant le départ du brin. La première approche (rallongement de l'antenne de 1/8 d'onde pour obtenir l'équivalent d'une 3/4 d'onde) ne donne pas réellement satisfaction. La seconde approche - préconisée par ARRL Antenna Hand Book - permet d'obtenir non seulement un accord mais aussi, une fois les radians installés, de réduire le SWR.

L'antenne installé directement au dessus du boitier de la balise. De gauche à droite: l'antenne Lora et son filtre, l'antenne APRS, une antenne discone et au sommet une antenne ADSB puis le récepteur Lora dans son boitier solaire.

Les premiers essais montrent une amélioration en émission: les trames transmises avec 0.5W sont maintenant reçues par les deux passerelles du coin. Ma balise transmet en effet alternativement avec une puissante de 0.5W et de 1W. Concernant la réception le score est bien plus faible qu'avec l'ensemble Colinéaire/FT2800M/Kantronix KAM-Plus. Il me faudrait engager plus de tests pour déterminer l'influence de la qualité du décodeur et du récepteur en inversant par exemple le raccordement aux  antennes. A suivre, peut-être ...

APRS: Mise à jour de la balise

Un radioamateur m'a fait remarquer avec justesse que ma balise autonome APRS occupait un peu trop de temps d'antenne. Les délais de transmission ont donc été augmentés. Et l'envoi d'un bulletin a été optimisé en ne transmettant que les informations utiles 'sans effacer' les anciennes lignes. Ceci d'autant que j'ai passé le délai à 30mn soit plus que la durée de vie 'normale' de 20mn. Ce bulletin me permet de connaitre les stations reçues, directement ou par relayage.

Cette balise est en fonctionnement continu depuis un peu moins de dix ans. La reprogrammation nécessite cependant de la descendre du toit. Elle est constituée d'une platine LightAPRS V1.0 largement modifiée pour y ajouter des capteurs mais aussi être à même de recevoir les trames pour les compter. Il y aurait encore suffisamment de place dans le code pour en faire un répéteur...

L'antenne a été réaccordée, en position, à l'aide du petit VNA. Le dégagement est sur 360° (hors le masque des deux cheminées) à 182m d'altitude.

TNC: Réalisation d'un TNC Kiss Arduino

La réparation du TNC241 m'a amené à réaliser un TNC sur la base d'un arduino Nano. Plusieurs projets existent depuis plus de 10 ans qui permettent cette réalisation à minimum d'investissement dont en particulier le projet 'MicroAPRS' déjà utilisé sur ma balise LightAPRS et le projet TNC2 de 'Mobilinkd'. 

Ces deux réalisations ont été testées et comparées sur une première maquette:

	MicroAPRS	TNC2 Mobilinkd
Système	- Minimaliste - Compilation immédiate sous PlatformIO - Import des sources simple	- BeRTOS - Utilisation du Wizard BertOS (obsolète) - Configuration manuelle sous PlatformIO
Terminal	- Mode KISS - Mode Console	- Mode KISS
Signalisation	- Diodes LED TX et RX	- Aucune
Modifications	- Simples	- Peu évidentes
Emission	- Algorithme dédié - DAC résistifs et Table sinus - Aucun filtrage - Pas de réglage de niveau	- Fonction de BeRTOS - Modulation PWM - Filtrage requis pour le lissage - Réglage de niveau
Réception	- Algorithme dédié - Détection via ADC - VRef 3.3V - Filtrage numérique	- Fonction de BeRTOS - Détection via ADC - VRef 5V
Divers	- Schéma proche du TNC2 - DAC résistif sur PD 7,6,5,4	- Schéma proche du MicroAprs - DAC sur PD 6

On notera que les schémas sont très similaires et permettent une comparaison sur une même platine moyennant la mise en place de quelques cavaliers. 

L'utilisation de la tension d'alimentation (cas 01) comme référence impose la mise en place d'un condensateur sur la broche Aref. Celui-ci n'est pas présent sur les schémas publiés. L'utilisation d'une référence externe (cas 00) nécessite que celle-ci soit câblée sur la broche Aref ce qui est  rarement indiqué sur les schémas publiés. 

Le choix d'une tension de référence assez basse permet de faire travailler le convertisseur sur une plage adaptée. Dans le cas d'une carte Arduino Nano, l'utilisation de la tension d'alimentation (5V) n'est pas optimale pour une tension d'entrée de l'ordre de 500mVAC. L'idéal serait d'utiliser une référence de tension externe de l'ordre de 2VDC, voire la tension de référence de 3.3VDC présente sur la carte.

C'est le choix fait sur la seconde maquette qui fonctionne parfaitement et dont le logiciel est en cours de modification pour pouvoir, entre autre, sélectionner au vol le mode d'accès console ou KISS.

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 ...