Lavpris trådløst sensornettverk på 433MHz -bånd: 5 trinn (med bilder)

2024 Forfatter: John Day | [email protected]. Sist endret: 2024-01-30 11:23

Tusen takk til Teresa Rajba for at du godtar meg med å bruke data fra publikasjonene deres i denne artikkelen

* På bildet ovenfor - de fem sensor -sender -enhetene som jeg brukte til testing

Hva er trådløse sensornettverk?

En enkel definisjon ville være: de trådløse sensornettverk refererer til en gruppe elektroniske enheter distribuert på et bestemt område for overvåking og registrering av miljødata, som overføres trådløst til et sentralt sted for å bli behandlet og lagret.

I dag kan trådløse sensornettverk brukes på flere måter, her er bare noen få eksempler:

• Områder med økologisk overvåking av skog, elver, innsjøer, hav og hav;
• Mulighet for å varsle i tilfelle o terroristiske, kjemiske, biologiske, epidemiske angrep;
• Overvåkingssystemer for barn, eldre, pasienter eller personer med spesielle behov;
• Overvåkingssystemer i landbruk og drivhus;
• Overvåkingssystem for værmeldinger;
• Overvåking av bytrafikk, skoler, parkeringsplasser;

Og mange, mange andre applikasjoner.

I denne artikkelen vil jeg vise resultatene av et eksperiment med trådløse sensornettverk som har blitt brukt til å overvåke temperatur- og fuktighetsdata, med en langsom og relativt forutsigbar variasjon. For dette eksperimentet valgte jeg å bruke sensorsendere som jeg bygde av meg selv ved hjelp av rimelige moduler. Mottakeren er også DIY, kommunikasjonen er enveis (på 433 MHz radiobånd), noe som betyr at sensorene bare sender dataene og den sentrale plasseringen bare mottar. Det er ingen kommunikasjon mellom sensorer og fra mottaker til sensorer.

Men hvorfor velge å bruke flere sendere og bare en mottaker? Den første grunnen vil åpenbart være "å gjøre det enkelt". Jo enklere monteringen er, desto mindre sannsynlig er det at den mislykkes, og det er definitivt mye lettere å reparere og bytte ut enkeltkomponentene ved feil. Strømforbruket er også lavere, batteriene vil vare lenger (sensorer bruker bare når de overvåkes og mottas, resten av tiden vil enheten være i dyp dvalemodus). Det faktum at det er enkelt, gjør enheten også billig. Et annet aspekt å huske på er dekningsområdet. Hvorfor? Det er mye lettere å bygge og bruke en sensitiv mottaker enn å ha en sensitiv mottaker og en kraftig sender på både sensorene og sentralmodulen (dette er nødvendig for en god toveiskommunikasjon). Med en sensitiv og god mottaker er det mulig å motta data fra lang avstand, men utsendelse av data for samme avstand krever høy utslippskraft, og dette kommer med høye kostnader, strømforbruk og (la oss ikke glemme) muligheten til å overskride lovlig maksimal sendereffekt på 433 MHz -båndet. Ved å bruke en mottaker av middels kvalitet, billig, men med en antenne av høy kvalitet (selv DIY) og billige sendere med en antenne av god kvalitet, kan vi oppnå gode resultater til en brøkdel av kostnaden for eksisterende trådløse sensornettverk.

Trinn 1: Teoretiske overveielser

Ideen om å bygge et trådløst sensornettverk for å overvåke temperatur og fuktighet i luft og jord i forskjellige områder av et drivhus kom meg inn i tankene for lenge siden, nesten 10 år siden. Jeg ønsket å bygge et 1-leders nettverk og å bruke 1-leders temperatur- og fuktighetssensorer. Dessverre, for 10 år siden var fuktighetssensorer sjeldne og dyre (selv om temperatursensorer var utbredt), og siden det ikke virket som å spre ledninger over hele drivhuset, ga jeg opp ideen ganske raskt.

Imidlertid har situasjonen endret seg radikalt. Vi kan finne billige sensorer av god kvalitet (temperatur og fuktighet), og vi har også tilgang til billige sendere og mottakere på 433 MHz-båndet. Det er bare ett problem: hvis vi har flere sensorer (la oss si 20), hvordan løser vi kollisjonene (vær oppmerksom på at dette er en enveiskommunikasjon), det vil si overlapping av utslipp av 2 eller flere sensorer? Mens jeg lette etter en mulig løsning, kom jeg over disse veldig interessante papirene:

