Vi skapar en gateway mellan Wi-Fi och LoRa för UDP
Jag hade en barndomsdröm â att ge varje hushĂ„lls "utan-WiFi"-enhet ett biljett till nĂ€tverket, dvs. en IP-adress och port. Efter ett tag insĂ„g jag att jag inte skulle skjuta upp det. Jag mĂ„ste bara göra det.
Teknisk specifikation
LÀgg till ett M5Stack-gateway med en installerad LoRa-modul (bild 1). Gatewayen kommer att anslutas till Wi-Fi-nÀtverket, dÀr den fÄr en lokal IP-adress via DHCP. Gatewayen kommer med jÀmna mellanrum att sÀnda sitt namn i "LoRa-vÀrlden" (analogt med SSID för Wi-Fi) och omrÄdet för tillÄtna portar sÄ att andra enheter vet att det finns ett sÄdant nÀtverk att ansluta sig till och inom vilket omrÄde de kan vÀlja en ledig port. Eftersom detta Àr en prototyp blir autentisering inte aktuellt denna gÄng. Nya klientenheter kommer att hitta det tillgÀngliga LoRa-nÀtverket och skicka den valda porten till det. NÀr gatewayen fÄr porten frÄn den nya klienten kontrollerar den om den Àr ledig, och om sÄ Àr fallet registrerar den den nya klienten och börjar lyssna pÄ den angivna porten pÄ sin egen asynkrona UDP-server. Efter registreringen kommer klienten att fÄ godkÀnnande eller avslag för att anvÀnda den angivna porten. Arbetsordningen Àr visad i tabell 1.
Bild 1
Tabell 1
sidan
riktning och data
sidan
session
[ klient ]
<â signal-björn â
[ gateway ]
0xA1
[ klient ]
â vald port â>
[ gateway ]
0xB1
[ klient ]
<â godkĂ€nnande eller avslag â
[ gateway ]
0xA2
[ klient ]
â UDP-paket â>
[ gateway ]
0xB2
[ klient ]
<â UDP-paket â
[ gateway ]
0xA3
[ nÀtverk ]
<â UDP-paket â
[ gateway ]
0xC1
Framför mig pÄ bordet ligger olika moduler för M5Stack som bara ligger dÀr. LÄt oss ta LoRa och ha lite kul med den. SjÀlva konceptet med moduler Àr fantastiskt! Vad sÀger man? Men jag har moduler av första revisionen, dÀr den inbyggda antennen Àr fruktansvÀrd, gjord av flexibel kretskort och klistrad pÄ sidan av chassit. Jag genomförde en gÄng fÀlttester med sÄdana moduler (du kan se dem pÄ en rysktalande YouTube-kanal):
SjĂ€lvklart var jag tvungen att ta bort dessa reliker och löda dit standard spiralantenner som följer med Ra-01. Efter denna anpassning förbĂ€ttrades kommunikationsavstĂ„ndet avsevĂ€rt, men det uppstod ett biverkningsproblem â antennen har en diameter som Ă€r större Ă€n det tillĂ„tna avstĂ„ndet mellan modulerna. Jag var tvungen att avstĂ„ frĂ„n den avslutande modulen under projektets gĂ„ng.
De första svÄrigheterna med synkroniseringens styvhet
Det verkar som om man bara kan ta biblioteket WiFiUdp.h, dĂ€r allt finns för den bekvĂ€ma driften av en UDP-server, sĂ„ Ă€r det inte. Biblioteket Ă€r designat för att starta en synkron server, som tyvĂ€rr inte kan hantera flera anslutningar i en och samma trĂ„d. Ett sĂ„dant bibliotek Ă€r inte lĂ€mpligt för den aktuella uppgiften. Jag var tvungen att dricka mĂ„nga koppar te och leta efter ett bibliotek som skulle möjliggöra att starta en asynkron UDP-server kapabel att stödja mĂ„nga anslutningar samtidigt. Ett sĂ„dant bibliotek hittades â AsyncUDP.h. Vad Ă€r dĂ„ skillnaden mellan en synkron och en asynkron server? LĂ„t oss titta pĂ„ sex episoder i figur 2, dĂ€r alternativen för sockarnas funktion visas pĂ„ ett trivialiskt sĂ€tt.
Figur 2
I huvudrollerna:
MĂ€nniskan i rollen som Sockeln;
Duvan i rollen som Anslutning;
Brev i rollen som Data.
Episod A. Synkron socket utan timeout
MÀnniskan stÄr kvar tills Duvan ger honom Brevet.
Episod B. Synkron socket med timeout
MÀnniskan vÀntar den överenskomna tid med Duvan och, om den inte anlÀnder i tid, kommer MÀnniskan att gÄ bort.
Episod C. Synkron socket med multitrÄdning
MÀnniskan latar sig och ser hur Duven sjÀlva levererar Brev.
Episod D. Asynkron socket (nÀr det inte finns nÄgot att ta emot)
MÀnniskan sysslar med sina favoritaktiviteter men glömmer inte Duvorna.
Episod E. Asynkron socket (nÀr det finns nÄgot att ta emot)
MÀnniskan avbryter sina sysslor för att ta emot brevet frÄn Duvan.
Episod F. Asynkron socket med multitrÄdning
MÀnniskan sysslar med sina uppgifter och ser hur Duven sjÀlva levererar Brev.
Om du har varit uppmĂ€rksam bör du ha lagt mĂ€rke till att halsbanden pĂ„ Duvorna i varje episod har en viss fĂ€rg. Och det Ă€r inte utan anledning. I episod A och B arbetar bara en socket pĂ„ servern. I episod C arbetar redan tvĂ„ sockets. I episoderna D, E och F finns det tre sockets. "Varför dĂ€r tvĂ„, men hĂ€r tre?" â frĂ„gar du. Det Ă€r hypotetiskt 2 och 3, istĂ€llet kan det i sjĂ€lva verket vara 20, och istĂ€llet för tre 200. MĂ„let Ă€r att visa att asynkrona sockets inte belastar hĂ„rdvaran lika mycket som synkrona.
Hur mycket fÄr plats?
LÄt oss titta pÄ tabell 1, som ger strukturen av en UDP-paket och tÀnka pÄ vad vi kan göra med detta.
Tabell 1. Struktur av UDP-paket
Bitar
0 â 15
16 â 31
0-31
AvsÀndarens port (Source port)
Mottagarens port (Destination port)
32-63
Datagrammets lÀngd (Length)
Kontrollsumma (Checksum)
64-âŠ
Data
LÄt oss lÀgga till ett fÀlt i början av denna tabell Session (1 Byte). Detta Àr tillrÀckligt för detta projekt. Baserat pÄ sessionen kommer enheten att veta hur den ska hantera paketet vidare. LÄt oss nu hitta koder för sessioner och registrera dem i tabell 2.
Tabell 2. Förklaring av sessioner
Kod
Namn
Förklaring
0xA1
Beacon
Gateway sÀnder namnet pÄ LoRa-nÀtverket och det godkÀnda portintervallet med viss periodicitet. Detta Àr nödvÀndigt sÄ att nya klienter ser det tillgÀngliga nÀtverket och nuvarande klienter, nÀr inga överföringar sker, kan avgöra signalstyrkan.
0xB1
FörfrÄgan
NÀr klienten upptÀcker nÀtverket skickar den den föredragna porten.
0xA2
GodkÀnnande eller avslag
Om den begÀrda porten Àr ledig svarar servern med ett godkÀnnande, annars med ett avslag.
0xB2
Up-link
NĂ€r klienten skickar ett UDP-paket till gatewayen.
0xA3
Down-link
NĂ€r gatewayen skickar ett UDP-paket till klienten.
0xC1
FortsÀttning av Up-link
NÀr gatewayen skickar ett UDP-paket till det lokala nÀtverket.
Bra. Nu lÄt oss diskutera sammansÀttningen av sessionerna i tabell 3.
Tabell 3. Sessioner
Namn pÄ session
SammansÀttning
Beacon
Sessionskod (1 Byte) + Namn pÄ LoRa-nÀtverk (4 Byte) + Startport (2 Byte) + Slutport (2 Byte)
FörfrÄgan
Ăverföringskod (1 Byte) + Namn pĂ„ LoRa-nĂ€tverk (4 Byte) + Föredragen port (2 Byte)
GodkÀnnande eller avslag
Ăverföringskod (1 Byte) + Namn pĂ„ LoRa-nĂ€tverk (4 Byte) + Föredragen port (2 Byte) + Resultat (1 Byte)
Up-link
Ăverföringskod (1 Byte) + Namn pĂ„ LoRa-nĂ€tverk (4 Byte) + AvlĂ€gset IP-adress (4 Byte) + AvlĂ€gset port (2 Byte) + Lokalt IP-adress (4 Byte) + Lokalt port (2 Byte) + Data storlek (2 Byte) + Data
Down-link
Ăverföringskod (1 Byte) + Namn pĂ„ LoRa-nĂ€tverk (4 Byte) + AvlĂ€gset IP-adress (4 Byte) + AvlĂ€gset port (2 Byte) + Lokalt IP-adress (4 Byte) + Lokalt port (2 Byte) + Data storlek (2 Byte) + Data
FortsÀttning av Up-link
AvlÀgset IP-adress (4 Byte) + AvlÀgset port (2 Byte) + Data storlek (2 Byte) + Data
Jag har skrivit tvÄ klienter för Arduino och M5Stack. PÄ kan ni se hur det fungerar. Inom lÀgenheten finns inga problem, fÀlttester har jag dock inte gjort Ànnu.
KÀllkoden Àr tillgÀnglig pÄ GitHub vid
För att veta mer om M5Stack-grundenhet och köpa den kan man
VÀlja trÄdlösa LoRa-moduler för grundutrustningen kan man
Jag skulle vara glad om detta projekt Àr till hjÀlp för dig. Stort tack för din tid!
Referenslista och (eller) kÀllor:
KĂ€lla: habr.com
