Lågpris trådlöst sensornätverk på 433MHz -band: 5 steg (med bilder)

2024 Författare: John Day | [email protected]. Senast ändrad: 2024-01-30 12:44

Stort tack till Teresa Rajba för att du vänligt gav mig sitt godkännande att använda data från deras publikationer i denna artikel

* På bilden ovan - de fem sensor -avsändarenheter som jag använde för testning

Vad är trådlösa sensornätverk?

En enkel definition skulle vara: de trådlösa sensornätverken hänvisar till en grupp elektroniska enheter distribuerade på ett visst område för övervakning och registrering av miljödata, som trådlöst överförs till en central plats för att bearbetas och lagras.

Numera kan trådlösa sensornätverk användas på flera sätt, nedan är bara några exempel:

• Områden med ekologisk övervakning av skogar, floder, sjöar, hav och hav;
• Möjlighet att varna om terroristattacker, kemiska, biologiska, epidemiska attacker;
• Övervakningssystem för barn, äldre, patienter eller personer med särskilda behov;
• Övervakningssystem inom jordbruk och växthus;
• Övervakningssystem för väderprognoser;
• Övervakning av stadstrafik, skolor, parkeringsplatser;

Och många, många andra applikationer.

I den här artikeln vill jag visa resultaten av ett experiment med trådlösa sensornätverk som har använts för övervakning av temperatur- och luftfuktighetsdata, med en långsam och relativt förutsägbar variation. För detta experiment valde jag att använda sensor-avsändare som jag byggde själv med prisvärda moduler. Mottagaren är också DIY, kommunikationen är enkelriktad (på 433 MHz radioband), vilket betyder att sensorerna bara överför data och den centrala platsen bara tar emot. Det finns ingen kommunikation mellan sensorer och från mottagare till sensorer.

Men varför välja att använda flera sändare och bara en mottagare? Uppenbarligen skulle den första anledningen vara att "göra det enkelt". Ju enklare monteringen är, desto mindre sannolikt är det att den misslyckas, och det är definitivt mycket lättare att reparera och byta ut de enskilda komponenterna vid störningar. Strömförbrukningen är också lägre, batterierna kommer att hålla längre (sensorer förbrukar bara under övervakning och mottagning, resten av tiden kommer enheten att vara i djupt viloläge). Det faktum att det är enkelt gör enheten också billig. En annan aspekt att tänka på är täckningsområdet. Varför? Det är mycket lättare att bygga och använda en känslig mottagare än att ha en känslig mottagare och en kraftfull sändare vid både sensorerna och den centrala modulen (detta är nödvändigt för en bra dubbelriktad kommunikation). Med en känslig och högkvalitativ mottagare är det möjligt att ta emot data från en lång sträcka, men att emittera data för samma sträcka kräver hög utsläppskraft och detta kommer med höga kostnader, elförbrukning och (låt oss inte glömma) möjligheten att överskrida laglig maximal sändareffekt på 433 MHz -bandet. Genom att använda en medelkvalitetsmottagare, billig men med en högkvalitativ antenn (även DIY) och billiga sändare med en antenn av god kvalitet, kan vi uppnå utmärkta resultat till en bråkdel av kostnaden för befintliga trådlösa sensornätverk.

Steg 1: Teoretiska överväganden

Tanken på att bygga ett trådlöst sensornätverk för övervakning av temperatur och fuktighet i luft och jord i olika delar av ett växthus kom upp i mitt sinne för länge sedan, nästan 10 år. Jag ville bygga ett 1-tråds nätverk och använda 1-tråds temperatur- och fuktsensorer. Tyvärr var fuktighetssensorer för tio år sedan sällsynta och dyra (även om temperatursensorer var utbredda) och eftersom det inte verkade som att sprida trådar över hela växthuset, gav jag upp tanken ganska snabbt.

Men nu har situationen förändrats radikalt. Vi kan hitta billiga sensorer av god kvalitet (temperatur och luftfuktighet), och vi har också tillgång till billiga sändare och mottagare på 433 MHz-bandet. Det finns bara ett problem: om vi har fler sensorer (låt oss säga 20) hur löser vi kollisionerna (kom ihåg att detta är en enkelriktad kommunikation), vilket betyder överlappning av 2 eller fler sensorer? När jag letade efter en möjlig lösning stötte jag på dessa mycket intressanta artiklar:

Trådlös sensor konvergerar gjutet baserat på procedurer för slumpmässiga funktioner - av RAJBA, T. och RAJBA, S.

och

Sannolikheten för kollisioner i Wireless Sensor Network med slumpmässig sändning - av RAJBA S. och RAJBA. T

I grund och botten visar författarna oss att sannolikheten för kollisioner i ett trådlöst sensornätverk kan beräknas om paketen utsänds vid vissa tidpunkter enligt en giftig (exponentiell) distribution.

Ett utdrag från ovanstående papper listar egenskaperna hos det studerade nätverket.

• ett ganska stort antal sensorsändarenheter N;
• sensor-avsändarenheter förblir helt oberoende och att slå dem på eller av har ingen inverkan på nätverksdriften;
• alla sensor-avsändarenheter (eller en del av dem) kan vara mobila förutsatt att de är placerade inom radioområdet för den mottagande stationen;
• de långsamt förändrade fysiska parametrarna utsätts för mätningar, vilket innebär att det inte är nödvändigt att överföra data mycket ofta (t.ex. var flera minuter eller flera dussintals minuter);
• överföringen är av envägstyp, det vill säga från sensorn-avsändarenheten upp till mottagningspunkten vid T-genomsnittliga tidsintervall. Information överförs i protokollet vid t_sid varaktighet;
• någon vald sensor börjar sända slumpmässigt vid Poisson -tider. PASTA (Poisson Arrivals See Time Averages) kommer att användas för att motivera sändning av sonder vid Poisson -epoker;
• alla sensorsändare förblir slumpmässigt oberoende och de kommer att överföra informationen vid ett slumpmässigt valt ögonblick av t_sid varaktighet och T genomsnittlig upprepningstid;
• om en eller flera sensorer börjar sända medan protokollet för t_sid varaktighet överförs från en annan sensor, en sådan situation kallas kollision. Kollision gör det omöjligt för central basstation att ta emot informationen på ett korrekt sätt.

Det passar nästan perfekt med sensornätverket jag vill testa …

Nästan.

Jag säger inte att jag helt förstod matematiken i tidningen, men på grundval av de presenterade uppgifterna och på slutsatserna har jag kunnat förstå lite vad det handlar om. Det enda är att ett värde som används i tidningen gjorde mig lite orolig:). Det är variabeln t_sid - dataöverföringens längd som antas vara 3,2x10^-5 s. Så överföringstiden för den insamlade informationen skulle vara 3,2 oss! Detta kan inte göras på 433 MHz -bandet. Jag vill använda antingen rcswitch eller radiohead för att programmera sändarsensorerna. När jag studerade koder för de två biblioteken kom jag fram till att den minsta sändningstiden skulle vara 20 ms, långt över värdet 3,2 oss. Med 2,4 GHz -sändarna är det möjligt t_sid tiden är så liten … men det är en annan historia.

Om vi tillämpar den formel som föreslagits av författarna till detta dokument blir resultatet:

Initial data (ett exempel):

• Antal sensorer N = 20;
• Dataöverföringslängd t_sid= 20x10^-3 s (0,020s)
• Genomsnittligt överföringsintervall T = 180s

Formeln:

Sannolikheten för kollision på T -intervall är

om vi tar hänsyn till de initiala uppgifterna är sannolikheten för kollision på T -intervallet 0,043519

Detta värde, som indikerar sannolikheten för att ha 4,35 kollisioner per 100 mätningar, är enligt min mening ganska bra. Sannolikheten kan förbättras om vi ökar den genomsnittliga överföringstiden, så vid ett värde av 300s skulle vi ha en sannolikhet på 0,026332, dvs 2,6 kollisioner per 100 mätningar. Om vi anser att vi ändå kan förvänta oss förlust av paketdata under systemets drift (beroende på till exempel väderförhållanden) så är detta nummer riktigt bra.

Jag ville göra en simulering av denna typ av nätverk men också ett slags designassistent, så jag gjorde ett litet program i C, du kan hitta källkoden på github (även en kompilerad binär som körs i Windows kommandorad - släpp).

Indata:

• sensor_number - antalet sensorer i nätverket;
• mätningar_nummer - antal mätningar som ska simuleras;
• genomsnittlig_överförings_intervall -genomsnittlig tid mellan på varandra följande dataöverföringar;
• transmission_time - den effektiva varaktigheten av dataöverföring.