Trådløs sensor konvergerer cast basert på prosedyrer for tilfeldige operasjoner - av RAJBA, T. og RAJBA, S.

og

Sannsynligheten for kollisjoner i Wireless Sensor Network med tilfeldig sending - av RAJBA S. og RAJBA. T

I utgangspunktet viser forfatterne oss at sannsynligheten for kollisjoner i et trådløst sensornettverk kan beregnes hvis pakkene sendes ut på bestemte tidspunkter i henhold til en giftig (eksponentiell) fordeling.

Et utdrag fra artikkelen ovenfor viser egenskapene til det studerte nettverket.

• ganske stort antall sensor-avsender-enheter N;
• sensor-sender enheter forblir helt uavhengige og å slå dem på eller av har ingen innflytelse på nettverksdriften;
• alle sensor-senderenheter (eller en del av dem) kan være mobile, forutsatt at de er innenfor radioområdet til mottakerstasjonen;
• de sakte endrede fysiske parametrene måles, noe som betyr at det ikke er nødvendig å overføre dataene veldig ofte (f.eks. hvert flere minutter eller flere titalls minutter);
• overføringen er av enveistype, det vil si fra sensor-senderenheten opp til mottakspunktet med T gjennomsnittlige tidsintervaller. Informasjon overføres i protokollen på t_s varighet;
• enhver valgt sensor begynner å sende tilfeldig på Poisson -tidspunkter. PASTA (Poisson Arrivals See Time Averages) vil bli brukt til å rettferdiggjøre sending av sonder ved Poisson -epoker;
• alle sensor-sender-enheter forblir tilfeldig uavhengige, og de vil overføre informasjonen på et tilfeldig valgt tidspunkt på t_s varighet og T gjennomsnittlig repetisjonstid;
• hvis en eller flere sensorer begynner å sende mens protokollen til t_s varighet blir overført fra en annen sensor, en slik situasjon kalles kollisjon. Kollisjon gjør det umulig for sentralstasjonen å motta informasjonen på en riktig måte.

Den passer nesten perfekt til sensornettverket jeg vil teste …

Nesten.

Jeg sier ikke at jeg helt forsto matematikken i avisen, men på grunnlag av dataene som ble presentert og på konklusjonene har jeg klart å forstå hva det handler om. Det eneste er at en verdi som ble brukt i avisen gjorde meg litt bekymret:). Det er variabelen t_s - varigheten av dataoverføringen som antas å være 3,2x10^-5 s. Så overføringstiden for de innsamlede dataene vil være 3,2 oss! Dette kan ikke gjøres på 433 MHz -båndet. Jeg vil bruke enten rcs -bryteren eller radiohodet til å programmere sendersensorene. Når jeg studerte kodene til de to bibliotekene, kom jeg til den konklusjon at den minste overføringstiden ville være 20 ms, godt over verdien på 3,2 oss. Med 2,4 GHz sendere er det mulig t_s tiden er så liten … men det er en annen historie.

Hvis vi bruker formelen foreslått av forfatterne av denne artikkelen, blir resultatet:

Innledende data (et eksempel):

• Antall sensorer N = 20;
• Dataoverføringsvarighet t_s= 20x10^-3 s (0,020s)
• Gjennomsnittlig overføringsintervall T = 180s

Formelen:

Sannsynlighet for kollisjon på T -intervall er

hvis vi tar hensyn til de første dataene, vil sannsynligheten for kollisjon på T -intervallet være 0,043519

Denne verdien, som indikerer sannsynligheten for å ha 4,35 kollisjoner per 100 målinger, er etter min mening ganske god. Sannsynligheten kan bli bedre hvis vi øker gjennomsnittlig overføringstid, så ved en verdi på 300s vil vi ha en sannsynlighet på 0,026332, dvs. 2,6 kollisjoner per 100 målinger. Hvis vi mener at vi kan forvente tap av pakkedata uansett under systemets drift (avhengig av værforholdene for eksempel), er dette tallet virkelig utmerket.

Jeg ønsket å gjøre en simulering av denne typen nettverk, men også en slags designassistent, så jeg laget et lite program i C, du kan finne kildekoden på github (også en kompilert binær som kjører i Windows kommandolinje - utgivelse).

Inndata:

• sensor_number - antall sensorer på nettverket;
• dimensions_number - antall målinger som skal simuleres;
• gjennomsnittlig_overføringsintervall -gjennomsnittlig tid mellom påfølgende dataoverføringer;
• transmission_time - den effektive varigheten av dataoverføring.

Produksjon:

