Rrjeti i sensorëve pa tela me kosto të ulët në brezin 433MHz: 5 hapa (me fotografi)

2024 Autor: John Day | [email protected]. E modifikuara e fundit: 2024-01-30 12:19

Shumë faleminderit Teresa Rajba që me dashamirësi më dha pranimin e saj për të përdorur të dhënat nga botimet e tyre në këtë artikull

* Në imazhin e mësipërm - pesë njësitë e dërguesve të sensorit që kam përdorur për testim

Cilat janë rrjetet e sensorëve pa tel?

Një përkufizim i thjeshtë do të ishte: rrjetet e sensorëve pa tel i referohen një grupi pajisjesh elektronike të shpërndara në një zonë të caktuar për monitorimin dhe regjistrimin e të dhënave mjedisore, të cilat transmetohen me valë në një vend qendror për tu përpunuar dhe ruajtur.

Në ditët e sotme Rrjetet e Sensorëve Wireless mund të përdoren në disa mënyra, më poshtë janë vetëm disa shembuj:

• Zonat e mbikëqyrjes ekologjike të pyjeve, lumenjve, liqeneve, deteve dhe oqeaneve;
• Mundësia e paralajmërimit në rast të sulmeve terroriste, kimike, biologjike, epidemike;
• Sistemet e monitorimit për fëmijët, të moshuarit, pacientët ose personat me nevoja të veçanta;
• Sistemet e mbikqyrjes në bujqësi dhe serra;
• Sistemi i monitorimit të parashikimit të motit;
• Mbikëqyrja e trafikut të qytetit, shkollave, parkingjeve të makinave;

Dhe shumë, shumë aplikacione të tjera.

Në këtë punim dua të tregoj rezultatet e një eksperimenti me rrjetet e sensorëve pa tela që janë përdorur për monitorimin e të dhënave të temperaturës dhe lagështisë, me një ndryshim të ngadaltë dhe relativisht të parashikueshëm. Për këtë eksperiment unë zgjodha të përdor sensorë-dërgues të cilët i kam ndërtuar vetë duke përdorur module të përballueshme. Marrësi është gjithashtu DIY, komunikimi është njëdrejtimësh (në brezin e radios 433 MHz), që do të thotë se sensorët transmetojnë vetëm të dhënat dhe vendndodhja qendrore merr vetëm. Nuk ka komunikim midis sensorëve dhe nga marrësi tek sensorët.

Por pse të zgjedhësh të përdorësh transmetues të shumtë dhe vetëm një marrës? Shtë e qartë se arsyeja e parë do të ishte "duke e bërë atë të thjeshtë". Sa më i thjeshtë të jetë montimi, aq më pak ka të ngjarë të dështojë, dhe padyshim që është shumë më e lehtë të riparoni dhe zëvendësoni përbërësit e vetëm në rast të keqfunksionimeve. Konsumi i energjisë është gjithashtu më i ulët, bateritë do të zgjasin më shumë (sensorët do të konsumojnë vetëm gjatë monitorimit dhe marrjes, pjesën tjetër të kohës pajisja do të jetë në gjendje gjumi të thellë). Fakti që është i thjeshtë e bën pajisjen gjithashtu të lirë. Një aspekt tjetër që duhet mbajtur parasysh është zona e mbulimit. Pse? Muchshtë shumë më e lehtë të ndërtosh dhe përdorësh një marrës të ndjeshëm sesa të kesh një marrës të ndjeshëm dhe një transmetues të fuqishëm si në sensorë ashtu edhe në modulin qendror (kjo është e nevojshme për një komunikim të mirë dypalësh). Me një marrës të ndjeshëm dhe me cilësi të mirë është e mundur të marrësh të dhëna nga një distancë e gjatë, por lëshimi i të dhënave për të njëjtën distancë kërkon fuqi të lartë të emetimit dhe kjo vjen me kosto të larta, konsum të energjisë elektrike dhe (të mos harrojmë) mundësinë për të kapërcyer fuqia maksimale e transmetuesit ligjor në brezin 433 MHz. Duke përdorur një marrës me cilësi të mesme, të lirë, por me një antenë me cilësi të lartë (madje edhe DIY) dhe transmetues të lirë me një antenë me cilësi të mirë, ne mund të arrijmë rezultate të shkëlqyera me një pjesë të kostos së rrjeteve ekzistuese të sensorëve pa tel.

