Réseau de capteurs sans fil à faible coût sur la bande 433 MHz : 5 étapes (avec photos)

2024 Auteur: John Day | [email protected]. Dernière modifié: 2024-01-30 09:07

Un grand merci à Teresa Rajba pour m'avoir gentiment accepté d'utiliser les données de leurs publications dans cet article

* Dans l'image ci-dessus - les cinq unités capteur-émetteur que j'ai utilisées pour les tests

Que sont les réseaux de capteurs sans fil ?

Une définition simple serait la suivante: les réseaux de capteurs sans fil font référence à un groupe d'appareils électroniques répartis sur une certaine zone pour surveiller et enregistrer des données environnementales, qui sont transmis sans fil à un emplacement central pour être traités et stockés.

De nos jours, les réseaux de capteurs sans fil peuvent être utilisés de plusieurs manières, ci-dessous ne sont que quelques exemples:

• Zones de surveillance écologique des forêts, des rivières, des lacs, des mers et des océans;
• Possibilité d'alerter en cas d'attaques terroristes, chimiques, biologiques, épidémiques;
• Systèmes de surveillance pour les enfants, les personnes âgées, les patients ou les personnes ayant des besoins spéciaux;
• Systèmes de surveillance dans l'agriculture et les serres;
• Système de surveillance des prévisions météorologiques;
• Surveillance du trafic urbain, écoles, parkings;

Et bien d'autres applications.

Dans cet article, je souhaite montrer les résultats d'une expérience avec des réseaux de capteurs sans fil qui ont été utilisés pour surveiller les données de température et d'humidité, avec une variation lente et relativement prévisible. Pour cette expérience, j'ai choisi d'utiliser des capteurs-émetteurs que j'ai construits moi-même à l'aide de modules abordables. Le récepteur est aussi DIY, la communication est unidirectionnelle (sur la bande radio 433 MHz), c'est-à-dire que les capteurs ne transmettent que les données et que la localisation centrale ne fait que recevoir. Il n'y a pas de communication entre les capteurs et du récepteur aux capteurs.

Mais pourquoi choisir d'utiliser plusieurs émetteurs et un seul récepteur ? Évidemment, la première raison serait de « faire simple ». Plus l'assemblage est simple, moins il risque de tomber en panne, et il est certainement beaucoup plus facile de réparer et de remplacer les composants individuels en cas de dysfonctionnement. La consommation d'énergie est également plus faible, les batteries dureront plus longtemps (les capteurs ne consommeront que pendant la surveillance et la réception, le reste du temps, l'appareil sera en mode veille profonde). Le fait qu'il soit simple rend l'appareil aussi bon marché. Un autre aspect à garder à l'esprit est la zone de couverture. Pourquoi? Il est beaucoup plus facile de construire et d'utiliser un récepteur sensible que d'avoir un récepteur sensible et un émetteur puissant à la fois au niveau des capteurs et du module central (ceci est nécessaire pour une bonne communication bidirectionnelle). Avec un récepteur sensible et de bonne qualité, il est possible de recevoir des données à longue distance, mais émettre des données pour la même distance nécessite une puissance d'émission élevée et cela entraîne des coûts élevés, une consommation d'électricité et (n'oublions pas) la possibilité de dépasser le puissance d'émission maximale légale sur la bande 433 MHz. En utilisant un récepteur de qualité moyenne, bon marché mais avec une antenne de haute qualité (même DIY) et des émetteurs bon marché avec une antenne de bonne qualité, nous pouvons obtenir d'excellents résultats à une fraction du coût des réseaux de capteurs sans fil existants.

Étape 1: Considérations théoriques

L'idée de construire un réseau de capteurs sans fil pour surveiller la température et l'humidité de l'air et du sol dans différentes zones d'une serre m'est venue à l'esprit il y a longtemps, presque 10 ans. Je voulais construire un réseau 1 fil et utiliser des capteurs de température et d'humidité 1 fil. Malheureusement, il y a 10 ans, les capteurs d'humidité étaient rares et chers (bien que les capteurs de température étaient répandus) et comme la diffusion de fils dans toute la serre ne semblait pas une option, j'ai abandonné l'idée assez rapidement.

Cependant, maintenant, la situation a radicalement changé. Nous sommes en mesure de trouver des capteurs bon marché et de bonne qualité (température et humidité), et nous avons également accès à des émetteurs et récepteurs bon marché sur la bande 433 MHz. Il n'y a qu'un seul problème: si nous avons plus de capteurs (disons 20) comment résolvons-nous les collisions (veuillez garder à l'esprit qu'il s'agit d'une communication unidirectionnelle), c'est-à-dire chevauchant l'émission de 2 capteurs ou plus ? En cherchant une solution possible, je suis tombé sur ces articles très intéressants:

Le capteur sans fil converge sur la base d'une procédure d'opérations aléatoires - par RAJBA, T. et RAJBA, S.

et

La probabilité de collisions dans le réseau de capteurs sans fil avec envoi aléatoire - par RAJBA S. et RAJBA. T

Fondamentalement, les auteurs nous montrent que la probabilité de collisions dans un réseau de capteurs sans fil peut être calculée si les paquets sont émis à certains moments selon une distribution poissonienne (exponentielle).

Un extrait de l'article ci-dessus liste les caractéristiques du réseau étudié.

• un assez grand nombre d'unités capteurs-émetteurs N;
• les unités capteurs-émetteurs restent totalement indépendantes et leur mise en marche ou à l'arrêt n'a aucune influence sur le fonctionnement du réseau;
• toutes les unités capteurs-émetteurs (ou une partie d'entre elles) peuvent être mobiles à condition qu'elles soient situées à portée radio de la station réceptrice;
• les paramètres physiques qui évoluent lentement sont soumis à des mesures, ce qui signifie qu'il n'est pas nécessaire de transmettre les données très fréquemment (par exemple toutes les quelques minutes ou plusieurs dizaines de minutes);
• la transmission est de type unidirectionnelle, c'est-à-dire depuis l'unité capteur-émetteur jusqu'au point de réception à T intervalles de temps moyens. Les informations sont transmises dans le protocole à t_p durée;
• tout capteur sélectionné commence à transmettre de manière aléatoire aux heures de Poisson. PASTA (Poisson Arrivals See Time Averages) sera utilisé pour justifier l'envoi de sondes aux époques de Poisson;
• toutes les unités capteur-émetteur restent aléatoirement indépendantes et elles transmettront les informations à un moment choisi au hasard de t_p durée et de T temps moyen de répétition;
• si un ou plusieurs capteurs commencent à émettre alors que le protocole de t_p la durée est transmise par un autre capteur, une telle situation est appelée collision. La collision empêche la station de base centrale de recevoir les informations de manière correcte.

Il s'intègre presque parfaitement avec le réseau de capteurs que je veux tester…

Presque.

Je ne dis pas que j'ai complètement compris les mathématiques dans l'article, mais sur la base des données présentées et des conclusions, j'ai pu comprendre un peu de quoi il s'agit. La seule chose est qu'une valeur utilisée dans le papier m'a un peu inquiété:). C'est la variable t_p - durée de la transmission des données supposée être 3,2x10^-5 s. Le temps de transmission des données collectées serait donc de 3,2 us ! Cela ne peut pas être fait sur la bande 433 MHz. Je veux utiliser le rcswitch ou la radiohead pour programmer les capteurs de l'émetteur. En étudiant les codes des deux bibliothèques, je suis arrivé à la conclusion que le plus petit temps de transmission serait de 20ms, bien au-dessus de la valeur de 3,2 us. Avec les émetteurs 2,4 GHz, il est possible de t_p le temps si petit… mais c'est une autre histoire.

Si nous appliquons la formule proposée par les auteurs de cet article, le résultat sera:

Données initiales (un exemple):

• Nombre de capteurs N=20;
• Durée de transmission des données t_p=20x10^-3 s (0.020s)
• Intervalle de transmission moyen T=180s

La formule:

La probabilité de collision sur l'intervalle T est

si l'on prend en compte les données initiales la probabilité de collision sur l'intervalle T sera de 0,043519

Cette valeur, qui indique la probabilité d'avoir 4,35 collisions pour 100 mesures, est, à mon avis, assez bonne. La probabilité pourrait s'améliorer si nous augmentions le temps de transmission moyen, donc à une valeur de 300s nous aurions une probabilité de 0,026332, soit 2,6 collisions pour 100 mesures. Si l'on considère que l'on peut de toute façon s'attendre à une perte de données par paquets pendant le fonctionnement du système (en fonction des conditions météorologiques par exemple), alors ce nombre est vraiment excellent.

Je voulais faire une simulation de ce type de réseau mais aussi une sorte d'assistant de conception, j'ai donc fait un petit programme en C, vous pouvez trouver le code source sur github (également un binaire compilé qui s'exécute en ligne de commande windows - Libération).

Des données d'entrée:

• sensor_number - le nombre de capteurs sur le réseau;
• mesures_number - nombre de mesures à simuler;
• average_transmission_interval -temps moyen entre les transmissions de données successives;
• transmission_time - la durée effective de la transmission des données.

Sortir:

• le temps de mesure maximal calculé;
• la liste des collisions entre deux capteurs;
• nombre de collisions;
• probabilité théorique des collisions.

Les résultats sont assez intéressants:)