Produktion:

• den beräknade maximala mättiden;
• listan över kollisioner mellan två sensorer;
• antal kollisioner;
• teoretisk sannolikhet för kollisionerna.

Resultaten är ganska intressanta:)

Nog med teorin, jag skulle inte vilja insistera mer på den teoretiska delen, artiklarna och källkoden är ganska vältaliga, så jag går bättre till den praktiska och effektiva implementeringen av det trådlösa sensornätverket och till testresultaten.

Steg 2: Praktisk implementering - hårdvaran

För sändarsensorer behöver vi följande komponenter:

• ATtiny85 mikrokontroller 1.11 $;
• Integrerat kretsuttag 8DIP 0,046 $;
• Temperatur/fuktighetsgivare DHT11 0,74 $;
• 433MHz H34A -sändarmodul 0.73 $;
• 4xAA batterihållare med omkopplare 1 $;

Totalt 3,63 $;

Mottagaren som används för testerna är en Arduino UNO (endast för testning) och en H3V4F -mottagningsmodul (0,66 $) med en billig bågantenn (0,32 $).

Sensorsändarscheman

Sändar-sensorenheterna drivs med 3xAA, 1,5v batterier (i det fjärde facket i batterihållaren finns den elektroniska enheten). Som du kan se är sändarens strömförsörjning och temperaturfuktighetssensorn ansluten till mikrokontrollerens PB0-stift (sändaren och sensorn drivs när stiftet är inställt på HIGH). Så när mikrokontrollern är i djupt viloläge kan den nå en strömförbrukning på 4,7 uA. Med tanke på att sändarsensorns väckningstid skulle vara cirka 3 sekunder (mätning, överföring etc.) och den genomsnittliga tiden mellan överföringar på 180 sekunder (som exemplet i föregående kapitel), bör batterierna motstå ganska mycket. Med några alkaliska batterier av god kvalitet (dvs. 2000 mAh) kan autonomin vara över 10 månader, beräknat på omnicalculator.com (där den totala strömförbrukningen är: sensor - 1.5mA, sändarmodul - 3.5mA och ATtiny85 mikrokontroller - 5mA, totalt 10mA).

På bilden nedan kan du se den nästan färdiga sensorsändarenheten.

Nedan är fotot av testmottagarenheten.

Steg 3: Praktisk implementering - Programvara

Programvaran som laddas upp till attiny85-mikrokontrollern, huvudkomponenten i sensorsändarenheterna, har till syfte att läsa data från sensorn, konvertera den för att överföras med radio och överföra den inom Poissons tidsramar (exponentiell distribution eller PASTA - Poisson Ankomster Se tidsmedelvärden). Genom att använda en enkel funktion övervakar den också batteriernas status och ger en varning om den nödvändiga spänningen för sensorn inte längre tillhandahålls. Källkoden är tillgänglig på github. Koden för testmottagaren är väldigt enkel, jag lägger upp den nedan.

// modifierat rcswitch-bibliotek från https://github.com/Martin-Laclaustra/rc-switch/tree/protocollessreceiver// koden är en modifierad version från exempel på det ursprungliga rcswitch-biblioteket #include RCSwitch mySwitch = RCSwitch (); osignerad lång data = 0; void setup () {Serial.begin (9600); mySwitch.enableReceive (0); // Mottagare vid avbrott 0 => det är 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 = bitExtraherad (data, 7, 1); // mindre signifikanta 7bits från position 1 - första bitens intaste temperatur längst till höger = bitExtraherad (data, 7, 8); // nästa 7bits från position 8 till höger och så vidare int v_min = bitExtracted (data, 1, 15); int packet_id = bitExtracted (data, 3, 16); // 3bits - 8 paket -ID från 0 till 7 int sensor_id = bitExtracted (data, 6, 19); // 6bit för 64 sensor -ID - totalt 24 bitar Serial.print (sensor_id); Serial.print (","); Serial.print (packet_id); Serial.print (","); Serial.print (temperatur); Serial.print (","); Serial.print (fuktighet); Serial.println (); mySwitch.resetAvailable (); }} // kod från https://www.geeksforgeeks.org/extract-k-bits-given-position-number/ int bitExtracted (unsigned long number, int k, int p) {return (((1 (p- 1)));}