Hapi 1: Konsiderata teorike

Ideja e ndërtimit të një rrjeti sensor pa tela për monitorimin e temperaturës dhe lagështisë së ajrit dhe tokës në zona të ndryshme të serrës më erdhi në mendje shumë kohë më parë, gati 10 vjet. Doja të ndërtoja një rrjet me 1 tela dhe të përdorja sensorë të temperaturës dhe lagështisë me 1 tela. Fatkeqësisht, 10 vjet më parë sensorët e lagështisë ishin të rrallë dhe të shtrenjtë (megjithëse sensorët e temperaturës ishin të përhapur) dhe meqenëse përhapja e telave në të gjithë serën nuk dukej një opsion, unë hoqa dorë nga ideja shumë shpejt.

Sidoqoftë, tani situata ka ndryshuar rrënjësisht. Ne jemi në gjendje të gjejmë sensorë të lirë dhe me cilësi të mirë (temperatura dhe lagështia), dhe gjithashtu kemi qasje në transmetues dhe marrës të lirë në brezin 433 MHz. Ekziston vetëm një problem: nëse kemi më shumë sensorë (le të themi 20) si i zgjidhim përplasjet (ju lutemi mbani në mend se ky është një komunikim i njëanshëm), që nënkupton mbivendosjen e emetimit të 2 ose më shumë sensorëve? Ndërsa kërkoja një zgjidhje të mundshme, hasa në këto gazeta shumë interesante:

Sensori pa tel konvergon i hedhur bazuar në procedurën e operacioneve të rastësishme - nga RAJBA, T. dhe RAJBA, S.

dhe

Probabiliteti i përplasjeve në Rrjetin e Sensorëve Wireless me dërgimin e rastësishëm - nga RAJBA S. dhe RAJBA. T

Në thelb, autorët na tregojnë se probabiliteti i përplasjeve në një rrjet sensor pa tel mund të llogaritet nëse paketat emetohen në pika të caktuara kohore sipas një shpërndarje poissoniane (eksponenciale).

Një ekstrakt nga punimi i mësipërm rendit karakteristikat e rrjetit të studiuar.

• një numër mjaft i madh i njësive sensor-dërgues N;
• njësitë e dërguesve të sensorëve mbeten plotësisht të pavarur dhe ndezja ose fikja e tyre nuk ka asnjë ndikim në funksionimin e rrjetit;
• të gjitha njësitë e dërguesve të sensorit (ose një pjesë e tyre) mund të jenë të lëvizshme me kusht që të jenë të vendosura brenda rrezes së radios të stacionit të marrjes;
• parametrat fizikë që ndryshojnë ngadalë i nënshtrohen matjeve, që do të thotë se nuk ka nevojë për transmetimin e të dhënave shumë shpesh (p.sh. çdo disa minuta ose disa dhjetëra minuta);
• transmetimi është i njëanshëm, domethënë nga njësia sensor-dërgues deri në pikën e marrjes në intervalet mesatare kohore T. Informacioni transmetohet në protokoll në t_fq kohëzgjatja e kohës;
• çdo sensor i zgjedhur fillon të transmetojë rastësisht në kohën Poisson. PASTA (Arritjet në Poisson Shihni Mesataret e Kohës) do të përdoren për të justifikuar dërgimin e sondave në epokat e Poisson;
• të gjitha njësitë e dërguesve të sensorëve mbeten rastësisht të pavarur dhe ato do të transmetojnë informacionin në një moment të zgjedhur rastësisht nga koha e t_fq kohëzgjatja dhe koha mesatare T e përsëritjes;
• nëse një ose më shumë sensorë fillojnë të transmetojnë ndërsa protokolli i t_fq kohëzgjatja transmetohet nga një sensor tjetër, një situatë e tillë quhet përplasje. Përplasja e bën të pamundur që stacioni bazë qendror të marrë informacionin në mënyrë korrekte.

Përshtatet pothuajse në mënyrë të përkryer me rrjetin e sensorëve që dua të provoj…

Pothuajse.

