Facem un gateway între Wi-Fi și LoRa pentru UDP
Am avut un vis de copil - să ofer fiecărui dispozitiv „fără Wi-Fi” un bilet în rețea, adică o adresă IP și un port. După un timp, am realizat că nu mai este un motiv să aștept. Trebuie să iau și să fac.
Cerințele tehnice
Să facem un gateway M5Stack cu modulul LoRa instalat (figura 1). Gateway-ul va fi conectat la rețeaua Wi-Fi, unde va obține o adresă IP locală prin DHCP. Gateway-ul va difuza periodic în "etereul LoRa" numele său (analog SSID pentru Wi-Fi) și gama de porturi acceptabile, astfel încât alte dispozitive să știe că există o astfel de rețea la care se pot conecta și în ce interval pot selecta un port liber. Deoarece acesta va fi un prototip, autentificarea nu va fi realizată de data aceasta. Noile dispozitive-client vor găsi rețeaua LoRa disponibilă și îi vor transmite portul selectat. După ce gateway-ul primește de la noul client portul, verifică dacă este liber, iar dacă da, înregistrează noul client și începe să asculte pe acest port pe propriul server UDP asincron. După înregistrare, clientul va primi acceptul sau refuzul pentru utilizarea portului solicitat. Ordinea de lucru este afișată în tabelul 1.
Figura 1
Tabelul 1
pagina
direcție și date
pagina
ședință
[ client ]
<— semnal - far —
[ gateway ]
0xA1
[ client ]
— portul selectat —>
[ gateway ]
0xB1
[ client ]
<— accept sau refuz —
[ gateway ]
0xA2
[ client ]
— pachet UPD —>
[ gateway ]
0xB2
[ client ]
<— pachet UPD —
[ gateway ]
0xA3
[ rețea ]
<— pachet UPD —
[ gateway ]
0xC1
În fața mea, pe masă, se află diverse Module pentru M5Stack care se plictisesc. Hai să luăm LoRa și să ne distrăm cu ea. Conceptul modulelor este minunat! Ce să spun? Dar, modulele pe care le am sunt din prima revizie, în care antena încorporată este teribilă, realizată pe un circuit flexibil lipit de peretele lateral al carcasei. Odată am efectuat teste în teren cu aceste module (puteți viziona pe canalul rus de YouTube):
Desigur, a fost nevoie să îndepărtez aceste rămășițe și să lipesc antene spirale standard, care vin împreună cu Ra-01. După o asemenea personalizare, raza de acțiune s-a îmbunătățit semnificativ, dar a apărut un efect secundar - antena are un diametru mai mare decât distanța maximă permisă între module. A fost necesar să renunț la modulul final pentru timpul proiectului.
Primele dificultăți de la rigiditatea sincronizării
Se părea că trebuie să iau biblioteca WiFiUdp.h, unde există tot ce este necesar pentru existența confortabilă a unui server UDP, însă nu. Biblioteca este destinată pentru a ridica un server sincronizat, care, din păcate, nu poate gestiona simultan mai multe conexiuni într-un singur fir. O astfel de bibliotecă nu este potrivită pentru sarcina actuală. A fost nevoie să consum multe cești de ceai și să caut o bibliotecă care să permită ridicarea unui server UDP asincron capabil să susțină multe conexiuni simultan. O astfel de bibliotecă a fost găsită — AsyncUDP.h. Care este deosebirea dintre un server sincron și unul asincron? Haideți să examinăm șase episoade în figura 2, în care sunt ilustrate în mod trivial opțiunile de funcționare ale socket-urilor.
Figura 2
În rolurile principale:
Omul în rolul Socket-ului;
Porumbel în rolul Conexiuni;
Scrisoare în rolul Date.
Ep. A. Socket sincron fără timeout
Omul va sta până când Porumbelul îi va aduce Scrisoarea.
Ep. B. Socket sincron cu timeout
Omul așteaptă timpul convenit cu Porumbelul, iar dacă acesta nu sosește la timp, Omul va pleca.
Ep. C. Socket sincron cu multi-threading
Omul stă degeaba și observă cum Porumbeii livrează singuri Scrisorile.
Ep. D. Socket asincron (când nu este nimic de primit)
Omul se ocupă de pasiunile sale, dar nu uită de Porumbei.
Ep. E. Socket asincron (când este ceva de primit)
Omul s-a distrat pentru scurt timp de la treburile sale pentru a primi o scrisoare de la Porumbel.
Ep. F. Socket asincron cu multi-threading
Omul își desfășoară activitățile și observă cum Porumbeii livrează singuri Scrisorile.
Dacă ați fost atenți, cu siguranță ați observat că zgardele de pe Porumbei în fiecare episod au o anumită culoare. Și nu este întâmplător. În episodul A și B, pe server funcționează doar un singur socket și atât. În episodul C funcționează deja două socket-uri. În episoadele D, E și F sunt deja câte trei socket-uri. „De ce sunt acolo două, iar aici trei?” — veți întreba. Acestea sunt pur și simplu 2 și 3, dar în realitate, în loc de 2 ar putea fi 20, iar în loc de 3, 200. Sarcina este de a arăta că socket-urile asincrone nu solicită hardware-ul atât de mult ca cele sincronizate.
Cât de mult poate încăpea?
Să examinăm tabelul 1, în care este prezentată structura pachetului UDP și să ne gândim ce putem face cu aceasta.
Tabelul 1. Structura pachetului UDP
Biți
0 — 15
16 — 31
0-31
Portul sursă (Source port)
Portul destinație (Destination port)
32-63
Lungimea datagramei (Length)
Sumă de control (Checksum)
64-…
Date
Să adăugăm un câmp suplimentar la începutul acestei tabele Sesiune (1 Byt). Acest lucru este suficient pentru acest proiect. Pe baza Sesiunii, dispozitivul va ști ce să facă cu pachetul mai departe. Acum să venim cu coduri pentru sesiuni și să le înregistrăm în tabelul 2.
Tabelul 2. Explicația sesiunilor
Cod
Denumire
Explicație
0xA1
Bază
Gateway-ul transmite numele rețelei LoRa și intervalul de porturi acceptate cu o anumită frecvență. Acest lucru este necesar pentru ca noii clienți să poată vedea rețeaua disponibilă, iar clienții existenți, atunci când nu sunt transmisii, să poată determina intensitatea semnalului.
0xB1
Cerere
Când clientul descoperă rețeaua, acesta trimite portul preferat.
0xA2
Acceptare sau refuz
Dacă portul solicitat de client este liber, serverul răspunde cu acceptare, iar în caz contrar, cu refuz.
0xB2
Up-link
Când clientul trimite un pachet UDP către gateway.
0xA3
Down-link
Când gateway-ul trimite un pachet UDP către client.
0xC1
Continuare Up-link
Când gateway-ul trimite un pachet UDP în rețeaua locală.
Bine. Acum să discutăm despre compunerea sesiunilor din tabelul 3.
Tabelul 3. Sesiuni
Numele sesiunii
Compoziție
Bază
Codul sesiunii (1 Byt) + Numele rețelei LoRa (4 Byt) + Portul de început (2 Byt) + Portul final (2 Byt)
Cerere
Codul de transmisie (1 Byt) + Numele rețelei LoRa (4 Byt) + Portul preferat (2 Byt)
Acceptare sau refuz
Codul de transmisie (1 Byt) + Numele rețelei LoRa (4 Byt) + Portul preferat (2 Byt) + Rezultatul (1 Byt)
Up-link
Codul de transmisie (1 Byt) + Numele rețelei LoRa (4 Byt) + Adresa IP externă (4 Byt) + Portul extern (2 Byt) + Adresa IP locală (4 Byt) + Portul local (2 Byt) + Dimensiunea datelor (2 Byt) + Datele
Down-link
Codul de transmisie (1 Byt) + Numele rețelei LoRa (4 Byt) + Adresa IP externă (4 Byt) + Portul extern (2 Byt) + Adresa IP locală (4 Byt) + Portul local (2 Byt) + Dimensiunea datelor (2 Byt) + Datele
Continuare Up-link
Adresa IP externă (4 Byt) + Portul extern (2 Byt) + Dimensiunea datelor (2 Byt) + Datele
Am scris doi clienți pentru Arduino și pentru M5Stack. Pe puteți vedea cum funcționează. În interiorul apartamentului nu sunt probleme, testele pe teren nu le-am efectuat încă.
Codul sursă este disponibil pe GitHub la
Pentru a afla mai multe despre dispozitivul de bază M5Stack și pentru a-l cumpăra, accesați
Alegeți modulele de comunicație LoRa pentru dispozitivul de bază poate
Aș fi bucuros dacă acest proiect vă va fi de folos. Vă mulțumesc mult pentru timpul acordat!
Lista de referințe și (sau) surse:
Sursa: habr.com
