Analyse graphique de la zone de couverture

Dans le premier article de cette série sur l’APRS, j’ai réalisé une simulation de la zone de couverture avec Radiomobile (merci Roger VE2DBE). Après quelques mois de fonctionnement, il me semble intéressant de valider ces prévisions et en même vérifier l’intérêt de ce digipeater. 

J’utilise le fichier log quotidien de DireWolf (dans /var/log), un script Perl pour faire le travail de mise en forme et de calcul des distances entre la station et les stations entendues. Mais pour ne pas tomber dans la routine de la base de données relationnelle, j’ai choisi d’essayer un autre système appelé base de données de séries temporelles.

A part la nouveauté, c’est surtout un type de SGBD bien adapté pour le stockage des données de l’IdO (Internet des Objets) car sans structure rigide et une facilité à engranger beaucoup de données et très rapidement. Ce type de SGBD est classé dans le NoSQL, que l’on peut décrypter par : “Not Only SQL” plutôt que “No SQL”.

Le SGBD qui me sembe avoir le vent en poupe est InfluxDB, qui est bien connu dans le stockage de la télémétrie de supervision car il est bien entouré :

• Telegraph pour la collecte
• InfluxDB pour le stockage
• Chronograf pour la représentation
• Kapacitor pour la détection, l’alerte et la réponse aux problèmes.

Ce qui fait TICK en référence à cette unité de mesure du temps en informatique. Mais revenons à nos moutons, je n’utiliserai que InfluxDB et j’ajouterai Grafana qui est un bel environnement de requête et de visualisation.

La chaîne de traitement est simple, et sera bientôt automatisée :

Le format du log est indiqué dans la documentation de DIreWolf. Le script Perl met en forme les infos à stocker, calcule la distance entre le Digipeater et la station entendue grâce  au module Geo::Calc:XS et enfin le locator grâce au module Ham::Locator. Evidemment une qualification des données a été nécessaire car l’analyse des trames permet aussi de remonter les erreurs de configuration de quelques stations qui seraient à une distance que même le meteo scatter ne permet pas d’atteindre. Le fichier généré est au format CSV qui peut être intégré directement par l’API HTTP de InfluxDB par une commande du style :

curl -i -XPOST ‘http://localhost:8086/write?db=mydb’ –data-binary @cpu_data.txt

Dans le cas présent j’ai buté sur une quantité de données trop importante pour être ingérée en une requête, donc j’ai utilisé le bon vieil outil split pour découper le fichier en extraits de 500 lignes. L’ensemble de la chaîne est légère et peu gourmande en ressource ce qui permet de se lâcher sur la quantité de données à stocker. Car sur les 175 log quotidien, j’arrive à une moyenne de 27700 trames reçues par jour pour 3,8 Mo.

Une agrégation des données est indispensable dans Grafana pour l’affichage car trop de données tue les données ;-).

Ces deux extraits indiquent une distance moyenne de 120 et 133 km sur deux périodes différentes. CE résultat est cohérent avec ce qui est indiqué sur aprs.fi. L’étape suivante sera l’affichage sur carte des positions géographiques reçues. Ces informations seront par la suite à suivre lorsque le Digipeater sera déplacé dans le pylône.