• den beregnede maksimale måletiden;
• listen over kollisjoner mellom to sensorer;
• antall kollisjoner;
• teoretisk sannsynlighet for kollisjonene.

Resultatene er ganske interessante:)

Nok med teorien, jeg vil ikke insistere mer på den teoretiske delen, artiklene og kildekoden er ganske veltalende, så det er bedre å gå til praktisk, effektiv implementering av det trådløse sensornettverket og til testresultatene.

Trinn 2: Praktisk implementering - maskinvaren

For sendersensorer trenger vi følgende komponenter:

• ATtiny85 mikrokontroller 1.11 $;
• Sokkel for integrert krets 8DIP 0,046 $;
• Temperatur/fuktighetssensor DHT11 0,74 $;
• 433MHz H34A sendermodul 0,73 $;
• 4xAA batteriholder med bryter 1 $;

Totalt 3,63 $;

Mottakeren som ble brukt til testene er en Arduino UNO (bare for testing) og en H3V4F -mottaksmodul (0,66 $) med en billig lysbueantenne (0,32 $).

Sensor-sender skjemaer

Senderen-sensorenhetene drives av 3xAA, 1,5v batterier (i det fjerde rommet i batteriholderen er det elektronisk sett). Som du kan se senderens strømforsyning og temperaturfuktighetssensoren er koblet til PB0-pinnen til mikrokontrolleren (senderen og sensoren får strøm når pinnen er satt til HIGH). Så når mikrokontrolleren er i dvalemodus, kan den nå et strømforbruk på 4,7 uA. Med tanke på at vekketiden til sendersensoren ville være omtrent 3 sekunder (måling, overføring osv.) Og gjennomsnittlig tid mellom sendingene på 180 sek (som eksemplet i forrige kapittel), bør batteriene motstå ganske mye. Med noen alkaliske batterier av god kvalitet (dvs. 2000 mAh) kan autonomien være over 10 måneder som beregnet på omnicalculator.com (der det totale strømforbruket er: sensor - 1,5mA, sendermodul - 3,5mA og ATtiny85 mikrokontroller - 5mA, totalt 10mA).

På bildet nedenfor kan du se den nesten ferdige sensoren-avsenderenheten.

Nedenfor er bildet av testmottakerenheten.

Trinn 3: Praktisk implementering - programvare

Programvaren som er lastet opp som kjører til attiny85 mikrokontroller, hovedkomponenten i sensor-avsender-enhetene, har til hensikt å lese dataene fra sensoren, konvertere den til å bli sendt via radio og overføre den innenfor Poisson-tidsrammer (eksponentiell distribusjon eller PASTA - Poisson Arrivals Se tidsgjennomsnitt). Ved å bruke en enkel funksjon overvåker den også statusen til batteriene og gir en advarsel hvis nødvendig spenning for sensoren ikke lenger er gitt. Kildekoden er tilgjengelig på github. Koden for testmottakeren er veldig enkel. Jeg legger den ut nedenfor.

// modifisert rcswitch-bibliotek fra https://github.com/Martin-Laclaustra/rc-switch/tree/protocollessreceiver// koden er en modifisert versjon fra eksempler på det originale rcswitch-biblioteket #include RCSwitch mySwitch = RCSwitch (); usignerte lange data = 0; ugyldig oppsett () {Serial.begin (9600); mySwitch.enableReceive (0); // Mottaker på interrupt 0 => det er pin #2} void loop () {if (mySwitch.available ()) {unsigned long data = mySwitch.getReceivedValue (); // output (mySwitch.getReceivedValue (), mySwitch.getReceivedBitlength (), mySwitch.getReceivedDelay (), mySwitch.getReceivedRawdata (), mySwitch.getReceivedProtocol ()); int fuktighet = bitExtracted (data, 7, 1); // mindre signifikante 7bits fra posisjon 1 - første bit bit int til høyre = bitExtracted (data, 7, 8); // neste 7bits fra posisjon 8 til høyre og så videre int v_min = bitExtracted (data, 1, 15); int packet_id = bitExtracted (data, 3, 16); // 3bits - 8 pakke -ID fra 0 til 7 int sensor_id = bitExtracted (data, 6, 19); // 6bit for 64 sensor -ID -er - totalt 24 bits Serial.print (sensor_id); Serial.print (","); Serial.print (packet_id); Serial.print (","); Serial.print (temperatur); Serial.print (","); Serial.print (fuktighet); Serial.println (); mySwitch.resetAvailable (); }} // kode fra https://www.geeksforgeeks.org/extract-k-bits-given-position-number/ int bitExtracted (unsigned long number, int k, int p) {return (((1 (p- 1))); }