Nuk po them se e kam kuptuar plotësisht matematikën në punim, por në bazë të të dhënave të paraqitura dhe në përfundimet kam qenë në gjendje të kuptoj pak për çfarë bëhet fjalë. E vetmja gjë është se një vlerë e përdorur në gazetë më shqetësoi pak:). Theshtë ndryshorja t_fq - kohëzgjatja e transmetimit të të dhënave që supozohet të jetë 3.2x10^-5 s Pra, koha e transmetimit të të dhënave të mbledhura do të ishte 3.2 us! Kjo nuk mund të bëhet në brezin 433 MHz. Dua të përdor ose rcswitch ose radiohead për të programuar sensorët e transmetuesit. Duke studiuar kodet e dy bibliotekave, arrita në përfundimin se koha më e vogël e transmetimit do të ishte 20ms, shumë më tepër se vlera prej 3.2 us. Me transmetuesit 2.4 GHz, është e mundur t_fq koha kaq e vogël … por kjo është një histori tjetër.

Nëse zbatojmë formulën e propozuar nga autorët e këtij punimi, rezultati do të jetë:

Të dhënat fillestare (një shembull):

• Numri i sensorëve N = 20;
• Kohëzgjatja e transmetimit të të dhënave t_fq= 20x10^-3 s (0.020s)
• Intervali mesatar i transmetimit T = 180s

Formula:

Probabiliteti i përplasjes në intervalin T është

nëse marrim parasysh të dhënat fillestare probabiliteti i përplasjes në intervalin T do të jetë 0.043519

Kjo vlerë, e cila tregon gjasat për të pasur 4.35 përplasje për 100 matje është, sipas mendimit tim, mjaft e mirë. Probabiliteti mund të përmirësohet nëse rrisim kohën mesatare të transmetimit, kështu që në vlerën 300 do të kishim një probabilitet prej 0.026332, pra 2.6 përplasje për 100 matje. Nëse marrim parasysh se mund të presim humbje të të dhënave të paketave gjithsesi gjatë funksionimit të sistemit (në varësi të kushteve të motit për shembull) atëherë ky numër është vërtet i shkëlqyer.

Doja të bëja një simulim të këtij lloji të rrjetit, por edhe një lloj asistenti të projektimit, kështu që bëra një program të vogël në C, ju mund të gjeni kodin burimor në github (gjithashtu një binar i përpiluar që po funksionon në vijën komanduese të Windows - lirimin).

Fut te dhenat:

• sensor_number - numri i sensorëve në rrjet;
• matjet_numer - numri i matjeve për tu simuluar;
• mesatare_transmetimi_interval -koha mesatare midis transmetimeve të njëpasnjëshme të të dhënave;
• koha e transmetimit - kohëzgjatja efektive e transmetimit të të dhënave.

Prodhimi:

• koha maksimale e llogaritur e matjes;
• lista e përplasjeve midis dy sensorëve;
• numri i përplasjeve;
• probabiliteti teorik i përplasjeve.

Rezultatet janë mjaft interesante:)

Mjaft me teorinë, nuk do të doja të këmbëngulja më shumë në pjesën teorike, artikujt dhe kodi burimor janë mjaft elokuentë, kështu që më mirë të shkoj në zbatimin praktik, efektiv të rrjetit të sensorëve pa tel dhe në rezultatet e testit.

Hapi 2: Zbatimi Praktik - Hardueri

Për sensorët e transmetuesit do të na duhen përbërësit e mëposhtëm:

• Mikrokontrolluesi ATtiny85 1.11 $;
• Fole e qarkut të integruar 8DIP 0.046 $;
• Sensori i temperaturës/lagështisë DHT11 0,74 $;
• Moduli i transmetuesit 433MHz H34A 0.73 $;
• Mbajtës i baterisë 4xAA me ndërprerës 1 $;

Gjithsej 3.63 $;

Marrësi i përdorur për testet është një Arduino UNO (vetëm për testim) dhe një modul marrës H3V4F (0.66 $) me një antenë hark të lirë (0.32 $).

Skemat sensore-dërguese

Njësitë e transmetuesit-sensorë mundësohen me bateri 3xAA, 1.5v (në ndarjen e katërt të mbajtësit të baterisë ekziston montimi elektronik). Siç mund ta shihni, furnizimi me energji i transmetuesit dhe sensori i lagështisë së temperaturës është i lidhur me kunjin PB0 të mikrokontrolluesit (transmetuesi dhe sensori mundësohen kur kunja është vendosur në LART). Pra, kur mikrokontrolluesi është në gjendje gjumi të thellë, mund të arrijë një konsum aktual prej 4.7uA. Duke marrë parasysh që koha e zgjimit të sensorit të transmetuesit do të ishte rreth 3 sekonda (matja, transmetimi etj.) Dhe koha mesatare midis transmetimeve prej 180 sekondash (siç është shembulli në kapitullin e mëparshëm), bateritë duhet të rezistojnë mjaft. Me disa bateri alkaline me cilësi të mirë (p.sh. 2000 mAh), autonomia mund të jetë mbi 10 muaj siç llogaritet në omnicalculator.com (ku konsumi i përgjithshëm aktual është: sensor - 1.5mA, modul transmetues - 3.5mA dhe mikrokontrollues ATtiny85 - 5mA, gjithsej 10mA)

