{"id":215,"date":"2017-03-06T18:35:58","date_gmt":"2017-03-06T17:35:58","guid":{"rendered":"https:\/\/www.f8eby.org\/blog\/?p=215"},"modified":"2017-03-07T00:18:23","modified_gmt":"2017-03-06T23:18:23","slug":"analyse-graphique-de-la-zone-de-couverture","status":"publish","type":"post","link":"https:\/\/www.f8eby.org\/blog\/index.php\/2017\/03\/06\/analyse-graphique-de-la-zone-de-couverture\/","title":{"rendered":"Analyse graphique de la zone de couverture"},"content":{"rendered":"

Dans le premier article<\/a> de cette s\u00e9rie sur l’APRS, j’ai r\u00e9alis\u00e9 une simulation de la zone de couverture avec Radiomobile<\/a> (merci Roger VE2DBE). Apr\u00e8s quelques mois de fonctionnement, il me semble int\u00e9ressant de valider ces pr\u00e9visions et en m\u00eame v\u00e9rifier l’int\u00e9r\u00eat de ce digipeater. <\/p>\n

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\u00e9es relationnelle, j’ai choisi d’essayer un autre syst\u00e8me appel\u00e9 base de donn\u00e9es de s\u00e9ries temporelles.<\/p>\n

A part la nouveaut\u00e9, c’est surtout un type de SGBD bien adapt\u00e9 pour le stockage des donn\u00e9es de l’IdO (Internet des Objets) car sans structure rigide et une facilit\u00e9 \u00e0 engranger beaucoup de donn\u00e9es et tr\u00e8s rapidement. Ce type de SGBD est class\u00e9 dans le NoSQL, que l’on peut d\u00e9crypter par : \u00ab\u00a0Not Only SQL\u00a0\u00bb plut\u00f4t que \u00ab\u00a0No SQL\u00a0\u00bb.<\/p>\n

Le SGBD qui me sembe avoir le vent en poupe est InfluxDB<\/a>, qui est bien connu dans le stockage de la t\u00e9l\u00e9m\u00e9trie de supervision car il est bien entour\u00e9 :<\/p>\n