Jeg har prøvd å inkludere så mange kommentarer som mulig for å gjøre ting lettere å forstå.

For feilsøking brukte jeg softwareserialbiblioteket og attiny85 -utviklingsbordet med USBasp -programmereren (se også min instruks om dette). Den serielle lenken er laget med Serial til TTL -omformer (med en PL2303 -brikke) koblet til de bøyde pinnene (3 og 4) på utviklingskortet (se bildet nedenfor). Alt dette har vært en uvurderlig hjelp for å fullføre koden.

Trinn 4: Testresultater

Jeg har laget 5 sensor-avsender-enheter som samler og sender verdier målt av DHT11-sensorene. Jeg registrerte og lagret målinger ved hjelp av testmottakeren og et terminalemuleringsprogram (foxterm) i løpet av tre dager. Jeg valgte et 48 timers intervall for studier. Jeg var ikke nødvendigvis interessert i måleverdiene (sensor 2, for eksempel viser det meg feil verdier), men i antall kollisjoner. I tillegg ble sensorene plassert svært nær (på 4-5 m) av mottakeren for å eliminere andre årsaker til tap av pakker. Testresultatene er lagret i en cvs -fil og lastet opp (se på filen nedenfor). Jeg lastet også opp en excel -fil basert på denne csv -filen. Jeg tok noen skjermbilder for å vise deg hvordan en kollisjon ser ut (selvfølgelig i testene mine). Jeg la også kommentarer til hvert skjermbilde.

Du lurer kanskje på hvorfor jeg ikke brukte en datalaster -tjeneste, for eksempel ThingSpeak. Faktum er at jeg har mange poster, mange sensorer og data som ofte kommer med uregelmessige intervaller, og online IoT -tjenester tillater bare data med et visst antall sensorer og bare med ganske store intervaller. Jeg tenker i fremtiden å installere og konfigurere min egen IoT -server.

Til slutt resulterte 4598 målinger på 5 sensorsenderenheter (ca. 920/sensor) i totalt 5 kollisjoner i en periode på 48 timer (0,5435 kollisjoner/100 målinger). Å gjøre litt matte (ved hjelp av wsn_test -programmet med innledende data: 5 sensorer, gjennomsnittstid 180s, overføringstid 110 ms) kollisjonssannsynlighet ville være 0,015185 (1,52 kollisjoner/100 målinger). De praktiske resultatene er enda bedre enn de teoretiske resultatene, ikke sant?:)

Uansett er det også 18 pakker tapt i denne perioden, så kollisjonene spiller egentlig ikke så stor rolle i denne forbindelse. Selvfølgelig bør testen finne sted over en lengre periode for å få de mest avgjørende resultatene, men etter min mening er den en suksess selv under disse forholdene og bekrefter fullt ut de teoretiske forutsetningene.

Trinn 5: Avsluttende tanker

Umiddelbar søknad

I et stort drivhus dyrkes flere avlinger. Hvis vanningen gjøres manuelt uten klimaovervåking, uten automatisering, uten dataregistrering er det fare for over- eller under vanning, og også vannforbruket er høyt, er det ingen bevis for vannforbrukoptimalisering, det er risiko for avlinger i generell. For å unngå dette kan vi bruke et trådløst sensornettverk:)

Temperatursensorer, luftfuktighetssensorer, jordfuktighetssensorer kan plasseres rundt i drivhuset, og ved hjelp av overførte data kan flere handlinger utføres: start-stopp elektriske ventiler for å la vannet flyte der det er nødvendig, start-stopp elektriske vifter for å redusere temperaturen i forskjellige områder, start-stopp-varmeovner etter behov og alle dataene kan arkiveres for fremtidig analyse. Systemet kan også tilby et webgrensesnitt som er tilgjengelig overalt og e -post- eller SMS -alarmer i tilfelle unormal tilstand.

Hva blir det neste?

• Testing med et større antall sensorer;
• Sanntidstesting med eksterne sensorer i dekningsområdet;
• Installere og konfigurere en lokal IoT -server (for eksempel på en Raspberry Pi);
• Tester også med sender (transceiver) -sensorer på 2,4 GHz.

så … fortsetter …:)

ANSVARSFRASKRIVELSE: Bruk av 433MHz frekvensbåndet i din region kan være underlagt radiofrekvensbestemmelser. Kontroller lovligheten din før du prøver dette prosjektet

Andreplass i sensorkonkurransen