Në foton më poshtë mund të shihni montimin pothuajse të përfunduar të sensorit-dërguesit.

Më poshtë është fotografia e njësisë së marrësit të provës.

Hapi 3: Zbatimi Praktik - Softuer

Softueri i ngarkuar duke funksionuar në mikrokontrolluesin attiny85, përbërësi kryesor i njësive të dërguesit të sensorit, ka për qëllim të lexojë të dhënat e dhëna nga sensori, t'i shndërrojë ato për t'u transmetuar me radio dhe t'i transmetojë ato brenda kornizave kohore Poisson (shpërndarje eksponenciale ose PASTA - Arritjet në Poisson Shihni Mesataret e Kohës). Gjithashtu, duke përdorur një funksion të thjeshtë, ai monitoron statusin e baterive dhe jep një paralajmërim nëse tensioni i kërkuar për sensorin nuk sigurohet më. Kodi burim është i disponueshëm në github. Kodi për marrësin e testit është shumë i thjeshtë po e postoj më poshtë.

// biblioteka e modifikuar rcswitch nga https://github.com/Martin-Laclaustra/rc-switch/tree/protocollessreceiver// kodi është një version i modifikuar nga shembujt e bibliotekës rcswitch origjinale #include RCSwitch mySwitch = RCSwitch (); të dhëna të gjata të panënshkruara = 0; void setup () {Serial.begin (9600); mySwitch.enableReceive (0); // Marrësi në ndërprerjen 0 => që është kunja #2} void loop () {if (mySwitch.available ()) {të dhëna të gjata të panënshkruara = mySwitch.getReceivedValue (); // output (mySwitch.getReceivedValue (), mySwitch.getReceivedBitlength (), mySwitch.getReceivedDelay (), mySwitch.getReceivedRawdata (), mySwitch.getReceivedProtocol ()); lagështia int = bitExracted (të dhëna, 7, 1); // më pak domethënëse 7bit nga pozicioni 1 - biti i parë më i djathtë int temperatura = bitExracted (të dhëna, 7, 8); // 7bit tjetër nga pozicioni 8 në të djathtë dhe kështu me radhë int v_min = bitExracted (të dhënat, 1, 15); int packet_id = bitExtracted (të dhëna, 3, 16); // 3bits - 8 pako id nga 0 në 7 int sensor_id = bitExracted (të dhëna, 6, 19); // 6bit për 64 ID të sensorit - gjithsej 24 bit Serial.print (sensor_id); Serial.print (","); Serial.print (packet_id); Serial.print (","); Serial.print (temperatura); Serial.print (","); Serial.print (lagështia); Serial.println (); mySwitch.resetAvailable (); }} // kodi nga https://www.geeksforgeeks.org/extract-k-bits-given-position-number/ int bitI nxjerrë (numër i gjatë i panënshkruar, int k, int p) {return (((1 (p- 1)));}

Unë jam përpjekur të përfshij sa më shumë komente të jetë e mundur për ta bërë më të lehtë për t’u kuptuar.

Për korrigjimin e gabimeve kam përdorur bibliotekën softwareserial dhe bordin e zhvillimit attiny85 me programuesin USBasp (shih gjithashtu udhëzuesin tim për këtë). Lidhja serike është bërë me konvertuesin Serial në TTL (me një çip PL2303) të lidhur me kunjat e përkulur (3 dhe 4) të bordit të zhvillimit (shiko foton më poshtë). E gjithë kjo ka qenë një ndihmë e paçmuar për të plotësuar kodin.

Hapi 4: Rezultatet e testit

