Nous faisons la passerelle entre le Wi-Fi et LoRa pour UDP
J'ai eu un rêve d'enfance: donner à chaque appareil domestique «sans Wi-Fi» un ticket réseau, c'est-à-dire une adresse IP et un port. Après un certain temps, j'ai réalisé que je ne devais pas le remettre. Nous devons prendre et faire.
Mandat
Faites-en une passerelle M5Stack avec le module LoRa installé (Figure 1). La passerelle sera connectée à un réseau Wi-Fi dans lequel obtenir une adresse IP locale via DHCP. La passerelle diffusera son nom en LoRa-éther avec une certaine fréquence (analogique du SSID pour le Wi-Fi) et la gamme de ports acceptables afin que les autres appareils sachent qu'il existe un tel réseau auquel vous pouvez vous connecter et dans quelle plage vous pouvez sélectionner un port libre. Puisque ce sera un prototype, l'authentification n'est pas cette fois. Les nouveaux appareils clients trouveront un réseau LoRa disponible et lui transmettront le port sélectionné. Une fois que la passerelle a reçu un port d'un nouveau client, elle vérifie s'il est libre, si c'est le cas, elle enregistre un nouveau client et commence à écouter ce port sur son propre serveur UDP asynchrone. Après l'enregistrement, le client recevra le consentement ou le refus d'utiliser le port déclaré. La procédure de fonctionnement est indiquée dans le tableau 1.
Figure 1
Tableau 1
Devant moi sur la table sont toutes sortes de modules pour le M5Stack et s'ennuient. Prenons LoR et amusez-vous avec elle . Le concept du module lui-même est magnifique! Que puis-je dire? Mais, les modules de ma première révision, dans lesquels une terrible antenne intégrée, faite sur une carte de circuit imprimé flexible et collée sur la paroi latérale du boîtier. J'ai déjà effectué des tests sur le terrain de ces modules (vous pouvez le regarder sur la chaîne en russe sur YouTube):
Naturellement, j'ai dû retirer ces rudiments et souder les antennes hélicoïdales standard fournies avec le Ra-01. Après une telle personnalisation, la portée de communication s'est sensiblement améliorée, mais un point latéral est apparu - l'antenne a un diamètre supérieur à la distance autorisée entre les modules. J'ai dû abandonner le module Final pour la durée du projet.
Premières difficultés de l'étanchéité synchronique
Il semblerait que prendre la bibliothèque WiFiUdp.h , où tout est pour l'existence confortable d'un serveur UDP, non. La bibliothèque est conçue pour soulever un serveur synchrone qui, malheureusement, ne peut pas servir plusieurs connexions en même temps. Une telle bibliothèque n'est pas adaptée à la tâche en cours. J'ai dû boire beaucoup de tasses de thé et chercher une bibliothèque qui nous permettrait d'élever un serveur UDP asynchrone capable de prendre en charge de nombreuses connexions en même temps. Une telle bibliothèque a été trouvée - AsyncUDP.h . Quelle est la différence entre un serveur synchrone et un serveur asynchrone? Jetons un coup d'œil à six épisodes de la figure 2, dans lesquels les options de fonctionnement du socket sont affichées de manière triviale.
Figure 2
Avec:
Un homme dans le rôle d'une prise ;
Dove dans le rôle de Compound ;
Pismo comme données .
Épisode A. Prise synchrone sans timeout
Une personne restera debout jusqu'à ce que la colombe lui apporte une lettre.
Épisode B. Prise synchrone avec timeout
Un homme attend l'heure convenue avec la Colombe, et s'il n'arrive pas à l'heure, l'homme partira.
Épisode C. Prise multithreading synchrone
Un homme lounges et regarde comme les pigeons livrent des lettres de leur propre chef.
Épisode D. Prise asynchrone (quand il n'y a rien d'autre à recevoir)
Un homme fait ses choses préférées, mais n'oublie pas les pigeons.
Épisode E. Prise asynchrone (quand il y a quelque chose à recevoir)
L'homme s'est brièvement distrait de ses affaires pour recevoir une lettre de la colombe.
Épisode F. Prise multithreading asynchrone
Un homme vaquer à ses occupations et regarde les Pigeons livrer des lettres par eux-mêmes.
Si vous avez fait attention, vous auriez probablement dû remarquer que les colliers des Pigeons dans chaque épisode ont une certaine couleur. Et ce n'est pas un hasard. Dans les épisodes A et B, un seul socket fonctionne sur le serveur et c'est tout. L'épisode C a déjà deux prises. Les épisodes D, E et F ont déjà trois prises. "Pourquoi y en a-t-il deux, mais en voici trois?" - demandez-vous. Ceci est conditionnellement 2 et 3, en fait, au lieu de 2, il peut être de 20 et au lieu de trois 200. La tâche consiste à montrer que les sockets asynchrones ne brûlent pas autant le fer que les synchrones.
Où va quoi?
Regardons le tableau 1, qui montre la structure du paquet UDP et réfléchissons à ce que vous pouvez faire à ce sujet.
Tableau 1. Structure des paquets UDP
Ajoutez un autre champ Session (1 octet) au tout début de ce tableau. C'est suffisant pour ce projet. En fonction de la session, l'appareil saura quoi faire avec le package suivant. Nous allons maintenant trouver des codes pour les sessions et les écrire dans le tableau 2.
Tableau 2. Description de la session
Bon. Voyons maintenant la composition des sessions dans le tableau 3.
Tableau 3. Sessions
A écrit deux clients pour Arduino et pour M5Stack. Vous pouvez voir comment cela fonctionne dans la vidéo . Il n'y a aucun problème dans l'appartement, je n'ai pas encore fait de tests sur le terrain.
Le code source est disponible sur GitHub à l'adresse
En savoir plus sur l'unité de base M5Stack et acheter ici.
Vous pouvez sélectionner les modules sans fil LoRa pour l'unité de base ici
Je serai heureux si ce projet vous est utile. Merci beaucoup pour votre temps!
Références et (ou) sources: