Chaîne d'acquisition des données (depuis Janvier 2013)
Pourquoi cette rupture technologique en 2013 ?
En décembre 2011, une panne sévère sur la station a eut lieu empêchant ainsi la récupération des données pendant plus d'un an. Pendant cette année une longue réflexion a été menée afin d'effectuer une refonte complète du système. Jusque là, le système était composé du récepteur d'origine de la satation (le WS7000-13) connecté à un PC qui tournait de 8h à 22h tous les jours. Une application (Wswin32) générait ensuite une floppé de graphiques, tableaux...etc. qui étaient envoyés ensuite via un autre logiciel sur le site. Vous trouverez la description complète de cette chaîne d'acquisition sur cette page.
Les inconvénient de ce mode d'acquisition sont nombreux: pas de mise à jour 24h/24, une unité centrale qui consomme de l'electricité (environ 30W) et qui fait du bruit 14h/jour, un volume de données généré assez conséquent (plusieurs centaines de Mo par an qui au fil des années demandent d'avoir un espace de stockage du site web de plusieurs Go).
La panne de la station a donc été l'occasion de tout remettre à plat avec un cahier des charges assez simple : un système flexible, minimale, fiable, silencieux et tournant 24h/24! C'est donc une solution linux embarqué qui s'est imposé (de par ma formation d'électronicien/informaticien) et plus particulièrement la mise en place d'un SBC (single board computer) à la place de l'unité centrale.
La nouvelle chaine d'acquisition est donc la suivante:
L'unité centrale : une carte linux embarqué NanosG20
A l'heure où sont écrites ces lignes, le monde du linux embarqué est en pleine effervescence. On trouve dans le commerce beaucoup de carte électronique linux (Raspberry Pi, Beaglebone, NanosG20, Pandaboard...etc).
Ces cartes sont de vrai mini ordinateurs intégrant entre autres une gestion des communications ethernet, usb, série, I2C, CAN... Toutefois, l'utilisation de ce genre de matériel nécessite de bonnes connaissances en Linux, en électronique et en programmation C.
Initialement le but était de remplacer l'unité centrale par ce genre de carte mais le récepteur des capteurs de la station ne communiquant que via le port série, une carte disposant d'un port série était donc nécessaire. En plus de disposer d'un port série, il fallait que le signal DTR du port série soit bien géré par la carte (ce signal est nécessaire pour le récepteur). Mon choix s'est donc arrêté sur la carte NanosG20 (photo ci-contre). Cette carte dispose d'un port RS232, un port RS485, d'une horloge intégré (très utile pour que la carte soit toujours à l'heure !), d'un buzzer.
Malheureusement, je n'ai jamais pû faire fonctionner le récepteur d'origine de la station avec cette carte (ce n'est pas faute d'y avoir passé des heures! ). Plutôt que de tester une n-ième carte, j'ai décidé de réaliser moi-même un récepteur qui serait compatible avec la carte (voir descriptif ci-dessous) et qui s'y connecterait en USB.
Le choix de la NanosG20 n'a donc pas été judicieux (d'autant plus que la carte est assez chère). Une évolution future sera de remplaçer cette carte par la BeagleBone Black, bien plus fournis en connectique, en mémoire, en puissance CPU mais aussi bien moins chère.
Quoi qu'il en soit, la mise en place de cette NanosG20 permet d'avoir un système totalement autonome, silencieux et à très faible consommation (1W max). De plus il est possible via le protocole SSH de se connecter à cette carte depuis n'importe où afin d'en prendre le contrôle pour effectuer un redémarrage ou une analyse de rapports d'erreurs.
La réalisation d'un nouveau récepteur 433MHz pour les capteurs de la WS-2500
La carte NanosG20 ne pouvant pas piloter le récepteur officiel de Lacrosse Technology (WS7000-13) il a fallu concevoir un nouveau récepteur, compatible avec la NanosG20.
Le protocole de transmission des capteurs de la WS2500 a été décripté depuis bien longtemps par des passionnés. Je l'ai d'ailleurs retranscrit sur cette page. Plutôt que de réaliser de A à Z un récepteur (réalisation du circuit, programmation du micro-contrôleur, tests...) j'ai directement reproduit le récepteur décrit sur ce site web: www.f6fbb.org (je remercie au passage l'auteur).
Ce récepteur capte les données émises par les capteurs et les envois ensuite sur le port série USB (via un protocole bien définie). L'utilisation d'un port série USB (donc port série "virtuel") est très pratique . La carte est ainsi alimentée par le port en + 5V par USB (il aurait fallu une alimentation séparée avec un récepteur fonctionnant sur un port série "classique") et de plus, ce type de port série-USB est totalement géré par la carte NanosG20 et le Linux qui tourne dessus.
Grâce à la mise en place de ce récepteur, j'ai pu découvrir que l'humidité extérieur est envoyée à la station avec une résolution de 0.1% mais que la station n'affiche l'humidité qu'avec une résolution de 1%. Le site web affiche désormais une humidité avec une résolution de 0.1%.
De plus, la pression atmosphérique avait auparavant une résolution de 1 hPa (résolution du capteur WS7000-20) ce qui ne me convenait pas du tout. En remplacement de ce capteur d'origine, un capteur de pression BMP085 a été ajouté. Ce capteur communique avec la carte NanosG20 par un bus I2C et permet ainsi la récupération de la pression atmosphérique avec une résolution de 0.1 hPa.
Le logiciel embarqué
Sur un linux embarqué, il n'est pas possible de faire tourner un logiciel comme Wswin32, logiciel tournant sous Windows mais surtout purement graphique (pas d'écran sur un Linux embarqué pour rappel). Il faut alors se tourner vers les logiciels là encore développés par des passionnés et qu'il faudra compiler spécifiquement pour le processeur de la carte (une épreuve qui peut s'avérer très douloureuse).
Comme expliqué précédemment, le but initial était de remplacer l'unité centrale par une carte linux qui devait se connecter au récepteur d'origine de la station. A partir de là, il aurait été possible d'utiliser le logiciel de Rainer Krienke, logiciel dédié à la communication avec le récepteur officiel de la WS2500 (WS7000-13) dans un environnement Linux.
L'utilisation d'un récepteur fait maison implique la création d'un logiciel dédié au pilotage de celui-ci. Ce logiciel, développé en language C, scrute en permanence le port série-usb dans l'attente d'une donnée. Ensuite, toutes les 2min50s (interval moyen entre 2 réceptions de données de la station), ce programme envoie les données à un script PHP sur ce site web, script qui vient ensuite enregistrer l'ensemble de ces données dans une base de données MySQL. Si la connexion internet n'est pas disponible, les données sont stockés localement jusqu'à ce qu'elles puissent être transmisent au site.
Changement d'architecture du site web
Auparavant, l'ensemble des données étaient généré en local par le logiciel Wswin32 puis envoyé sur le site. Avec la mise en place d'une base données MySQL, les graphiques et tableaux présents sur le site sont générés dynamiquement. Pour cela, la librairie graphique ChartDirector est utilisée.
C'est d'ailleurs pour cette raison qu'au moment où ces lignes sont écrites le site est moins riche qu'avant en termes de graphiques/statistiques car il faut du temps pour développer les scripts PHP qui permettent la mise en forme des données.
Conclusion
Les prochaines étapes consisteront dans un premier temps à remplacer la NanosG20 par une carte plus performante et moins chère (la Beaglebone Black semble actuellement la mieux placée). Enfin, un autre projet sera de construire entièrement les capteurs de la station, afin de descendre à un pas de mesure de 1 min tout en gardant une rétro-compatibilité avec l'écran de l'ancienne station.
Dernière mise à jour: 03/11/14