Unë kam krijuar 5 njësi dërgues-sensorë që mbledhin dhe dërgojnë vlera të matura nga sensorët DHT11. Kam regjistruar dhe ruajtur matjet, me ndihmën e marrësit të testit dhe një programi të emulimit terminal (foxterm), gjatë tre ditëve. Zgjodha një interval 48 orësh për studim. Unë nuk isha domosdoshmërisht i interesuar për vlerat e matura (sensori 2, për shembull, më tregon vlera të gabuara), por për numrin e përplasjeve. Për më tepër, sensorët u vendosën shumë afër (në 4-5 m) nga marrësi për të eleminuar shkaqet e tjera të humbjes së paketave. Rezultatet e testit janë ruajtur në një skedar cvs dhe janë ngarkuar (shikoni skedarin më poshtë). Unë gjithashtu ngarkova një skedar excel bazuar në këtë skedar csv. Mora disa pamje të ekranit për t'ju treguar se si duket një përplasje (në testet e mia natyrisht), shtova komente si dhe në çdo pamje të ekranit.

Ju mund të pyesni veten pse nuk kam përdorur një shërbim të ngarkuesit të të dhënave për shembull ThingSpeak. Fakti është se kam shumë regjistrime, shumë sensorë dhe të dhëna që vijnë shpesh në intervale të parregullta, dhe shërbimet online IoT lejojnë të dhëna vetëm në një numër të caktuar sensorësh dhe vetëm në intervale mjaft të mëdha. Po mendoj në të ardhmen të instaloj dhe konfiguroj serverin tim IoT.

Në fund, 4598 matje në 5 njësi dërgues-sensor (afërsisht 920/sensor) rezultuan në një total prej 5 përplasjesh për një periudhë prej 48 orësh (0.5435 përplasje/100 matje). Bërja e ndonjë matematike (duke përdorur programin wsn_test me të dhënat fillestare: 5 sensorë, koha mesatare 180s, koha e transmetimit 110 ms) probabiliteti i përplasjes do të ishte 0.015185 (1.52 përplasje/100 matje). Rezultatet praktike janë edhe më të mira sesa rezultatet teorike, apo jo?:)

Gjithsesi ka edhe 18 pako të humbura në këtë periudhë, kështu që përplasjet nuk kanë shumë rëndësi në këtë drejtim. Sigurisht që testi duhet të zhvillohet për një periudhë më të gjatë kohore për të marrë rezultatet më përfundimtare, por sipas mendimit tim është një sukses edhe në këto kushte dhe konfirmon plotësisht supozimet teorike.

Hapi 5: Mendimet përfundimtare

Aplikimi i menjëhershëm

Në një serë të madhe rriten disa të lashta. Nëse ujitja bëhet manualisht pa monitorim të klimës, pa asnjë automatizim, pa regjistrime të të dhënave ekziston rreziku i ujitjes nën ose nën ujë dhe gjithashtu konsumi i ujit është i lartë, nuk ka dëshmi për optimizimin e konsumit të ujit, ka rrezik për të lashtat në të përgjithshme. Për të shmangur këtë, ne mund të përdorim një rrjet sensor pa tel:)

Sensorë të temperaturës, sensorë të lagështisë së ajrit, sensorë të lagështisë së tokës mund të vendosen përreth në serrë dhe me ndihmën e të dhënave të transmetuara mund të bëhen disa veprime: valvulat elektrike start-stop për të lënë ujin të rrjedhë aty ku është e nevojshme, start-stop tifozët elektrikë për të ulur temperaturën në zona të ndryshme, ndizni ngrohësit sipas nevojës dhe të gjitha të dhënat mund të arkivohen për analiza të ardhshme. Gjithashtu, sistemi mund të sigurojë një ndërfaqe në internet që është e arritshme kudo dhe alarmet me email ose SMS në rast të gjendjes jonormale.

Ç'pritet më tej?

• Testimi me një numër më të madh të sensorëve;
• Testimi në kohë reale me sensorë të largët në zonën e mbulimit;
• Instalimi dhe konfigurimi i një serveri lokal IoT (në Raspberry Pi për shembull);
• Testet gjithashtu me transmetues (marrës marrës)-sensorë në 2.4Ghz.

kështu … për të vazhduar …:)

Mospranimi: Përdorimi i brezit të frekuencës 433MHz në rajonin tuaj mund t'i nënshtrohet rregulloreve të frekuencës së radios. Ju lutemi kontrolloni ligjshmërinë tuaj para se të provoni këtë projekt

Vrapues në Konkursin e Sensorëve