dimanche 17 mai 2020

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

dimanche 3 mai 2020

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

vendredi 1 mai 2020

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