Vi laver en gateway mellem Wi-Fi og LoRa for UDP
Jeg havde en barndomsdrĂžm â at give hver husholdnings "uden Wi-Fi" en billet til nettet, dvs. en IP-adresse og port. Efter noget tid indsĂ„ jeg, at jeg ikke skulle udsĂŠtte det. Jeg mĂ„tte tage fat og gĂžre det.
Teknisk specifikation
At lave en gateway med M5Stack med det installerede LoRa-modul (figur 1). Gatewayen vil blive tilsluttet Wi-Fi-netvÊrket, hvor den vil fÄ en lokal IP-adresse via DHCP. Gatewayen vil med bestemte intervaller sende sit navn (analogt til SSID for Wi-Fi) og det tilladte portinterval, sÄ andre enheder ved, at der er et sÄdant netvÊrk, man kan tilslutte sig, og hvilken port man kan vÊlge fra. Da dette vil vÊre en prototype, er godkendelse ikke nÞdvendigt denne gang. Nye klientenheder vil finde det tilgÊngelige LoRa-netvÊrk og overfÞre den valgte port til det. NÄr gatewayen har modtaget den valgte port fra den nye klient, tjekker den, om den er ledig, og hvis ja, registrerer den den nye klient og begynder at lytte pÄ denne port pÄ sin egen asynkrone UDP-server. Efter registreringen vil klienten modtage accept eller afvisning til brug af den angivne port. Arbejdsprocessen er vist i tabel 1.
Figur 1
Tabel 1
side
retning og data
side
session
[ klient ]
<â signal-buoy â
[ gateway ]
0xA1
[ klient ]
â valgte port â>
[ gateway ]
0xB1
[ klient ]
<â accept eller afvisning â
[ gateway ]
0xA2
[ klient ]
â UPD-pakke â>
[ gateway ]
0xB2
[ klient ]
<â UPD-pakke â
[ gateway ]
0xA3
[ netvĂŠrk ]
<â UPD-pakke â
[ gateway ]
0xC1
PÄ mit bord ligger der forskellige moduler til M5Stack og keder sig. Lad os tage LoRa og have det sjovt med den. Selve konceptet med modulerne er vidunderligt! Hvad skal man sige? Men modulene er af fÞrste revision, som har en frygtelig indbygget antenne lavet af et fleksibelt printkort, der er klistret til sidevÊggen af kabinettet. Jeg har en gang gennemfÞrt feltforsÞg med sÄdanne moduler (man kan se dem pÄ en russisktalende YouTube-kanal):
Naturligvis mĂ„tte jeg fjerne disse rudimenter og lodde standard spiralantenner, der fĂžlger med Ra-01. Efter denne tilpasning blev kommunikationsafstanden betydeligt forbedret, men der opstod et bivirkning â antennen har en diameter stĂžrre end den maksimale afstand mellem modulene. Jeg mĂ„tte opgive den afsluttende modul i lĂžbet af projektet.
De fĂžrste vanskeligheder ved synkron stivhed
Det burde vĂŠre nemt, tag biblioteket WiFiUdp.h, hvor alt til komfortabel drift af en UDP-server findes, men desvĂŠrre ikke. Biblioteket er designet til at oprette en synkron server, som desvĂŠrre ikke kan hĂ„ndtere flere forbindelser i Ă©n trĂ„d samtidigt. Et sĂ„dant bibliotek er ikke egnet til den nuvĂŠrende opgave. Det var nĂždvendigt at drikke mange kopper te og lede efter et bibliotek, der ville muliggĂžre oprettelsen af en asynkron UDP-server, der kan understĂžtte mange forbindelser pĂ„ Ă©n gang. Et sĂ„dant bibliotek blev fundet â AsyncUDP.h. Hvad er sĂ„ forskellen mellem en synkron server og en asynkron? Lad os se pĂ„ seks episoder i figur 2, hvor forskellige tilstande af socket-arbejde illustreres trivielt.
Billede 2
Medvirkende:
Menneske i rollen som Socket;
Due i rollen som Forbindelse;
Brev i rollen som Data.
Episod A. Synkron socket uden timeout
Mennesket vil stÄ, indtil Duen bringer det et Brev.
Episod B. Synkron socket med timeout
Mennesket venter den tid, der er aftalt med Duen, og hvis den ikke ankommer til tiden, vil Mennesket gÄ.
Episod C. Synkron socket med multitrÄdighed
Mennesket slapper af og ser, hvordan Duene selv leverer Breve.
Episod D. Asynkron socket (nÄr der ikke er noget at modtage endnu)
Mennesket beskĂŠftiger sig med sine yndlingsaktiviteter, men glemmer ikke Duerne.
Episod E. Asynkron socket (nÄr der er noget at modtage)
Mennesket kan kortvarigt distrahere sig fra sine gÞremÄl for at modtage et brev fra Duen.
Episod F. Asynkron socket med multitrÄdighed
Mennesket beskÊftiger sig med sine gÞremÄl og ser, hvordan Duene selv bringer Breve.
Hvis du har vĂŠret opmĂŠrksom, har du sikkert bemĂŠrket, at halsbĂ„ndene pĂ„ Duene i hver episode har en bestemt farve. Og det er ikke uden grund. I episode A og B arbejder kun Ă©n socket pĂ„ serveren. I episode C er der allerede to sockets i brug. I episoderne D, E og F er der tre sockets. "Hvorfor er der to dĂ©r, og tre her?" â spĂžrger du. Det er betinget 2 og 3, men i virkeligheden kan der i stedet for 2 vĂŠre 20, og i stedet for tre 200. FormĂ„let er at vise, at asynkrone sockets ikke belaster hĂ„rdvaren sĂ„ meget som synkrone gĂžr.
Hvor meget hvad kan opbevares?
Lad os se pÄ tabel 1, der viser strukturen af en UDP-pakke, og overveje, hvad der kan gÞres med det.
Tabel 1. Struktur af en UDP-pakke
Bits
0 â 15
16 â 31
0-31
Afsenderens port (Source port)
Modtagerens port (Destination port)
32-63
DatagramlĂŠngde (Length)
Kontrolsum (Checksum)
64-âŠ
Data (Data)
Lad os tilfÞje endnu et felt i starten af denne tabel. Session (1 Byte). Dette er tilstrÊkkeligt til dette projekt. Baseret pÄ sessionen vil enheden vide, hvordan den skal hÄndtere pakken videre. Lad os nu finde pÄ koder til sessionerne og registrere dem i tabel 2.
Tabel 2. Forklaring til sessioner
Kode
Navn
Forklaring
0xA1
Beacon
Gateway sender navnet pÄ LoRa-netvÊrket og intervallet for tilladte porte med en bestemt frekvens. Dette er nÞdvendigt, sÄ nye kunder kan se det tilgÊngelige netvÊrk, og nuvÊrende kunder kan bestemme signalniveauet, nÄr der ikke er nogen transmissioner.
0xB1
Indsendelse
NĂ„r kunden opdager netvĂŠrket, sender de den Ăžnskede port.
0xA2
Accept eller afvisning
Hvis den Ăžnskede port er ledig, svarer serveren med accept, ellers med afvisning.
0xB2
Up-link
NĂ„r kunden sender en UDP-pakke til gatewayen.
0xA3
Down-link
NĂ„r gatewayen sender en UDP-pakke til kunden.
0xC1
FortsĂŠttelse af Up-link
NĂ„r gatewayen sender en UDP-pakke til det lokale netvĂŠrk.
Fint. Lad os nu diskutere indholdet af sessionerne i tabel 3.
Tabel 3. Sessioner
Sessionens navn
Indhold
Beacon
Sessionkode (1 Byte) + Navn pÄ LoRa-netvÊrk (4 Byte) + Startport (2 Byte) + Slutport (2 Byte)
Indsendelse
OverfÞrselskode (1 Byte) + Navn pÄ LoRa-netvÊrk (4 Byte) + Foretrukken port (2 Byte)
Accept eller afvisning
OverfÞrselskode (1 Byte) + Navn pÄ LoRa-netvÊrk (4 Byte) + Foretrukken port (2 Byte) + Resultat (1 Byte)
Up-link
OverfÞrselskode (1 Byte) + Navn pÄ LoRa-netvÊrk (4 Byte) + Fjern IP-adresse (4 Byte) + Fjern port (2 Byte) + Lokal IP-adresse (4 Byte) + Lokal port (2 Byte) + Data stÞrrelse (2 Byte) + Data
Down-link
OverfÞrselskode (1 Byte) + Navn pÄ LoRa-netvÊrk (4 Byte) + Fjern IP-adresse (4 Byte) + Fjern port (2 Byte) + Lokal IP-adresse (4 Byte) + Lokal port (2 Byte) + Data stÞrrelse (2 Byte) + Data
FortsĂŠttelse af Up-link
Fjern IP-adresse (4 Byte) + Fjern port (2 Byte) + Data stĂžrrelse (2 Byte) + Data
Jeg har skrevet to klienter til Arduino og M5Stack. Du kan se hvordan det fungerer. Der er ingen problemer inden for lejligheden, jeg har endnu ikke udfĂžrt feltprĂžver.
Kildekoden er tilgÊngelig pÄ GitHub pÄ
Du kan lĂŠre mere om M5Stack Basis-enheden og kĂžbe den
Du kan vÊlge trÄdlÞse LoRa-moduler til Basis-enheden
Jeg vil vĂŠre glad, hvis dette projekt bliver nyttigt for dig. Tak for din tid!
Litteraturliste og (eller) kilder:
Kilde: habr.com
