UDP számára Wi-Fi és LoRa közötti átjárót készítünk
Gyermekkori álmom volt, hogy minden háztartási "Wi-Fi nélküli" eszköznek jegyet adjak a hálózatra, azaz IP-címet és portot. Idővel rájöttem, hogy nem szabad halogatni. Csinálni kell.
Műszaki követelmény
Készítse el az M5Stack átjárót telepített LoRa modullal (1. ábra). Az átjáró csatlakozni fog a Wi-Fi hálózathoz, ahol DHCP-n keresztül helyi IP-címet kap. Az átjáró meghatározott időközönként sugározni fog a "LoRa-éterben" a nevét (hasonlóan az SSID-hez a Wi-Fi-nél) és a megengedett portok tartományát, hogy más eszközök tudják, hogy létezik egy ilyen hálózat, amelyhez csatlakozni lehet, és milyen tartományban lehet kiválasztani a szabad portot. Mivel ez prototípus lesz, az azonosítás most nem szükséges. Az új kliens eszközök megtalálják a hozzáférhető LoRa hálózatot és átküldik a választott portot. Miután az átjáró megkapta az új kliens portját, ellenőrzi, hogy szabad-e; ha igen, akkor regisztrálja az új klienst és elkezd figyelni a megadott porton a saját aszinkron UDP szerverén. A regisztráció után a kliens hozzájárulást vagy elutasítást kap a megadott port használatára. A működés rendje az 1. táblázatban látható.
1. ábra
1. táblázat
oldal
irány és adatok
oldal
ülés
[ kliens ]
<— jelzi a világítótornyot —
[ átjáró ]
0xA1
[ kliens ]
— kiválasztott port —>
[ átjáró ]
0xB1
[ kliens ]
<— hozzájárulás vagy elutasítás —
[ átjáró ]
0xA2
[ kliens ]
— UDP-csomag —>
[ átjáró ]
0xB2
[ kliens ]
<— UDP-csomag —
[ átjáró ]
0xA3
[ hálózat ]
<— UDP-csomag —
[ átjáró ]
0xC1
Az íróasztalon különféle M5Stack modulok fekszenek és unatkoznak. Vegyük a LoRát és szórakozzunk vele. A modulok koncepciója csodálatos! Mit is mondhatnék? De a moduljaim az első verzióval rendelkeznek, amelyeknek borzalmas beépített antennájuk van, amely egy hajlékony nyomtatott áramkörre van ragasztva a ház oldalfalára. Egyszer mezőteszteket végeztem ezeken a modulokon (meg lehet nézni a orosz nyelvű YouTube csatornámon):
Természetesen el kellett távolítani ezeket a maradványokat és standard spirálantennákat kellett beforrasztanom, amelyek a Ra-01-hez járnak. Ezen testreszabás után a kapcsolat távolsága jelentősen javult, de lett egy mellékhatás — az antenna átmérője nagyobb, mint a modulok közötti megengedett távolság. Kénytelen voltam lemondani a Záró modulról a projekt idejére.
Az első nehézségek a szinkron merevségből adódnak
Úgy tűnik, elég, ha kitöltöm a könyvtárat WiFiUdp.h, ahol minden a kényelmes UDP-kiszolgáló működéséhez szükséges, nos, nincs. A könyvtár egy szinkronkiszolgáló felállítására van optimalizálva, ami, sajnos, nem képes több kapcsolat kezelésére egy szálban. Ez a könyvtár nem alkalmas a jelenlegi feladatra. Sok csésze tea elfogyasztása után muszáj volt keresni egy olyan könyvtárat, amely lehetővé teszi egy aszinkron UDP-kiszolgáló felállítását, amely képes egyszerre több kapcsolatot támogatni. Egy ilyen könyvtárat megtaláltunk — AsyncUDP.h. Mi a különbség a szinkron és az aszinkron kiszolgáló között? Nézzük meg a 2. ábrán hat epizódot, amelyben trivialis módon vannak bemutatva a socketek működési lehetőségei.
2. ábra
Főszereplők:
Ember mint Socket;
Galamb mint Kapcsolat;
Levél mint Adatok.
A epizód. Szinkron socket időtúllépés nélkül
Az ember állni fog, amíg a galamb el nem hozza neki a levelet.
B epizód. Szinkron socket időtúlmérővel
Az ember vár a galambbal egyeztetett időtartamig, és ha az nem érkezik meg időben, akkor elmegy.
C epizód. Szinkron socket több szálas működéssel
Az ember tétlenül nézi, ahogy a galambok saját maguktól kézbesítik a leveleket.
D epizód. Aszinkron socket (amikor még nincs mit fogadni)
Az ember a kedvenc tevékenységeivel foglalkozik, de nem felejti el a galambokat.
E epizód. Aszinkron socket (amikor van mit kapni)
Az ember rövid időre elterelte a figyelmét a dolgaiból, hogy levelet kapjon a galambtól.
F epizód. Aszinkron socket több szálas működéssel
Az ember a dolgaival foglalkozik és nézi, ahogy a galambok saját maguktól kézbesítik a leveleket.
Ha figyelmes voltál, biztosan észrevetted, hogy a galambok nyakörvei minden epizódban meghatározott színűek. És nem véletlenül. Az A és B epizódban a kiszolgálón csak egy socket működik, és ennyi. A C epizódban már két socket van működésben. A D, E és F epizódokban már három socket működik. 'Miért van ott kettő, meg itt három?' — kérdezed. Ez csak elméletben 2 és 3, valójában a két helyett 20, a három helyett pedig 200 is lehet. A feladat az, hogy megmutassuk, hogy az aszinkron socketek nem terhelik úgy le a hardvert, mint a szinkronosok.
Mennyi fér el hol?
Nézzük meg az 1. táblázatot, amely bemutatja az UDP csomag struktúráját, és gondolkodjunk el, mit lehet ezzel tenni.
1. táblázat. Az UDP csomag struktúrája
Bitek
0 — 15
16 — 31
0-31
Küldő port (Source port)
Célport (Destination port)
32-63
Datagram hossz (Length)
Ellenőrző összeg (Checksum)
64-…
Adatok (Data)
Hozzáadunk egy mezőt a táblázat elejéhez Ülés (1 Byte). Ez elegendő ehhez a projekthez. Az ülés alapján az eszköz tudni fogja, mit tegyen a további csomaggal. Most kitaláljuk az ülések kódjait, és felvesszük őket a 2. táblázatba.
2. táblázat. Ülések magyarázata
Kód
Név
Magyarázat
0xA1
Májk
A híd periodikusan kihirdeti a LoRa-hálózat nevét és a megengedett portok tartományát. Ez szükséges, hogy az új kliensek láthassák a rendelkezésre álló hálózatot, míg a meglévő kliensek, amikor nincsenek átvitelek, meg tudják határozni a jel szintjét.
0xB1
Kérelem
Amikor a kliens felfedezte a hálózatot, elküldi a preferált portot.
0xA2
Hozzájárulás vagy elutasítás
Ha a kért port szabad, a szerver hozzájárulással válaszol, ellenkező esetben elutasítással.
0xB2
Felfelé irányuló kapcsolat
Amikor a kliens UDP-csomagot küld a hídnak.
0xA3
Lefelé irányuló kapcsolat
Amikor a híd UDP-csomagot küld a kliensnek.
0xC1
Felfelé irányuló kapcsolat folytatása
Amikor a híd UDP-csomagot küld a helyi hálózatba.
Jó. Most beszéljük meg az ülések összetételét a 3. táblázatban.
3. táblázat. Ülések
Ülés neve
Összetétel
Májk
Ülés kód (1 Byte) + LoRa-hálózat neve (4 Byte) + Kezdő port (2 Byte) + Végső port (2 Byte)
Kérelem
Küldési kód (1 Byte) + LoRa-hálózat neve (4 Byte) + Preferált port (2 Byte)
Hozzájárulás vagy elutasítás
Küldési kód (1 Byte) + LoRa-hálózat neve (4 Byte) + Preferált port (2 Byte) + Eredmény (1 Byte)
Felfelé irányuló kapcsolat
Küldési kód (1 Byte) + LoRa-hálózat neve (4 Byte) + Távoli IP-cím (4 Byte) + Távoli port (2 Byte) + Helyi IP-cím (4 Byte) + Helyi port (2 Byte) + Adatok mérete (2 Byte) + Adatok
Lefelé irányuló kapcsolat
Küldési kód (1 Byte) + LoRa-hálózat neve (4 Byte) + Távoli IP-cím (4 Byte) + Távoli port (2 Byte) + Helyi IP-cím (4 Byte) + Helyi port (2 Byte) + Adatok mérete (2 Byte) + Adatok
Felfelé irányuló kapcsolat folytatása
Távoli IP-cím (4 Byte) + Távoli port (2 Byte) + Adatok mérete (2 Byte) + Adatok
Két klienst írtam Arduinóra és M5Stack-ra. A megnézheti, hogyan működik. A lakáson belül nincs probléma, terepi teszteket még nem végeztem.
A forráskód elérhető a GitHub-on a
Tudjon meg többet a M5Stack alap eszközről, és vásárolhat
Válasszon vezeték nélküli LoRa modulokat az alap eszközhöz
Örömmel veszem, ha ez a projekt hasznos lesz az Ön számára. Köszönöm, hogy időt szánt rá!
Irodalomjegyzék és (vagy) források:
Forrás: habr.com