Assez avec la théorie, je ne voudrais pas insister davantage sur la partie théorique, les articles et le code source sont assez éloquents, je ferais donc mieux de passer à la mise en œuvre pratique et efficace du réseau de capteurs sans fil et aux résultats des tests.

Étape 2: Mise en œuvre pratique - le matériel

Pour les émetteurs-capteurs, nous aurons besoin des composants suivants:

• Microcontrôleur ATtiny85 1,11 $;
• Prise de circuit intégré 8DIP 0,046 $;
• Capteur de température/humidité DHT11 0,74 $;
• Module émetteur 433MHz H34A 0,73 $;
• Porte-piles 4xAA avec interrupteur 1$;

Total 3,63 $;

Le récepteur utilisé pour les tests est un Arduino UNO (uniquement pour les tests) et un module de réception H3V4F (0,66$) avec une antenne à arc bon marché (0,32$).

Schémas capteur-émetteur

Les unités émetteur-capteur sont alimentées par 3 piles AA, 1,5 V (dans le quatrième compartiment du porte-piles se trouve l'ensemble électronique). Comme vous pouvez le voir, l'alimentation de l'émetteur et le capteur de température et d'humidité sont connectés à la broche PB0 du microcontrôleur (l'émetteur et le capteur sont alimentés lorsque la broche est réglée sur HAUT). Ainsi, lorsque le microcontrôleur est en mode veille prolongée, il peut atteindre une consommation de courant de 4,7 uA. Considérant que le temps de réveil de l'émetteur-capteur serait d'environ 3s (mesure, transmission etc.) et le temps moyen entre les transmissions de 180s (comme dans l'exemple du chapitre précédent), les batteries devraient résister pas mal. Avec quelques piles alcalines de bonne qualité (c'est-à-dire 2000 mAh), l'autonomie pourrait être supérieure à 10 mois comme calculé sur omnicalculator.com (où la consommation totale de courant est: capteur - 1.5mA, module émetteur - 3.5mA et microcontrôleur ATtiny85 - 5mA, total 10mA).

Sur la photo ci-dessous, vous pouvez voir l'ensemble capteur-émetteur presque terminé.

Ci-dessous se trouve la photo du récepteur de test.

Étape 3: Mise en œuvre pratique - Logiciel

Le logiciel téléchargé fonctionnant sur le microcontrôleur attiny85, composant principal des unités capteur-émetteur, a pour but de lire les données fournies par le capteur, de les convertir pour être transmises par radio et de les transmettre dans des délais de Poisson (distribution exponentielle ou PÂTES - Arrivées Poisson Voir Moyennes de temps). De plus, en utilisant une fonction simple, il surveille l'état des batteries et donne un avertissement si la tension requise pour le capteur n'est plus fournie. Le code source est disponible sur github. Le code du récepteur de test est très simple, je le poste ci-dessous.

//bibliothèque rcswitch modifiée de https://github.com/Martin-Laclaustra/rc-switch/tree/protocollessreceiver// le code est une version modifiée à partir d'exemples de la bibliothèque rcswitch originale #include RCSwitch mySwitch = RCSwitch(); données longues non signées = 0; void setup() { Serial.begin(9600); mySwitch.enableReceive(0); // Récepteur sur interruption 0 => c'est la broche #2 } void loop() { if (mySwitch.available()) { unsigned long data = mySwitch.getReceivedValue(); //output(mySwitch.getReceivedValue(), mySwitch.getReceivedBitlength(), mySwitch.getReceivedDelay(), mySwitch.getReceivedRawdata(), mySwitch.getReceivedProtocol()); int humidité = bitExtracted(data, 7, 1); //moins significatif 7bits à partir de la position 1 - premier bit le plus à droite int temperature = bitExtracted(data, 7, 8); // 7 bits suivants de la position 8 vers la droite et ainsi de suite int v_min = bitExtracted(data, 1, 15); int packet_id = bitExtracted(data, 3, 16); //3bits - 8 identifiants de paquets de 0 à 7 int sensor_id = bitExtracted(data, 6, 19); //6bit pour 64 ID de capteur - total 24 bits Serial.print(sensor_id);Serial.print(", ");Serial.print(packet_id);Serial.print(", ");Serial.print(temperature); Serial.print(", ");Serial.print(humidité); Serial.println(); mySwitch.resetAvailable(); } } //code de https://www.geeksforgeeks.org/extract-k-bits-given-position-number/ int bitExtracted(unsigned long number, int k, int p) { return (((1 (p - 1))); }

J'ai essayé d'inclure autant de commentaires que possible pour rendre les choses plus faciles à comprendre.

Pour le débogage, j'ai utilisé la bibliothèque logicielle et la carte de développement attiny85 avec le programmeur USBasp (voir aussi mon instructable à ce sujet). La liaison série a été réalisée avec un convertisseur Série vers TTL (avec une puce PL2303) connecté aux broches coudées (3 et 4) de la carte de développement (voir photo ci-dessous). Tout cela a été d'une aide précieuse pour compléter le code.

Étape 4: Résultats des tests

J'ai créé 5 unités capteur-émetteur qui collectent et envoient les valeurs mesurées par les capteurs DHT11. J'ai enregistré et sauvegardé les mesures, à l'aide du récepteur de test et d'un programme d'émulation de terminal (foxterm), pendant trois jours. J'ai choisi un intervalle de 48 heures pour l'étude. Je n'étais pas forcément intéressé par les valeurs mesurées (capteur 2, par exemple, il m'affiche des valeurs erronées) mais par le nombre de collisions. De plus, les capteurs ont été placés très près (à 4-5 m) du récepteur pour éliminer d'autres causes de perte de paquets. Les résultats du test ont été enregistrés dans un fichier cvs et téléchargés (regardez le fichier ci-dessous). J'ai également téléchargé un fichier Excel basé sur ce fichier csv. J'ai pris quelques captures d'écran pour vous montrer à quoi ressemble une collision (dans mes tests bien sûr), j'ai également ajouté des commentaires à chaque capture d'écran.

Vous vous demandez peut-être pourquoi je n'ai pas utilisé de service de chargement de données, par exemple ThingSpeak. Le fait est que j'ai de nombreux enregistrements, de nombreux capteurs et données venant souvent à intervalles irréguliers, et les services IoT en ligne n'autorisent les données qu'à un certain nombre de capteurs et uniquement à des intervalles assez importants. Je pense à l'avenir à installer et configurer mon propre serveur IoT.

Au final, 4598 mesures sur 5 unités capteur-émetteur (environ 920/capteur) ont abouti à un total de 5 collisions sur une période de 48 heures (0,5435 collisions/100 mesures). En faisant quelques calculs (en utilisant le programme wsn_test avec les données initiales: 5 capteurs, temps moyen 180s, temps de transmission 110 ms), la probabilité de collision serait de 0,015185 (1,52 collisions/100 mesures). Les résultats pratiques sont encore meilleurs que les résultats théoriques n'est-ce pas ?:)

Quoi qu'il en soit, il y a aussi 18 paquets perdus dans cette période, donc les collisions n'ont pas vraiment trop d'importance à cet égard. Bien sûr le test devrait se dérouler sur une plus longue période de temps pour obtenir les résultats les plus concluants mais à mon avis est un succès même dans ces conditions et confirme pleinement les hypothèses théoriques.

Étape 5: Réflexions finales

Application immédiate

Dans une grande serre, plusieurs cultures sont cultivées. Si l'irrigation est effectuée manuellement sans surveillance du climat, sans aucune automatisation, sans enregistrement de données, il y a un risque de sur ou sous-irrigation et aussi la consommation d'eau est élevée, il n'y a aucune preuve d'optimisation de la consommation d'eau, il y a un risque pour les cultures dans général. Pour éviter cela, nous pouvons utiliser un réseau de capteurs sans fil:)

Des capteurs de température, des capteurs d'humidité de l'air, des capteurs d'humidité du sol peuvent être placés tout autour de la serre et à l'aide des données transmises, plusieurs actions peuvent être effectuées: vannes électriques marche-arrêt pour laisser l'eau s'écouler là où c'est nécessaire, ventilateurs électriques marche-arrêt pour réduire la température dans différentes zones, les réchauffeurs marche-arrêt au besoin et toutes les données peuvent être archivées pour une analyse future. En outre, le système peut fournir une interface Web accessible partout et des alarmes par e-mail ou SMS en cas de condition anormale.

Et après?

• Test avec un plus grand nombre de capteurs;
• Tests en temps réel avec des capteurs à distance dans la zone de couverture;
• Installation et configuration d'un serveur IoT local (sur un Raspberry Pi par exemple);
• Tests également avec des capteurs émetteurs (émetteurs-récepteurs) sur 2,4 Ghz.

alors… à suivre…:)

AVIS DE NON-RESPONSABILITÉ: L'utilisation de la bande de fréquence 433 MHz dans votre région peut être soumise à des réglementations sur les fréquences radio. Veuillez vérifier votre légalité avant d'essayer ce projet

Finaliste du concours Sensors