Jag har försökt att inkludera så många kommentarer som möjligt för att göra det lättare att förstå.

För felsökning använde jag softwareserialbiblioteket och attiny85 -utvecklingskortet med USBasp -programmeraren (se även min instruktion om detta). Serielänken har gjorts med Serial to TTL -omvandlare (med ett PL2303 -chip) anslutet till de böjda stiften (3 och 4) på utvecklingskortet (se bild nedan). Allt detta har varit en ovärderlig hjälp för att komplettera koden.

Steg 4: Testresultat

Jag har skapat 5 sensorsändarenheter som samlar in och skickar värden som mäts av DHT11-sensorerna. Jag registrerade och sparade mätningar, med hjälp av testmottagaren och ett terminalemuleringsprogram (foxterm), under tre dagar. Jag valde ett 48 timmars intervall för studier. Jag var inte nödvändigtvis intresserad av mätvärdena (sensor 2, det visar mig till exempel fel värden) utan antalet kollisioner. Dessutom placerades sensorerna mycket nära (vid 4-5 m) av mottagaren för att eliminera andra orsaker till paketförlust. Testresultaten har sparats i en cvs -fil och laddats upp (se filen nedan). Jag laddade också upp en excel -fil baserad på denna csv -fil. Jag tog några skärmdumpar för att visa dig hur en kollision ser ut (i mina tester förstås), jag la också kommentarer till varje skärmdump.

Du kanske undrar varför jag inte använde en datalastartjänst till exempel ThingSpeak. Faktum är att jag har många poster, många sensorer och data som kommer ofta med oregelbundna intervall, och online IoT -tjänster tillåter endast data vid ett visst antal sensorer och bara med ganska stora intervall. Jag tänker i framtiden att installera och konfigurera min egen IoT -server.

I slutändan resulterade 4598 mätningar på 5 sensorsändarenheter (cirka 920/sensor) i totalt 5 kollisioner under en period av 48 timmar (0,5435 kollisioner/100 mätningar). Att göra lite matematik (med hjälp av wsn_test -programmet med initiala data: 5 sensorer, genomsnittstid 180s, sändningstid 110 ms) kollisionssannolikhet skulle vara 0,015185 (1,52 kollisioner/100 mätningar). De praktiska resultaten är ännu bättre än de teoretiska resultaten, eller hur?:)

Hur som helst går det också 18 paket förlorade under denna period, så kollisionerna spelar egentligen inte så stor roll i detta avseende. Naturligtvis bör testet äga rum under en längre tid för att få de mest avgörande resultaten men enligt min mening är det en framgång även under dessa förhållanden och bekräftar fullt ut de teoretiska antagandena.

Steg 5: Slutliga tankar

Omedelbar ansökan

I ett stort växthus odlas flera grödor. Om bevattningen görs manuellt utan klimatövervakning, utan någon automatisering, utan dataregister finns det risk för över- eller underbevattning och dessutom är vattenförbrukningen hög, det finns inga belägg för optimering av vattenförbrukningen, det finns risk för grödor i allmän. För att undvika detta kan vi använda ett trådlöst sensornätverk:)

Temperatursensorer, luftfuktighetssensorer, jordfuktighetssensorer kan placeras runt om i växthuset och med hjälp av överförd data kan flera åtgärder göras: start-stop elektriska ventiler för att låta vattnet flöda där det behövs, start-stop elektriska fläktar för att minska temperaturen i olika områden, start-stop-värmare efter behov och all data kan arkiveras för framtida analyser. Systemet kan också tillhandahålla ett webbgränssnitt som är tillgängligt överallt och e -post- eller SMS -larm vid onormalt tillstånd.

Vad kommer härnäst?

• Testning med ett större antal sensorer;
• Realtidstestning med fjärrsensorer i täckningsområdet;
• Installera och konfigurera en lokal IoT -server (till exempel på en Raspberry Pi);
• Testar också med sändare (transceiver) -sensorer på 2,4 GHz.

så … fortsätter …:)

ANSVARSFRISKRIVNING: Användning av 433MHz frekvensband i din region kan omfattas av radiofrekvensbestämmelser. Kontrollera din laglighet innan du försöker detta projekt

Tvåa i sensortävlingen