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

Divers: Afficheur NMEA

Ce dernier week-end a bien été occupé à développer un afficheur NMEA destiné à être connecté à un GPS-DO 10MHz. Cet afficheur permettra de vérifier le bon fonctionnement du GPS, et donc du verrouillage du TXCO.

Le dispositif utilise Arduino Nano pilotant un afficheur LCD 2x16 caractères. Le tout est intégré dans un boîtier plastique, l'adaptation de niveau est assurée par un MAX232. L'ensemble est alimenté par la base de temps laquelle transmet aussi le signal 1PPS pour contrôle.

La programmation reste simple quoique s'appuyant sur deux timers, l'un interne destiné à contrôler l'affichage des différentes séquences, le second contrôlé par le signal 1PPS. Aucune des librairies existantes pour l'Arduino ou pour le Teensy  ne gère proprement les erreurs protocolaires. Un automate d'état a donc été réécrit pour traiter chaque trame NMEA sans se limiter à la trame RMC comme le font la majorité des parseurs.

La connexion à base de temps permet de visualiser alternativement le nombre de satellites visibles au regard des 12 pouvant être traités, le niveau d'erreur (PDOP) mais aussi l'heure UTC, l'altitude de l'antenne (posée en haut du pylône) et les coordonnées du lieux en décimal et en 'd.m.s'. Deux symboles animés retranscrivent l'état de la liaison série et du signal 1PPS.

Le seul problème rencontré est celui de l'erreur sur la date. Cette erreur est liée au module GPS utilisé: un Jupiter disposant d'une sortie 10kHz utilisée comme référence de verrouillage. Depuis fin 2015, ce module fournit en effet une date décalée de 1024 semaines en arrière. Une correction dans le logiciel de l'Arduino permet de s'en affranchir.

Problème bien plus gênant, mon dernier Arduino Nano pourtant approvisionné via une boutique sérieuse il y maintenant quelques années s'est mis à transmettre le fameux message indiquant que le chip FT232R est une copie: "NON GENUINE DEVICE FOUND!". Le problème est ici que contrairement à ce qui est annoncé dans la littérature, le message n'est pas transmis par le driver FTDI Windows mais bien par le chip lui-même. La connexion de la platine sur une machine LINUX délivre ce même message. Serait-il possible que, d'une manière ou d'une autre, l'un des drivers de mes machines Windows ait reprogrammé le firmware du faux FT232R. Je n'y crois guère - ce serait une forme d'attaque active - mais je n'ai aucune autre explication à l'heure actuelle.