În cadrul lucrării prezentate mi-am propus explorarea proprietăților protocoalelor de comunicații wireless, folosite pentru distanțe mici și medii,… [303567]

Capitolul 1. [anonimizat], [anonimizat], în raport cu alte protocoale asemănătoare folosite în prezent într-o măsură mai mare.

Necesitatea protocoalelor wireless a [anonimizat] o suprafață relativ mică. [anonimizat], [anonimizat] o [anonimizat]: [anonimizat], putând să apară confuzii între cablurile ce trebuie conectate la un anumit pin/interfață/port la un anumit moment de timp. [anonimizat] s-a [anonimizat], datorită necesității rezolvării problemelor de mai sus.

[anonimizat]. Acesta a crescut destul de mult în ultima vreme întrucât s-a căutat optimizarea parametrilor de folosire a mediului wireless: [anonimizat], dimensiunea pachetelor transmise etc. [anonimizat], soluțiile wireless urmăresc să reprezinte o [anonimizat] a crea inconveniente utilizatorului.

În partea practică a [anonimizat]:

Capitolul 2. Rețelele wireless de noduri ([anonimizat])

2.1 [anonimizat] s-a [anonimizat], crescându-se treptat spre rețele de dimensiuni mai ridicate. Totuși, tendința este aceea de a [anonimizat] a [anonimizat]. [anonimizat]-un număr foarte mare de specializări: medicină, [anonimizat], militar etc. Prin conectarea într-o rețea a [anonimizat], care ar fi mai greu de monitorizat în moduri convenționale.

Figura 2-0-1

[anonimizat], [anonimizat], având același scop.

Referindu-[anonimizat]. Pentru a se îndeplini toate cerințele, de-a lungul timpului au fost propuse mai multe modele de rețele, în jurul cărora au fost construite mai multe modele de protocoale și stive de protocoale. Deși există numeroase moduri în care se poate realiza clasificarea rețelelor de senzori, în continuare scoatem în evidență doar câteva caracteristici ce au un impact major în designul unui protocol.

Punctele de colectare a datelor (data sink(s)) – în cadrul rețelelor wireless de senzori, avem două tipuri de terminale majore: sursele ce generează date și punctele de colectare, unde datele generate sunt necesare în vederea prelucrării sau trimiterii către sistemele care realizează prelucrarea. În funcție de locația acestor puncte, și intervalul în care acestea au nevoie de date pentru a putea realiza prelucrarea, protocolul trebuie să fie capabil să se adapteze cerințelor.

Mobilitatea nodurilor – În cazul cel mai general, nodurile sunt presupuse ca fiind imobile. Totuși, după cum vom prezenta și în cadrul părții practice a lucrării, există situații în care trebuie luată în considerare mișcarea senzorilor pentru a satisface nevoile utilizatorilor: exemplul cel mai relevant stă în domeniul roboticii, unde un robot trebuie să fie capabil să ia decizii pe baza senzorilor atașați sau domeniul militar. Mobilitatea influențează într-un mod major protocoalele și serviciile de localizare.

Resursele nodurilor – În funcție de necesitățile de procesare a fiecărui senzor în parte (aici trebuie luate în considerare mărimile măsurate de către aceștia), memoria internă și frecvența de procesare trebuie adaptate corespunzător. Protocoalele pentru rețelele wireless de senzori trebuie să ia în considerare și aceste detalii în momentul în care sunt proiectate.

Modele de generare a traficului – În majoritatea aplicațiilor, senzorii sunt în cea mai mare parte a timpului într-un mod de ”așteptare”, generând trafic doar atunci când au loc evenimente de interes. În felul acesta se urmărește o eficientizare a consumului de energie. Există totuși și domenii în care este nevoie de monitorizare și generare continuă de date, cum ar fi supravegherea mediului înconjurător. Evident, între aceste două cazuri nu vor putea fi folosite aceleași protocoale.

După cum se poate observa în cele de mai sus, există un număr mare de criterii ce trebuie luate în considerare în momentul în care este conturat și proiectat un protocol de comunicație.

În continuare ne propunem să prezentăm câteva dintre caracteristicile acestui tip de rețele care oferă avantaje respectiv dezavantaje față de sistemele deja existente în infrastructură.

2.2 Caracteristicile principale ale rețelelor de noduri wireless

Precizăm încă de la început că rețelele de senzori au niște caracteristici comune ce sunt împrumutate de la rețelele ad hoc. Totuși, există numeroase diferențe între acestea, cele prezentate în cadrul lucrării fiind mai avansate și având multe funcționalități de care rețelele ad hoc nu dispun.

Totuși, în cadrul proiectării unui protocol pentru rețele de senzori trebuie luate în considerare câteva dintre proprietățile ”moștenite” de la rețelele ad hoc. Printre acestea se numără:

Constrângerile legate de timpul de viață a unui nod, date de către modul de alimentare. În cadrul lucrării prezente ne-am propus alimentarea unor noduri cu ajutorul energiei solare, oferind în felul acesta un timp de viață mai ridicat și o mobilitate crescută.

Probleme în cadrul procesului de comunicație generate de către mediul prin care se face transmisia wireless.

Abilitatea de auto-configurare, fără a fi necesar un grad de intervenție ridicat din partea administratorilor, odată ce sistemul este configurat și funcțional.

Figura 2-0-2

După cum observăm, aceste caracteristici conțin atât avantaje cât și dezavantaje, lăsând deschise opțiuni de dezvoltare în combaterea dezavantajelor. În cadrul rețelelor de senzori prezentate în cadrul acestei lucrări, au fost adăugate o serie de caracteristici, la care s-a ajuns plecând de la diverse probleme întâmpinate în implementarea rețelelor ad hoc.

Din punct de vedere al performanțelor, rețele ad hoc, în forma lor brută nu pot conecta în mod eficient mai mult de 30-40 de senzori, întrucât procesul de comunicație nu este optimizat pentru un număr atât de mare. În WSN-uri, acest lucru este rezolvat de așa natură încât să permită conectarea unui număr de noduri care să ajungă la ordinul miilor.

Senzorii în general sunt imobili într-un mediu în care se face monitorizarea diverșilor parametri. Totuși, în cadrul protocoalelor dezvoltate pentru WSN-uri, s-a luat în considerare și posibilitatea deplasării nodurilor, întrucât există domenii în care acest lucru este necesar.

Introducerea informațiilor de localizare spațială a nodurilor, relativ la spațiul supravegheat.

Rețelele de senzori au de cele mai multe ori un model de trafic de tip many-to-one, lucru care poate conduce către probleme de aglomerare a datelor și dificultate în prelucrarea acestora de către nodurile centrale. In WSN-uri aceste probleme se rezolvă prin implementarea mai multor puncte capabile de prelucrare a datelor și cu ajutorul protocoalelor, ce au rolul de a transmite datele către nodul cel mai liber, pentru a nu cauza blocaje.

Dimensiunile pachetelor de date transmise sunt destul de mici, pentru a simplifica procesul de switching între noduri

În procesul de incorporare a tuturor acestor caracteristici și a multor altele în designul unui protocol, trebuie ținut minte faptul că resursele fizice ale fiecărui nod sunt limitate și trebuie folosite în mod cât mai eficient. În același timp, protocoalele trebuie să fie foarte simple, pentru a executa operațiile într-un timp cât mai scăzut. Toate aceste reglementări au condus către un număr foarte mare de protocoale dezvoltate pentru a lucra între nivelele acces la rețea și transport, fiecare dintre ele având ca și obiectiv principal proiectarea unei rețele de sine stătătoare, care să opereze un timp cât mai îndelungat fără să fie necesară intervenția unui administrator, păstrând un număr cât mai mare de canale de comunicație și o calitate a serviciilor livrată cât mai ridicată.

2.3 Despre senzori și utilitatea acestora

Deși în cadrul lucrării ne propunem să efectuăm mai multe scenarii funcționale în care se va folosi un protocol wireless de comunicație, ne dorim să demonstrăm de asemenea și utilitatea acestui protocol în rețelele de senzori wireless pentru lucrări viitoare. În continuare vom prezenta câteva caracteristici și proprietăți ale senzorilor și traductorilor, accentuând diferențele dintre acestea în cadrul unui mediu tehnic.

De-a lungul istoriei ne-a fost dovedit în repetate rânduri că progresele făcute atât în știință cât și în inginerie au reprezentat factori majori în dezvoltarea tehnologiei senzorilor. Un prim exemplu din punct de vedere istoric poate să fie reprezentat de sensibilitatea termică a unei rezistențe, observată la începutul anilor 1800 de către Wilhelm von Siemens și implementată ulterior în dezvoltarea unui senzor de temperatură, bazat pe un rezistor de cupru. Stabilitatea cristalelor de cuarț, precum și proprietățile lor piezoelectrice au jucat un rol foarte important în dezvoltarea senzorilor ce sunt folosiți în zilele noastre în aproape orice aplicație, inclusiv în domeniul militar.

Raportându-ne la trecutul mai apropiat, o noua eră în tehnologiile senzorilor a fost declanșată de către posibilitatea explorării proprietăților siliconului în vederea creării unor noi metode de a transforma fenomene fizice în unele electrice, pentru a putea fi citite și procesate de către un calculator. Cercetările ce se realizează în prezent ne vor oferi un control mai bun asupra proprietăților materialelor și a modului în care acestea se comportă, oferindu-ne astfel perspectiva unor noi generații de senzori, mai eficienți și cu un preț de producție redus.

În ciuda faptului ca există, la momentul actual, o cantitate semnificativă de materiale scrise pentru a descrie senzorii și traductorii, se păstrează în continuare o ambiguitate destul de mare în folosirea unei singure definiții pentru aceștia. Motivul este unul destul de simplu: acest domeniu revoluționar, care este într-o continuă dezvoltare este unul interdisciplinar, presupunând cunoștințe din mai multe domenii. De aici deducem că nu ar trebui să ne surprindă inexistența unei definiții acceptate în unanimitate legate de conceptul unui senzor.

Pentru a putea prezenta importanța senzorilor este suficient să ne îndreptăm atenția către dispozitivele electronice pe care le folosim în viața de zi cu zi, atât în mediul de acasă cât și în cel în care ne desfășurăm activitatea profesională, indiferent de domeniu. Atât ei cât și traductorii sunt prezenți peste tot, chiar dacă uneori suntem conștienți de acest lucru întotdeauna, simplificându-ne viața prin eficientizarea activităților întreprinse, de la cele mai semnificative până la cele minore, cărora nu le dăm suficient de multă atenție. Lucrarea de față își propune prezentarea conceptelor generale a acestor senzori și traductori, împreună cu noile tehnologii care înglobează folosirea senzorilor, precum Internet of Things.

Un senzor, în termeni cât mai generali, reprezintă o componentă hardware menită să măsoare o cantitate fizică, pe baza căreia emite o un semnal ce poate fi citit și interpretat de către un observator sau un instrument specializat. Unul dintre cele mai simple de înțeles exemple este reprezentat de către termocuplu, care măsoară temperatura la care este expus, iar pe baza unei referințe, emite o tensiune, ce poate fi citită cu ajutorul unui voltmetru. Din punct de vedere al preciziei, toți senzorii sunt calibrați cu ajutorul unor standarde bine cunoscute și definite.

Traductorul reprezintă un dispozitiv ce este alimentat cu energie de către un sistem, în timp ce la rândul său alimentează un al doilea sistem, dar cu energie prezentată sub altă formă. Exemplul cel mai banal este reprezentat de către un difuzor(Figura 1) care transformă semnalele electrice în energie sonoră. Ne putem referi însă și la termocuplul specificat mai sus, capabil să transforme căldura în energie electrică.

În anumite contexte, termenii de senzor și traductori sunt folosiți ca și sinonime, dar acest lucru depinde mult de aplicația în care întâlnim noțiunile.

Senzorii analogi produc un semnal continuu(sau o tensiune), care în general este proporțional cu cantitatea de informație măsurată. Măsurile fizice precum: temperatura, viteza, presiunea etc. reprezintă toate cantități analogice, întrucât sunt de cele mai multe ori continue. Legându-ne la exemplul de mai devreme, temperatura unui lichid poate să fie măsurată cu ajutorul unui termometru sau a unui termocuplu, care răspunde în mod continuu la schimbările de temperatură, pe măsură ce acesta este încălzit sau răcit.

Traductorii ce se află la ieșirea unui sistem sunt denumiți în mod uzual acuatori(dispozitive de acționare) și convertesc energia electrică într-un alt tip de energie, cum ar fi căldură sau energie mecanică.

Figura 2-0-3

Senzorii digitali au un semnal discret la ieșire, sau o tensiune ce reprezintă cantitatea ce este măsurată. Acest semnal de ieșire poate să fie reprezentat sub forma unui singur bit sau a unei secvențe de biți. Un astfel de senzor este reprezentat, ca și caz general, de către un micro senzor ce are integrat un convertor analog-digital pe o singura pastilă de silicon, pentru a forma o componenta micro-electro-mecanică, ce poate procesa informație sau poate comunica cu un procesor integrat. Aceste caracteristici au dat naștere senzorilor inteligenți din zilele noastre, întâlniți sub denumirea de smart-sensors.

2.4. Protocoale wireless folosite pentru conectarea nodurilor

La momentul actual, există un număr relativ mare de protocoale wireless ce pot fi folosite pentru diverse aplicații. În continuare ne propunem să prezentăm o parte dintre aceste protocoale, cele mai folosite și utile din cele existente, făcând o comparație cu protocolul principal al lucrării prezentate – ZigBee.

Protocoalele pe care le vom analiza în continuare în vederea comparației sunt: ZigBee (IEEE 802.15.4), Bluetooth (IEEE 802.15.1), Ultra-Wide-Band (IEEE 802.15.3) și Wi-Fi (IEEE 802.11). Toate cele patru protocoale au un design general pentru rețele wireless de dimensiuni mici, în care toate dispozitivele sunt conectate pe o distanță maximă de câțiva metri – până la câteva zeci. De asemenea, în cadrul proiectării celor patru protocoale, s-a urmărit un consum cât mai mic de energie, pentru a putea oferi dispozitivelor ce folosesc aceste protocoale, o durată de viață a bateriei cat mai mare (sau a unui ciclu de baterie.) Din punct de vedere obiectiv, aplicațiile țintă ale protocoalelor sunt următoarele:

Bluetooth – tastaturi, mouse fără fir, căști hands-free etc.

UWB – legături multimedia ce necesită lățime mare de bandă

ZigBee – orientat pe conexiune, cu un design special pentru rețelele de monitorizare și control a unui număr mare de dispozitive.

Wi-Fi – conexiunile de tip PC – PC, cu ajutorul unui intermediar (de cele mai multe ori un wireless access point (AP)) – vine ca un substituent al rețelelor clasice, ce folosesc cabluri de cupru (coaxiale, torsadate) sau fibre optice.

În continuare, aceste protocoale vor fi comparate din punct de vedere al standardelor, evaluând atât metricile de funcționare, timpul de transmisiune, eficiența codării, complexitatea și consumul mediu de putere. Vor fi scoase în evidență avantajele fiecărui protocol în parte, dar vom pune accent pe utilitatea lor în rețelele de senzori, precum cele utilizate în cadrul acestei lucrări.

2.4.1 Bluetooth și Bluetooth Low Energy (BLE)

Bluetooth-ul tradițional nu poate fi comparat cu ZigBee sau alte servicii din suita celor prezentate mai sus, întrucât are un defect major, care l-ar descalifica din start din folosirea sa în rețelele wireless de senzori și anume – consumul ridicat de energie. În cazul în care am avea o aplicație practică care ar avea nevoie de alimentare pe bază de baterie, pe o perioadă mai îndelungată de timp, protocolul Bluetooth tradițional (802.15.1) nu ar putea sa fie folosit. Acesta consumă în jur de 1W, valoare care pentru aplicațiile Internet of Things este foarte mare. Bluetooth Low Energy are un consum de aproximativ 10 – 100 ori mai mic, încadrându-se între 10 – 100 mW.

Majoritatea caracteristicilor protocolului BLE au fost împrumutate de la Bluetooth, deci se poate discuta în paralel despre acestea, scoțând în evidență doar diferențele majore de interes.

BLE este folosit pentru rețelele personale (PAN), se bazează pe conexiunile wireless pentru scurte distanțe, având un cost scăzut de implementare. În principiu, acest protocol, împreună cu tradiționalul Bluetooth au fost concepute pentru a scădea numărul de cabluri necesare conectării perifericelor la un calculator personal (tastatură, mouse, boxe, cameră web, imprimantă, scanner etc.)

Figura 2-0-4

Există două topologii ce sunt folosite în mod special pentru Bluetooth – piconet și scatternet. Piconet are o structură generală ce permite conectarea unui master și a mai multor periferice secundare (slave). Toate perifericele din cadrul acestei topologii se sincronizează între ele cu ajutorul unui clock – rate setat de către master. Pentru a nu exista interferențe, în momentul inițializării conexiunii, masterul este responsabil cu scanarea mediului înconjurător și stabilirea frecvenței de funcționare, astfel încât să nu apară interferențe cu alte conexiuni. Perifericele sunt responsabile de comunicare punct – la – punct doar cu masterul, nu și între ele. Masterul, pe de altă parte, poate avea conexiuni punct – la – punct sau punct – la – multipunct. Pentru economisirea de energie, un periferic (slave), poate intra în mod de stand-by în momentul în care nu are date de transmis.

Scatternet reprezintă o colecție de piconet ce se suprapun în domeniul frecvenței și din punct de vedere spațial. Un dispozitiv ce folosește Bluetooth se poate conecta în mod simultan la mai multe piconet-uri, permițând în felul acesta un flux de date între acestea, devenind astfel, un scatternet.

BLE are avantajul major de a fi suportat de foarte multe sisteme de operare ce se folosesc în prezent pe dispozitivele mobile: Android, iOS, Windows 8/10 sau OS X. Nu multe alte protocoale se bucură de această incorporare, având nevoie de dispozitive suplimentare pentru comunicare activă.

2.4.2 Ultra-Wide-Band (UWB)

Unul dinte protocoale care s-a bucurat de o majoră creștere a popularității în ultima vreme este UWB. Una dintre caracteristicile căreia i se datorează această popularitate este lățimea de bandă posibilă în cadrul transmisiunii de date – aceasta poate să ajungă până la 480 Mbps, fiind mai mult decât suficientă pentru o multitudine de aplicații ce au nevoie de transmisie de date pe rază scurtă, mai ales într-un mediu închis, casnic.

În lipsa interferențelor majore, acesta poate să fie folosit și pe post de înlocuitor al clasicului serial USB 2.0.

Pe lângă acest avantaj se mai adaugă consumul relativ de putere, existând posibilitatea alimentării dispozitivelor cu ajutorul unei baterii, pe o perioadă mai lungă de timp; rezolvarea problemelor de comunicație în cazul apariției mai multor căi de transmisie a datelor și posibilitatea localizării precise a unui nod emițător de date.

Totuși, există și un dezavantaj în prezent, la această tehnologie, întrucât durează destul de mult de timp pentru a alege un canal de transmisie. Pe scurt, timpul în care un emițător și un destinatar ajung la sincronizare, este de ordinul milisecundelor. De aceea, este important ca tehnologia de acces la mediul de transmisie (MAC – Medium Access Control) să aibă în vedere acest lucru. Există două protocoale care se ocupă de acest acces – CSMA/CA (Carrier Sense Multiple Access / Collision Avoidance) și TDM (Time Division Multiplexing).

2.4.3 Wireless Fidelity (Wi – Fi)

În momentul în care se discută despre protocolul Wi-Fi, sunt incluse automat standardele 802.11a/b/g/n/ac/ad, folosite pentru conexiunea într-o rețea locală. Acestea permit conectarea utilizatorului la Internet, când este în apropierea unui access point (AP). Arhitectura generală a protocolului are la bază o celulă ce se numește basic service set (BSS), ce constă într-un set de stații mobile și fixe. Dacă una dintre stații iese din aria de acoperire a BSS-ului la care era conectată, aceasta nu va mai avea conexiune și nu va mai putea comunica direct cu vecinii săi. Mai departe, protocolul IEEE 802.11 a evoluat cu independent basic service set (IBSS) și extended service set (ESS).

Există și posibilitatea interconectării mai multor BSS-uri, cu ajutorul unui sistem distribuit, conducând în felul acesta la apariția unui ESS, cu dimensiuni și complexitate ce pot fi stabilite de către administratorul de rețea.

Figura 2-0-5

Avantajele acestor protocoale sunt viteza foarte mare de transmisie (ultimele versiuni permit traficul de date la o viteza de 1.3 Gbps) și o rezistență ridicată la interferențe cauzate de mediul de transmisiune. Totuși, în cadrul rețelelor wireless de senzori, precum cele ce urmează să fie prezentate, nu viteza este elementul principal ce trebuie urmărit.

Un dezavantaj major este necesitatea echipamentelor intermediare, a căror preț poate crește exponențial în momentul în care se discută conectarea mai multor noduri (peste 10-20). Deși se pot conecta mai multe noduri și la echipamentele ieftine, componentele interne ale acestora (procesor, memorie RAM, ROM), nu fac față volumului de trafic.

2.4.4 ZigBee

ZigBee, așa cum este descris în cadrul standardului IEEE 802.15.4, este un protocol de transmisie de date cu o rată mică de transmisie pentru WPAN (Wireless Personal Area Network). Acesta a fost conceput pentru o conexiune simplă între dispozitive, păstrând consumul de energie la un minim.

Rețeaua cu ZigBee se auto-organizează, fiind necesar un minim de intervenție al utilizatorului sau al administratorului, în momentul configurării inițiale. Intervențiile ulterioare sunt necesare doar în situații cu probleme majore, în care se defectează un număr foarte mare de noduri sau în cazul în care sunt șterse și resetate configurațiile ce rulează. Rețelele organizate de către ZigBee pot fi atât de tip multi-hop, stea (star), cât și de tip mesh (plasă).

Figura 2-0-6

În cadrul unei rețele ZigBee, dispozitivele au două moduri în care pot funcționa: dispozitiv complet funcțional (DCF / FFD – Full Device Device) sau dispozitiv cu funcționare redusă (DFR / RFD – Reduced Function Device). Dispozitivele DCF pot îndeplini trei roluri în cadrul unei rețele: coordonator al PAN, coordonator sau periferic. Un dispozitiv DCF poate comunica în activ cu alte DCF-uri sau cu alte DFR-uri, în timp ce un dispozitiv DFR poate comunica doar cu alte dispozitive DFR.

Nodurile ce îndeplinesc rolul de dispozitiv cu funcționare redusă au scopuri mai puțin importante în cadrul unei rețele – de cele mai multe ori, au un rol pasiv (întrerupător, senzor pasiv cu infraroșu). Nu au necesitatea de a transmite cantități mari de date și pot comunica cu un singur DCF într-un moment de timp, dar pot face trecerea de la unul la altul.

După ce un nod complet funcțional a fost activat pentru prima oară, este capabil să își formeze propria rețea și să devină coordonator de PAN, formând o rețea stea. Mai multe rețele de tip stea pot opera independent unele de celelalte, separându-se cu ajutorul unui identificator al rețelei, unic în spațiul radio de operare. Odată ce a fost ales un identificator pentru PAN, coordonatorul poate permite conectarea altor noduri în cadrul rețelei.

Datorită avantajelor protocolului (interferențe reduse), posibilitatea criptării datelor, posibilitatea conectării unui număr foarte mare de noduri în cadrul unei singure rețele (> 65000), ZigBee se pretează foarte bine unor aplicații din domeniul Internet of Things, dar și altora mai complexe. Câteva exemple sunt: automatizarea proceselor casnice și de la locul de muncă (pornirea cafetierei, mașinii de spălat, a frigiderului etc.), monitorizare medicală (EEG, EKG), monitorizare a securității și monitorizare seismologică. În cadrul tuturor acestor aplicații, nodurile compatibile ZigBee pot fi alimentate cu baterie, consumul de energie asociat protocolului fiind foarte redus.

Mai multe detalii despre acest protocol urmează să oferim în următoarele capitole.

În cadrul următorului tabel prezentăm caracteristicile generale ale protocoalelor prezentate, dar și a lui ZigBee, care urmează să fie detaliat în continuare.

2.4.5 Concluzii

Fiecare protocol în parte se prezintă cu caracteristici și avantaje ce îl recomandă pentru folosirea în diverse aplicații, dar în același timp, și cu dezavantaje pentru aplicațiile propuse în cadrul lucrării prezentate sau în cadrul proiectelor viitoare de același tip.

După cum am ilustrat în cadrul prezentării de mai sus, ne vom axa asupra protocolului ZigBee și vom demonstra utilitatea acestuia în diverse aplicații, cu o complexitate din ce în ce mai mare. Am ales acest protocol deoarece îl consider ca fiind unul dintre cele mai utile și ”de viitor”, întrucât, spre diferență de orice alt protocol, permite conectarea simultană a până la 65.000 noduri, sau chiar și mai mult decât atât.

Pe scurt, el poate să fie folosit la scară mare, având nevoie de o configurare corectă și la început, astfel încât să reziste diverselor mici probleme ce pot interveni, putând ulterior să funcționeze o durată foarte lungă de timp fără intervenția unui administrator.

În principiu, nu am ales folosirea Bluetooth sau Wi-Fi deoarece consumul de energie ridicat ar fi făcut protocolul inadecvat pentru lucrul în cadrul rețelelor de senzori. De asemenea, după cum am prezentat deja în tabel, aceste protocoale nu permit conexiunea între dispozitive pentru prea multe dispozitive. Mai mult decât atât, pentru a permite o conectare de tip point – to – multipoint, dispozitivele trebuie să ruleze un software care consumă mai multe resurse hardware interne, iar consumul acestora crește pe măsură ce crește și numărul de dispozitive conectare. ZigBee permite acest tip de conexiuni în mod implicit, iar consumul de energie și resurse nu crește semnificativ odată cu creșterea numărului de dispozitive conectate.

Un alt motiv care m-a împins să aleg ZigBee ca și principal protocol descris în cadrul acestui lucrări este reprezentat de raza de acțiune a acestuia – cu echipamentul potrivit, ZigBee poate oferi conectivitate eficientă pe o rază de până la 100 metri. Alte protocoale sunt de asemenea capabile să atingă această distanță, dar întrucât ne-am propus să lucrăm în mediul ”Internet of Things”, iar scenariile pe care le vom prezenta se desfășoară în principiu într-un mediu casnic sau de birou, nu este neapărată nevoie să ajungem la această distanță – în concluzie, nu am avea de ce să consumăm energie și putere de alimentare din moment ce distanța maximă pe care ne propunem să emitem/recepționăm nu depășește 20 – 25 metri.

Capitolul 3. Protocolul ZigBee

3.1 Caracteristicile principale

În primul rând, îmi doresc să stabilesc de la început că există o diferență între ZigBee și XBee, întrucât în cadrul documentării făcute pentru lucrarea curentă, am observat că se creează o confuzie între acești termeni, existând o ambiguitate. ZigBee reprezintă standardul folosit pentru comunicații wireless cu consum redus de energie și putere, în rețele de tip plasă (mesh), în timp ce XBee este un echipament hardware ce suportă o multitudine de protocoale wireless, printre care ZigBee (802.15.4), dar și WiFi.

Pentru a permite comunicare între un număr cât mai mare de dispozitive, fără a ține cont de producător, avem nevoie de o arhitectură de protocol care, la nivelul fizic să ofere a separare a componentelor și funcționalităților în mai multe module, care să poată fi asamblate în diverse metode. Fiecare rețea, indiferent de modul de interconectare a dispozitivelor care o alcătuiesc, are nevoie de un nivel fizic pe care să se transmită semnalele. Rețele de calculatoare se pot interconecta cu ajutorul cablurilor Ethernet, rețelele metropolitane pot fi realizate cu ajutorul cablurilor coaxiale, fibră optică etc., iar exemplele pot continua.

După cum am subliniat însă și mai devreme, tendința generală a prezentului este de a folosi protocoale wireless pentru nivelul fizic – pentru rețelele de calculatoare, protocolul cel mai des folosit este WiFi, în timp ce pentru rețele mobile de comunicații se folosesc protocoale GSM (Global System for Mobile Communications): 3G, 4G, GPRS, EGRPRS (EDGE), LTE etc. Din punct de vedere al aplicațiilor, al nivelelor superioare din stivele de protocoale (TCP/IP sau ISO/OSI), nu se va simți nicio diferență în momentul în care se face trecerea de la comunicațiile clasice, pe fir, la cele fără fir (cel mult vor apărea delay-uri, dar dacă aplicația este realizată corect, nu ar trebui să facă o diferență majoră). Când vorbim despre nivelul aplicație, ne referim la orice interacțiune directă cu utilizatorul (browser web, jocuri, întrerupătoare, becuri etc.). Aceste aplicații sunt ”protejate” de către interfețele dintre straturile stivelor de protocoale, care permit fiecărui modul software sau hardware să își modifice modul de funcționare, păstrând în continuare comunicarea cu celelalte nivele în exact același fel.

O echivalență, în vederea simplificării percepției și înțelegerii a acestor lucruri se poate face cu ajutorul modului de funcționare a unei mașini. Aceasta poate să meargă peste diverse tipuri de sol: străzi asfaltate, drumuri forestiere, drumuri cu noroi – fără a-și modifica comportamentul. Cauciucurile sunt cele care permit acest lucru, oferind o interfață între nivelul vehiculului (cel al aplicației în cazul nostru) și cel fizic (drumul parcurs). Mașina poate să fie reprezentată ori de vehiculul personal, ori de un camion, motocicletă și așa mai departe – deci aplicația poate să se schimbe, cât timp interfețele sunt prezente.

Nivelul de rețea ce se află sub ZigBee ce suportă o multitudine de caracteristici avansate este cunoscut sub numele de IEEE 802.15.4 – acesta reprezintă un set de standarde ce impun mai multe proprietăți funcționale, cum ar fi: managementul consumului de energie, tipul de adresa, corecția de erori, formatul mesajelor generale, precum și alte specificații tehnice necesare comunicațiilor de tip point – to – point. O parte dintre acestea reprezintă necesități pentru a permite comunicarea între mai multe noduri wireless, în timp ce o parte au fost impuse pentru creșterea performanțelor, în raport cu alte protocoale.

Ca și noduri, în cadrul lucrării prezentate vom lucra cu modulele XBee Series 2 (am fi putut lucra și cu Series 1, dar au performanțe mai mici pe termen lung de funcționare) – acestea suportă protocolul 802.15.4 în mod nativ, nefiind nevoie să instalăm componente software pentru interoperabilitate. După cum am spus deja, ZigBee reprezintă un set de nivele construite deasupra standardului 802.15.4 – acestea aduc trei lucruri foarte importante în cadrul unei rețele:

Rutare (routing)

În cazul cel mai general, rutarea reprezintă procesul de găsire al celui mai scurt drum de la o sursă la o destinație, pe baza informațiilor oferite de către rețea. Acest drum este, în general, în cadrul rețelelor, stabilit de către fiecare nod intermediar.

Tabelele de rutare definesc modul în care un nod radio wireless poate trimite mai departe (forwarding) mesajele către alte module wireless din apropierea sa, în vederea ajungerii până la o destinație specificată.

Tabelele de rutare pot fi populate în mod static sau dinamic, în funcție de alegerea celui care configurează nodurile – dinamic presupune folosirea unui protocol dinamic de comunicare între noduri (pe lângă ZigBee) care să decidă căile cele mai scurte, în timp ce modul static presupune configurarea de către administrator a tuturor căilor.

Crearea de rețele ad hoc

Rețelele ad hoc reprezintă rețele ce se creează în mod automat, fără a fi necesară intervenția unui administrator.

Sunt foarte utile în anumite circumstanțe, dar în cazul în care avem o aglomerare de noduri, rețelele se pot crea în mod diferit față de ceea ce ne-am fi dorit noi și pot conduce la o funcționare mai puțin eficientă decât cazul ideal.

Reconfigurare automată sub formă mesh

Rețelele de tip mesh reprezintă structuri în care oricare două noduri sunt interconectate prin mai mult de o cale disponibilă, existând oricând o cale redundantă. Căile redundante trebuie să depindă cât mai puțin unele de celelalte.

Reconfigurarea automată reprezintă capacitatea unei rețele de a-și reveni singură în cazul în care unul sau mai multe noduri nu mai sunt disponibile sau sunt afectate de către un factor extern care le face imposibilă comunicarea. Pe scurt, rutele rămân disponibile, chiar și după ce anumite noduri au devenit indisponibile.

3.2 Rețele formate cu ajutorul ZigBee

O rețea, indiferent de protocolul cu care aceasta este constituită sau de dispozitivele care o constituie, are mai multe tipuri de componente, care îndeplinesc diverse roluri. În cadrul rețelelor în care folosim ZigBee, există trei tipuri de componente, care îndeplinesc funcționalități specifice. Multe rețele pot conține doar două tipuri de componente, altele le vor conține pe toate trei. Decizia legată de acest lucru aparține administratorului, care, pe baza unei analize, hotărăște de ce funcționalități are nevoie și de care se poate folosi. Pentru dezambiguizare, când discutăm despre rețele, ne referim la cel puțin două noduri interconectate – se pot obține diverse funcționalități minimale și cu un singur nod wireless, dar acestea nu vor fi prezentate în cadrul lucrării prezentate.

ZigBee, ca și protocol, a fost proiectat în mod special pentru conceptul de Internet of Things și de automatizări casnice.

3.2.1 Tipurile de dispozitive în cadrul unei rețele

Coordonator

Orice rețea ZigBee are nevoie în orice moment de timp de către un coordonator. Acesta trebuie să fie unic la nivel de rețea.

Un coordonator este responsabil cu formarea topologiei logice a rețelei, oferire și configurarea adreselor și managementul altor funcționalități ce definesc rețeaua, o securizează și o păstrează funcțională pentru intervale lungi de timp.

Rolul unui coordonator poate fi asumat de către un alt nod, în cazul în care principalul devine indisponibil.

Se recomandă ca coordonatorul să aibă o sursă de energie cât mai sigură, pentru a nu pune în pericol funcționarea rețelei. De asemenea, coordonator se alege și nodul care are cele mai bune resurse hardware, pentru a putea face față unui număr mare de conexiuni active în orice moment de timp.

Router

Un router reprezintă un nod wireless ce are acces la toate caracteristicile specifice protocolului ZigBee.

O rețea poate avea mai multe noduri care să îndeplinească funcționalitatea de router.

Se poate conecta în mod activ la o rețea (nu are deci nevoie de un administrator care să-i spună să se conecteze) sau poate cere să se alăture unei rețele, dacă aceasta este securizată.

Poate trimite și primi informații de la alte noduri, dar cel mai important – poate ruta informațiile primite. Acest lucru înseamnă că dacă un mesaj a ajuns la router dar nu îi este destinat acestuia, el se poate ocupa cu trimiterea mai departe a informațiilor, către nodul corespunzător, cu ajutorul tabelei de rutare.

Routerele trebuie de asemenea să aibă o sursă de alimentare constantă, pentru a nu se risca discontinuități în procesul de comunicare.

End device (dispozitiv terminal)

Aceste dispozitive sunt folosite în principiu, în circumstanțele în care capacitățile hardware și consumul de energie al unui router nu sunt necesare. Ele sunt de fapt versiuni mai reduse ale routerelor.

End device-urile pot să se alăture în mod pasiv rețelelor din jurul său și sunt capabile să trimită și să primească informații, dar astea sunt cam toate capacitățile sale.

Un end-device are nevoie în orice moment de timp de un router sau un coordonator la care să se conecteze, pentru a reprezenta ”părintele”. Un end-device nu se poate conecta în mod activ într-o rețea și depinde de existența unui ”părinte” – acesta îi ajută să se conecteze la rețea și de asemenea stochează mesaje când end–device-urile sunt în stand-by.

O rețea poate conține un număr foarte mare de end-device-uri – de fapt, bazându-ne pe caracteristicile ZigBee, putem forma o rețea care să conțină doar un coordonator și multe end-device-uri, fără niciun router. Totuși în aceste circumstanțe, performanțele vor fi limitate

La un end-device, de cele mai multe ori, se vor conecta senzori – direct sau indirect cu ajutorul unei plăci de dezvoltare (cum ar fi Arduino)

3.2.2 Topologiile disponibile

O topologie reprezintă modul de interconectare al dispozitivelor în cadrul unei rețele – modul în care se coordonează și își transmit informațiile între ele. O topologie poate să fie logică sau fizică – amândouă sunt la fel de importante. Pentru a concepe o topologie completă și corectă este necesară o analiză cuprinzătoare asupra a ceea ce se dorește implementat, luându-se în considerare o multitudine de factori, printre care:

Numărul de dispozitive conectate în orice moment de timp (în cazul nostru, se discută despre noduri);

Mobilitatea nodurilor conectate – în cazul rețelelor de senzori wireless, ne va interesa raza de acțiune a protocolului, întrucât o parte dintre senzori vor putea fi mobili;

Lățimea de bandă necesară fiecărui nod – majoritatea scenariilor pe care urmează să le ilustrăm nu necesită o lățime foarte mare de bandă, întrucât volumul de date transmis într-o secundă nu este foarte mare;

Topologia fizică reprezintă poziționare efectivă într-un mediu a nodurilor, conținând distanța dintre acestea și mediul folosit pentru interconectare (în cazul nostru vom avea numai mediul wireless). Topologia logică conține informații legate de adresarea nodurilor, protocoalele folosite, securitatea impusă în cadrul rețelei, rolul jucat de fiecare nod în parte etc. Cele două topologii diferă în majoritatea cazurilor.

În cadrul rețelelor constituite cu ajutorul ZigBee, avem la dispoziție, în principiu, patru tipuri de topologii logice, pe care urmează să le descriem în continuare. Topologiile fizice nu au o relevanță foarte mare în cadrul acestor rețele, întrucât mediul de transmisiune va fi întotdeauna reprezentat de către aer, iar poziționarea va fi relativă la locația în care se dorește implementarea unui exemplu/scenariu.

Pereche (Pair)

Reprezintă cea mai simplă modalitate de interconectare a oricare două noduri/module wireless. După cum am precizat și mai sus, orice rețea are nevoie de un coordonator unic – așadar, în cadrul topologiei, unul dintre noduri trebuie să fie reprezentat de acesta, în timp ce celălalt va fi reprezentat de către un router sau un end-device.

Această topologie este ideală pentru scenariile simple și pentru detectarea, și rezolvarea problemelor dintr-o topologie mai mare – se izolează pe rând nodurile, iar cu ajutorul unui nod de test, de a cărui funcționalitate corectă suntem siguri, se testează fiecare dintre acestea, în rețele de tip pereche.

Figura 3-0-1

Stea (Star)

Acest tip de rețea este de asemenea, în principiu, destul de simplu de înțeles și implementat – un nod ce îndeplinește funcția de coordonator se află în centrul topologiei, iar el se conectează, la un număr de end device-uri. Orice mesaj trimis în cadrul acestui tip de rețea trebuie să treacă, în mod obligatoriu, prin coordonator, care se ocupă cu rutarea lor în mod corespunzător, către destinația finală.

End-device-urile nu au comunicare directă între ele în cadrul acestui tip de topologie – avem astfel avantajul că nu pot apărea suprapuneri de date, reducând posibilitatea pierderii informațiilor furnizate de către orice end-device la orice moment de timp.

Figura 3-0-2

Plasă (Mesh)

Complexitatea rețelelor crește în momentul în care se folosește acest tip de topologie, întrucât avem prezente în mod concomitent toate cele trei tipuri de componente – coordonator, router și end-device. Routerele sunt responsabile cu trimiterea mesajelor către alte routere sau către end-device-uri atunci când este necesar. Coordonatorul (reprezintă mai mult o formă avansată de router) este responsabil cu managementul rețelei și poate de asemenea să ruteze mesaje. End device-urile se pot lega atât de coordonator, cât și de router – ele pot genera și primi trafic de date, dar vor avea nevoie întotdeauna de un ”părinte” care să le ajute să comunice cu alte noduri ale rețelei.

Rețelele ce sunt construite pe baza acestei topologii se diferențiază față de cluster-tree prin faptul că au un grad ridicat de redundanță – asta înseamnă că un router se conectează simultan la coordonator dar și la alte routere – dacă apare o problemă cu o cale de comunicare, există întotdeauna una redundantă. În majoritatea circumstanțelor acest lucru reprezintă un avantaj, dar poate fi considerat un dezavantaj când este necesară calcularea constantă a celor mai scurte drumuri, care să fie instalate în cadrul unei tabele de rutare.

Figura 3-0-3

Arbore (Cluster-tree)

Se asemănă destul de mult cu topologia mesh, dar, în acest tip de topologie, routerele formează o formă de ”back bone” a rețelei, care se conectează doar la coordonator. Nu mai există niciun fel de redundanță a rețelei, iar defecțiunea unui router, aduce o dată cu sine, imposibilitatea de comunicare a anumitor end-device-uri.

Figura 3-0-4

3.2.3 Adresarea nodurilor

Pentru a fi posibilă comunicarea între oricare două dispozitive, în cazul general, este necesar ca cele două să aibă stabilite adrese, de același fel, cu ajutorul cărora să se identifice destinația intenționată. În cadrul protocolului ZigBee se respectă această regulă, niciun mesaj neputând fiind transmis de către un nod fără o adresă destinație stabilită.

Într-un mod asemănător adresării folosite în rețelele Ethernet – IPv4 (Internet Protocol version 4), ZigBee folosește două tipuri de adrese pentru identificarea sursei și a destinației. În primul rând, fiecare nod ZigBee este identificat, la nivel global cu o adresă serială pe 64 de biți, reprezentată în format hexazecimal. Aceste adrese sunt unice, neexistând, teoretic, două noduri fabricate cu aceeași adresă. Pentru a putea fi ușor de citit și identificat, aceste adrese sunt inscripționate pe spatele nodurilor. În figura de mai jos se poate observa adresa unuia dintre nodurile folosite în cadrul acestei lucrări (un nod de tip XBee, care va fi detaliat în capitolele următoare).

Figura 3-0-5

Pe lângă această adresă, se mai folosește o adresă mai scurtă, pe 16 biți, alocată în mod dinamic de către nodul coordonator în cadrul unei rețele funcționale. Această adresă nu mai este unică decât la nivelul unei rețele wireless de noduri, motivul principal pentru care este folosită fiind reprezentat de către dimensiunea mai redusă a pachetelor în cadrul transmisiei și de către memoria relativ limitată a echipamentelor.

În cele din urmă, un nod XBee poate să primească și o adresă reprezentată sub forma unui șir de caractere, cu ajutorul căruia să fie mai ușor unui administrator să urmărească configurarea și comportamentele membrilor unei rețele. Această adresă nu este folosită în cadrul transmisiunii de date, ci doar pentru monitorizare și verificare, fiind utilă minții umane – într-un mod asemănător sunt folosite numele pentru identificarea site-urilor și nu adresele IP publice, unice la nivel global.

În continuare, fiecare rețea în parte va avea un identificator propriu, pentru a asigura sincronizarea dintre nodurile pe care le doresc să comunice între ele – în felul acesta, protocolul ne permite să avem mai multe noduri în aceeași locație, dar care să facă parte din rețele diferite – cu o sincronizare corectă, nu vor avea loc nici interferențe (despre canalele folosite de către ZigBee discutăm în capitolele următoare). Rețelele create cu ajutorul protocolului ZigBee se încadrează în categoria PAN (Personal Area Network – Rețele personale), iar identificatorul folosit pentru acestea este de asemenea pe 16 biți, reprezentat sub forma hexazecimală.

Putem concluziona, după analiza adresării ce ne stă la dispoziție, că avem posibilitatea definirii unui număr de 65.536 (2^16) rețele unice la nivelul unei suprafețe clar delimitate, fără a exista riscul suprapunerii între două dintre acestea. În cadrul fiecărei rețele, avem posibilitatea alocării adreselor unice către 65.536 de noduri – în felul acesta putem spune că într-o suprafață în care funcționează protocolul ZigBee putem avea peste 4 miliarde de dispozitive (4.294.967.296) care să comunice simultan pentru transmisia de date. Această valoare este echivalentă cu numărul teoretic de adrese unice IPv4 ce pot fi alocate la nivel global în Internet.

Trebuie subliniat că la această valoare se ajunge doar dacă este optimizat și procesul de alocare al canalelor și nu există interferențe între noduri foarte apropiate – în cazul în care nu este respectat acest lucru, eficiența transmisiei va scădea, îngreunând comunicarea.

Figura 3-0-6

3.2.4 Canalele de comunicație

Pe lângă responsabilitatea alegerii unui identificator pentru PAN și alocarea adreselor unice la nivel de rețea, coordonatorul mai trebuie să aleagă și un canal pe care să se sincronizeze și să comunice cu nodurile din rețea. Canalul trebuie să fie unic pentru o rețea, iar în majoritatea cazurilor, coordonatorul face alegerea după ce le scanează pe toate cele disponibile și îl identifică pe cel mai puțin aglomerat. Spre diferență de alte protocoale, coordonatorul dintr-o rețea ZigBee își poate schimba în mod automat canalul când simte o aglomerare de trafic de date, semnalând acest lucru către routere și end device-uri.

Standardul IEEE 802.15.4 oferă trei moduri de operabilitate, în următoarele benzi de frecvență: 2.4GHz (disponibil la nivel mondial), 915MHz (Statele Unite ale Americii), 868MHz (Europa). Împărțirea în canale între acestea se face în felul următor

Un canal între 868 – 868.6 MHz (20kbit/s)

10 canale între 902 – 928 MHz (40kbit/s)

16 canale între 2.4 și 2.4835 GHz (250kbit/s)

Toate aceste benzi de frecvență funcționează bazându-se pe tehnica spectrului direct împrăștiat (Direct Sequence Spread Spectrum – DSSS). Pentru modulare, banda de 2450 MHz folosește modularea în fază cu offset în cuadratură (Offest Quadrature Phase Shift Keying – OPQSK), în timp ce benzile de 868 – 915 MHz se bazează pe modulare binară în fază (Binary Phase Shift Keying – BPSK).

În majoritatea cazurilor se va opta pentru folosirea lățimii de bandă de 2.4 GHz, datorită ratei de bit mult mai ridicată (de peste 10 ori, conform tabelului de mai sus) și datorită ariei de acoperire mult mai bună a semnalului. Totuși, odată cu această alegere ne punem problema suprapunerii cu protocolul 802.11 (Wi-Fi), întrucât majoritatea access-point-urilor (AP-urilor) folosesc aceeași frecvență pentru comunicare (chiar dacă în ultimele versiuni, 802.11 permite comunicarea și pe 5GHz și 50GHz – acestea consumă mult mai multă energie).

Această problemă este una reală, întrucât Wi-Fi este principalul protocol folosit în rețelele wireless de transmisii de date, ca alternativă la clasicele rețele Ethernet și cabluri de cupru (UTP – Unshielded Twisted Pair sau coaxiale), fiind practic prezent în aproape orice clădire sau locuință. Wi-Fi și ZigBee folosesc aceeași lățime de bandă, dar scopul pentru care sunt folosite este radical diferit, ZigBee fiind folosit pentru rețele de senzori, procese de automatizare, monitorizare etc.

După cum se poate observa și în figura de mai jos, singurele canale (cu lățime de 22 MHz) ale protocolului 802.11 care nu se suprapun sunt 1, 7, 13 (respectiv 1, 6, 11 pentru SUA). Atât canalul 1 cât și canalul 6 (respectiv 7) se suprapun cu mai multe canale ale lui ZigBee (lățime mult mai mică, doar 2 MHz). Singurul canal al Wi-Fi care nu se suprapune complet cu ZigBee este canalul 11 (respectiv 13).

Din punct de vedere al planificării unei rețele, acest amănunt poate complica puțin lucrurile, dar în realitate nu este atât de dificil să se renunțe în cadrul configurării Wi-Fi la canalul 11, pentru a se permite existența unor canale libere de ZigBee. Iar în eventualitatea în care acest lucru nu este posibil, cele două pot coexista fără prea mari probleme de comunicare – apar delay-uri și pierderi de date semnificative doar în momentul în care ambele rețele au trafic constant și conectate cel puțin 30 – 35 de dispozitive/noduri.

Figura 3-0-7

3.3 Componentele hardware ale transmisiunii de date

În capitolele precedente ne-am ocupat cu prezentarea generală a protocolului ZigBee și a noțiunilor fundamentale legate de funcționarea sa într-un mediu standard de comunicație. În continuare ne propunem să detaliem modul de transmisiune a datelor, informațiile hardware legate de dispozitive folosite pentru comunicarea cu acest protocol, stările de funcționare a acestor noduri și particularitățile comunicațiilor de acest fel.

3.3.1 Modulele XBee

După cum am precizat anterior la începutul lucrării, există o diferență majoră între ZigBee și XBee – primul fiind protocolul folosit în această lucrare, în timp ce XBee este denumirea modulelor hardware ce sunt compatibile cu acest protocol și sunt folosite în cadrul rețelelor de senzori pentru transmisia și recepția datelor relevante.

Modulele XBee au un design atât hardware cât și software conturat de către Digi International, fiind livrate împreună cu o varietate de antene (cu ajutorul cărora se poate regla puterea de transmisiune și distanța acoperită de semnalul transmis) și module firmware ce pot fi actualizate oricând cu ajutorul unui software. În continuare vom detalia cele mai populare module XBee folosite în prezent, axându-ne pe cele folosite în cadrul lucrării. Există două versiuni de bază a modulelor XBee:

XBee Series 1 – Acestea sunt produse de către Freescale și au rolul de a oferi un mod simplu de transmisiune, bazându-se în principiu pe comunicațiile de tip punct – la – punct. Pe lângă acesta mai este posibilă folosirea unor rețele de tip mesh personalizate acestor module. Nu vom folosi aceste module în cadrul lucrării întrucât ne vom axa pe rețele a căror dimensiune poate fi crescută fără nicio problemă.

XBee Series 2 – Cea de-a doua serie de module XBee sunt dotate cu un microcontroler de la Ember Networks, care le permite funcționarea într-o gamă mai largă de rețele. Rețele de tip mesh sunt optimizate cu acest microcontroler, pe conceptul acestora fiind construite majoritatea rețelelor de senzori. În cadrul lucrării, toate noțiunile prezentate se vor baza pe acest tip de module.

Ambele tipuri de module se găsesc atât în versiuni standard, cât și în versiuni mai profesioniste, diferența fiind dată de către puterea de transmisie a semnalului – versiunile profesioniste se identifică prin cuvântul Pro atașat denumirii – XBee Series 2 Pro. O diferență relevantă între cele două mai este dată de cost, versiunile Pro fiind mai scumpe, datorită specificațiilor tehnice superioare. În cadrul lucrării nu vom folosi modulele Pro întrucât nu avem nevoie de putere foarte mare de transmisie.

Figura 3-0-8

3.3.2 Specificații tehnice

În timp ce modulele Series 1 sunt foarte populare la început, pentru învățat și proiecte de dimensiuni reduse, modulele Series 2 sunt recomandate datorită faptului că suportă toate proprietățile protocolului ZigBee. Acestea au un design special pentru rețelele de senzori de dimensiuni ridicate, fiind potrivite pentru mediile mari de lucru, comerciale, academice, dar și cele casnice.

Acestea din urmă au o rază mai mare de acoperire, folosind și mai puțina putere pentru alimentare decât Series 1. Formatul fizic este păstrat pentru a putea fi posibilă actualizarea, într-un mod cât mai simplu din punct de vedere hardware, de la Series 1 la Series 2. Totuși, nu există posibilități de interoperabilitate între cele două versiuni – acest lucru înseamnă că dacă se decide migrarea unei rețele de la Series 1 la 2, toate modulele trebuie schimbate, nu doar o parte, întrucât o singură rețea nu poate fi constituită din ambele variante, simultan.

În continuare prezentăm specificațiile tehnice ale celor două tipuri de module, scoțând în evidență superioritatea modulelor Series 2.

Modulele XBee, ca orice alte dispozitive ce funcționează cu unde radio, au nevoie de antene pentru a putea transmite și primi semnale. Există mai multe moduri de a integra antenele pe componentele hardware prezentate, fiecare având propriile avantaje și dezavantaje. Vom prezenta doar câteva în continuare, întrucât în cadrul lucrării nu ne-am folosit de antene, nefiind nevoie de ele pentru conceptele demonstrate.

Antena de tip fir – o simplă legătură conectată la modulul radio – în majoritatea cazurilor este exact ceea ce trebuie pentru comunicații, fiind simplă cu radiații omnidirecționale (puterea semnalului este aproximativ aceeași în toate direcțiile, în linie dreaptă și perpendiculară pe modul)

Antenă de tip chip – Un modul sub forma unui chip ceramic, atașat direct pe modulul XBee – are avantajul faptului că semnalul nu este propagat în toate direcțiile. Reprezintă alegerea ideală pentru produsele ce se doresc a fi purtate de către utilizator.

Conector U.FL – Există două tipuri de conectori pentru antenele externe, iar acesta este cel de dimensiuni reduse. Aceste antene nu sunt întotdeauna necesare, fiind folosite doar în momentele în care modulele radio sunt încapsulate (închise într-o cutie), iar antena trebuie să fie în exterior – în felul acesta semnalul nu este atenuat în mod semnificativ.

Conector RPSMA – Acest conector reprezintă doar o formă mai mare a conectorului U.FL (care este mai fragil). Folosit în mediile în care antena ar putea să fie afectată de șocuri mecanice – avem o siguranță mai mare a faptului că aceasta va rămâne conectată la modulul XBee.

Figura 3-0-9

3.3.3 Conexiunea la modulele XBee

Vom discuta în continuare despre modul în care utilizatorul uman poate interacționa cu modurile XBee, dar și despre modurile în care acestea pot comunica între ele. Pentru început însă, precizăm că în vederea configurării și comunicării dintre calculator și modulul XBee este necesar un modul specific.

Mai exact, este necesar un adaptor care să permită scrierea și citirea informațiilor de pe modulele XBee pentru utilizatorul uman, împreună cu un software specific ce va rula pe calculatorul de pe care se realizează modificările. Aceste adaptoare se pot conecta direct pe o conexiune serială (USB), având 5 pini principali ce pot fi folosiți (Reset, RX, TX, Masă, alimentare 5V). Modulele folosite în cadrul acestei lucrări nu pot fi utilizate pentru alte scopuri pe lângă comunicarea cu calculatorul, întrucât nu oferă conectivitate către ceilalți pini ai modulului XBee.

Totuși, aceste adaptoare pot fi folosite pentru o conexiune minimală între noduri, în vederea verificării sincronizării unei rețele și a transmisiei de date foarte simplă (cum ar fi un chat).

Figura 3-0-10

Pentru partea de software, există o soluție oferită de producătorii modulelor XBee ce poate fi folosită pentru update-ul firmware-ului, schimbarea rolurilor și modificări de bază legate de funcționalitate. Numele programului este XCTU și poate fi descărcat direct de pe pagina celor de la Digi Communications – https://www.digi.com/products/xbee-rf-solutions/xctu-software/xctu.

În cadrul acestui program este posibilă descoperirea în mod automat a modulelor XBee conectate, împreună cu ”citirea” informațiilor legate de funcționalitatea la un moment dat a acestora, după cum este ilustrat în următoarele figuri:

Figura 3-0-11

Din interfața ce se deschide în mod automat la pornirea programului selectăm opțiunea de descoperire a modulelor radio conectate, după ce acestea au fost conectate pe legătura serială disponibilă – în cazul de față, USB.

Figura 3-0-12

Figura 3-0-13

După finalizarea căutării, modulele radio descoperite vor fi prezentate în cadrul ferestrei principale a aplicației, fiind specificat rolul acestora, portul pe care se află conectate și adresa MAC (adresa fizică) corespunzătoare.

Figura 3-14

În continuarea selectării unuia dintre modulele descoperite, ne vor fi prezentate toate informațiile configurate până la momentul respectiv și de asemenea, vom avea posibilitatea modificării acestor date cu ușurință (lucru ce ne va fi util în continuare).

Această citire și configurare este realizată într-un mod asemănător celui în care modulele XBee își transmit informațiile între ele. Totuși, în momentul în care se realizează conexiunea serială, datele pot fi încapsulate în două moduri diferite:

Echipamentele configurate în mod API folosesc o încapsulare a datelor ce ușurează comunicațiile dintre calculatoare, dar este mai dificil de interpretat de către utilizatorii umani

Modul AT – oferă o serie de comenzi ce sunt concepute special pentru a ușura configurarea de către utilizatorul uman. În cadrul acestui mod de configurare/comunicare, modulele radio se pot afla în două stări:

Modul transparent

Acesta este modul implicit pentru modulele radio ce funcționează în modul AT. Poartă această denumire întrucât radiourile trimit pur și simplu mai departe informațiile primite, fără a le altera sau modifica în vreun fel. Când primește date de la un alt nod, acestea sunt trimise pe legătura serială în mod identic celui în care au fost primite.

Modul de comandă

Acest mod este folosit în momentul în care ne dorim ca nodul să nu trimită mai departe informațiile primite de la calculator, ci mai degrabă să le păstreze în vederea configurării – mai exact, îl folosim când dorim să schimbăm ceva anume în funcționarea nodurilor.

Trecerea între modul transparent și modul de comandă este realizată prin folosirea unei secvențe prestabilite – ”+++”. În momentul în care este primită această secvență, nodul intră în modul de comandă, semnalează acest lucru prin returnarea unui mesaj ”OK”, unde așteaptă comenzi de configurare. Dacă nu se detectează niciun fel de comenzi de configurare timp de 10 secunde, atunci se face în mod automat trecerea în modul transparent.

Pentru această configurare, poate fi folosit meniul de terminal al aplicației XCTU sau un alt program ce emulează o consolă și citește/interpretează informații de pe interfața serială, cum ar fi PuTTy, CoolTerm etc. În imaginea de mai jos este demonstrată trecerea din modul transparent în cel de comandă, precum și modificarea, verificarea și salvarea unui parametru (PAN ID).

Figura 3-15

3.4 Transmisia de date între modulele XBee

Configurate în modul AT, nodurile XBee au o funcționare destul de simplă de înțeles și utilizat (după cum este ilustrat în capitolul anterior), transmisia făcându-se în mod serial, nefiind necesară segmentare de date sau o sincronizare a acestora. Singura necesitate în cadrul unei rețele formată din module XBee configurate în mod AT de funcționare este ca acestea să formeze o rețea – adică să aibă același PAN ID, unul dintre dispozitive să aibă rolul de coordonator și să funcționeze pe același canal de transmisiune.

În cadrul lucrării prezentate vom folosi modul AT de configurare în cadrul primelor proiecte prezentate pentru a ilustra funcționalitatea de bază a protocolului, urmând ca ulterior, coordonatorul rețelei – cel care practic stochează și afișează datele recepționate, să lucreze în mod API.

API – Application Programming interface – reprezintă în general un set de interfețe standard de comunicare, concepute special pentru a se permite comunicarea între două programe software, fără a se ține cont de limbajul în care acestea sunt scrise, locația în care acestea rulează, sisteme de operare etc. Pe scurt, cu ajutorul unui API, o aplicație de tip software poate să trimită cereri, către un alt program, formatarea cererii făcându-se într-un standard cunoscut și utilizat de către toată lumea.

În modul AT, aveam nevoie de un terminal pentru a realiza comunicarea cu nodurile XBee, iar informația era afișată doar în acele ferestre. Acest mod este util și pentru comunicarea cu modulele externe, cum ar fi plăcuțele de dezvoltare Arduino. Vom folosi modul API de comunicare pentru a putea permite și altor aplicații să primească informații direct de la modulele XBee pentru a le putea prelucra și lua decizii pe baza acestora. Bibliotecile necesare comunicării dintre aplicațiile scrise în aproape orice limbaj de programare pot fi integrate cu ușurință în cadrul unui IDE (Integrated Development Environment).

Figura 3-16

Specificăm ca nodurile XBee nu au suficientă memorie integrată pe placă pentru a putea reține atât comenzile de configurare pentru modul AT cât și cele specifice modului API. În consecință. pentru a putea face trecerea dintr-un mod în altul, este necesar upload-ul unui firmware diferit, lucru care se poate realiza cu ajutorul adaptoarelor prezentate mai devreme și a programului XCTU.

Figura 3-17

Scopul modului API este acela de a oferi o transmisie de date predictibilă, sigură și eficientă, prin intermediul bibliotecilor software corespunzătoare. În continuare prezentăm structura cadrelor folosite pentru asigurare sincronizării între programele software ce comunică între ele și transmisia efectivă de informații.

Delimitator start – Fiecare frame specific transmisiunii în modul API are un preambul specific pentru a ajuta dispozitivele la sincronizare. Acest preambul este reprezentat de o valoarea hexazecimală – 0x7E (126 în valoare zecimală). Ne folosim de acest lucru pentru a știi când să citim și la ce anume să ne așteptăm în cadrul unei transmisii de date.

Lungime cadru – Următorii 2 bytes recepționați după preambul ne indică lungimea totală a cadrului transmis, respectiv recepționat – în majoritatea cazurilor, MSB (Most Significant Byte) are valoarea 0, în timp ce LSB (Least Significant Byte) conține întreaga lungime. Atunci când se folosesc cadre cu o dimensiune mai mare, se poate modifica și valoarea MSB. Totuși, în cadrul ZigBee se recomandă să nu se folosească cadre de dimensiuni foarte mari, ci un număr mai mare de cadre.

Date (payload) – În această parte a cadrului sunt conținute datele relevante în vederea prelucrării și luării deciziei. Conținutul acestui câmp reprezintă ceea ce anume ne dorim să transmitem de fapt între două noduri.

Checksum (verificator) – Acest ultim byte din cadrul unui frame reprezintă modalitatea prin care ne asigurăm că datele au fost transmise în întregime și nu au existat pierderi pe parcurs. Valoarea scrisă în acest câmp este obținută printr-o formulă de însumare a tuturor byte-urilor de dinainte – din acest rezultat se păstrează doar ultimii 8 biți, iar rezultat se scade din hexazecimalul 0xFF.

Înainte de a transmite un frame, orice nod XBee calculează această valoare și o scrie în ultimul câmp disponibil. La destinație, se recalculează această valoare, iar dacă cele două coincid, atunci se poate concluziona că datele au fost transmise în întregime, fără a exista pierderi.

Respectând structura generală a cadrului prezentată mai sus, există mai multe tipuri de mesaje folosite pentru a trimite sau primi informații de la un nod radio XBee. Există un număr foarte mare de cadre specifice protocolului, dar în continuare ne vom concentra doar pe cele mai importante.

Byte-ul corespunzător tipului de frame ne indică ce fel de cadru API am primit/trimitem și ne permite să îl analizăm – de exemplu un frame de tip 0x08 ne indică faptul că urmează o comandă de tip AT.

Capitolul 4. Proiectarea unui sistem de aprindere de la distanță a luminii

În cadrul acestui proiect ne propunem să controlăm intensitatea luminoasă dintr-o încăpere, la distanță, folosind protocolul ZigBee. Urmează să prezentăm implementarea în două moduri:

manuală – cu ajutorul unui potențiometru se va regla la distanță intensitatea luminii

automată – folosind un fotorezistor, vom măsura intensitatea luminoasă dintr-o anumită zonă și vom aprinde luminile atunci când este depășit un anumit prag.

Transmisia de date în cadrul acestor proiecte se va face de asemenea în două moduri diferite, pentru a putea ilustra posibilitățile oferite de către protocol și de către modulele XBee ce urmează să fie utilizate – în primă fază vom face transmisia de date ajutându-ne în totalitate de modulele Arduino Uno, ulterior trecând la transmisiune directă între noduri.

Aprinderea manuală a sistemului de iluminat

În cadrul acestui scenariu vom avea nevoie de conectarea modulelor XBee la o placă de dezvoltare Arduino, pentru a se putea face transmisia datelor citite de la un potențiometru, respectiv aprinderea unui sistem de iluminat. În cadrul scenariului nostru ne vom limita la aprinderea unor LED-uri conectate pe plăcuțele de dezvoltare (breadboard), dar logica implementată poate să fie păstrată și pentru un sistem de dimensiuni mai mari.

În cadrul proiectării acestui sistem vom folosi următoarele componente:

2 module XBee Series 2 – unul dintre ele configurat în mod de coordonator AT, în timp ce al doilea în mod endpoint AT

2 plăcuțe intermediare pentru conectarea modulelor XBee la breadboard – spațierea dintre pinii modulelor XBee este de doar 2mm, în timp ce breadboard-urile standard au o spațiere între puncte de 2.54mm (1 inch).

2 breadboard-uri

Un potențiometru

Un modul de conectarea a plăcuțelor XBee la calculator în vederea configurării acestora

1 Rezistor

2 plăcuțe de dezvoltare Arduino Uno.

Pentru a putea trece mai departe, vom prezenta pe scurt placa de dezvoltare Arduino Uno, împreună cu IDE-ul folosit pentru programarea sa (Arduino IDE).

4.1.1 Placa de dezvoltare Arduino Uno

Arduino Uno este una dintre cele mai populare plăci de dezvoltare folosite în cadrul dezvoltării de proiecte electronice, întrucât este ușor de configurat, are un număr destul de mare de pini și este compatibilă cu un număr foarte mare de shield-uri, care permit adăugarea diverselor funcționalități.

Printre avantajele folosirii plăcuței Arduino Uno se numără faptul că nu este necesară scrierea manuală a prea multor funcții, întrucât, foarte multe dintre ele, deja există scrise în librăriile Arduino IDE și este necesar doar includerea lor în programele ce sunt dezvoltate. Acest lucru duce mai departe la ușurința utilizării unui număr foarte mare de shield-uri, fără a se pune probleme legate de rescriere a bibliotecilor sau de incompatibilități cu componente externe.

De asemenea, după ce am încărcat secvența de cod, aceasta rămâne salvată în cadrul memoriei flash chiar și după ce nu mai avem alimentare. În momentul în care realimentăm placa nu mai este nevoie să ne reconectăm și să retransmitem codul întrucât el este deja acolo și este rulat automat.

Ca și dezavantaje putem enumera frecvența destul de scăzută a microprocesorului și memoria nu foarte cuprinzătoare de tip flash și EEPROM. Un alt amănunt care nu se pliază foarte bine conceptului de Internet of Things este acela că placa nu vine cu un adaptor Ethernet inclus și trebuie achiziționat separat shield-ul potrivit.

Specificații tehnice:

Microcontroler ATmega328

Memorie flash: 32KB

Frecvență procesor: 16 MHz

Memorie SRAM: 2KB

Memorie EEPROM: 1KB

Pini digitali I/O: 14(dintre care 6 pot oferi output PWM)

Pini analogi input: 6

4.1.2 Programarea Arduino Uno

Așa cum am precizat anterior, parte a conceptului Arduino este aceea care susține că orice individ, având cunoștințe minime sau în dezvoltare legate de programare și electronică să poată să folosească tehnologia oferită de către plăcuțele Uno, Mega, Leonardo etc. în scopuri personale sau pentru a-și ușura stilul de viață.

Pentru ca acest lucru să fie posibil este nevoie de un sistem de operare al plăcilor care să poată să înțeleagă limbaje de programare simple și care să nu aibă nevoie de includerea a prea multor biblioteci, cel puțin la început. De asemenea, modul de comunicare dintre utilizator și hardware trebuie să fie destul de simplu.

Software-ul care rulează pe plăci îndeplinește toate aceste condiții, iar cu ajutorul Arduino IDE(Integrated Development Environment) se poate folosi orice limbaj de programare(C/C++/Java etc.) pentru a scrie programele. Compilatorul inclus în cadrul aplicației poate înțelege toate aceste limbaje, pe care le traduce în limbaj mașină și le trimite către placa de dezvoltare. Un plus al Arduino IDE mai este faptul că, spre diferență de alte programe de verificat și compilat cod, funcționează fără nicio problemă pe orice sistem de operare care rulează pe calculatoare: Windows, Mac OS X sau diverse versiuni de Linux.

Arduino IDE vine, de asemenea, integrat cu o librărie software “Wiring”, care conține foarte multe proceduri și funcții des utilizate pentru citirea informațiilor de la pin-urile plăcii sau pentru trimiterea de semnale către acestea.

Cele mai simple programe în limbajul C/C++ ce pot fi rulate pe Arduino, conțin două funcții de bază, obligatorii, ce sunt compilate și legate între ele în cadrul unei alte funcții main():

setup() – o funcție ce rulează o singură dată la pornirea programului și inițializează parametrii de lucru ai programului ce urmează să fie pus în aplicare

loop() – o funcție ce este reluată și rulată până când placa de dezvoltare nu mai este alimentată

4.2.1 Schema electrică a proiectului

Conectarea modulelor XBee nu se va face direct pe breadboard, din cauza spațierii pinilor. Vom folosi un breakout-board pentru conectarea intermediară dintre cele două. Acest lucru nu a putut fi explicat în schema electrică realizată cu ajutorul programul fritzing.

Pentru partea de receptor (sistemul efectiv de iluminare) avem următoarea schemă electrică:

După cum se poate observa pe schemă, alimentăm nodul XBee la tensiune de 3.3V (acesta nu va funcționa la o tensiune mai ridicată – cum ar fi cea de 5V) – prin conectarea alimentării la pinul 1. Legăm și pinul de masă (ground) al modului XBee – pinul 10 în mod corespunzător pe breadboard.

LED-ul pe care dorim să îl aprindem de la distanță îl vom conecta la un pin PWM (Pulse Width Modulation) – pinul 3 în cazul nostru, pentru a putea transmite tensiuni variabile, care să ne reprezinte aprinderea la diverse intensități.

Arduino Uno trebuie să aibă pinii de transmisie și recepție a datelor (TX, respectiv RX – 1 și 0) conectați la pinii echivalenți ai modulului XBee (pinii 2 și 3).

Folosim de asemenea și un rezistor pentru a nu conecta în mod direct LED-ul la pinul de alimentare, evitând în felul acesta arderea diodei.

În continuare prezentăm schema electrică a emițătorului (controlerul sistemului de iluminat).

După cum se poate observa, doi dintre pinii potențiometrului se conectează la alimentare, respectiv masă, în timp ce cel de-al treilea este conectat la unul dintre pinii analogici ai plăcuței de dezvoltare Arduino Uno. Folosim un astfel de pin pentru a putea citi în mod corespunzător valorile trimise de către potențiometru.

Ca și în schema de mai sus, modulul XBee se conectează la Arduino Uno prin cei doi pini RX/TX, fiind alimentat la o tensiune de 3.3V.

4.2.3 Configurarea modulelor XBee

După cum am prezentat și în partea introductivă a lucrării, într-o rețea ce funcționează cu ajutorul protocolului ZigBee, avem nevoie de un coordonator unic. Acesta este cel care impune folosirea unui anumit canal de transmisiune, stabilește adresele în cadrul rețelei și primește toate datele de la end device-uri și de la routere. În cadrul rețelei noastre, topologia aleasă va fi ”perece” (pair), urmând să configurăm unul dintre moduri în modul Coordonator AT, iar cel de-al doilea în modul Endpoint AT.

În procesul de configurare a modulelor trebuie să ne asigurăm că setăm în mod corespunzător adresele destinație ale cadrelor (putem specifica adresele finale în acest scenariu întrucât avem o topologie de tip ”pereche” ).

Pentru conexiunea între calculator și modulele XBee am folosit Tera Term – un client ce citește și afișează informațiile de pe un port serial într-o interfață ușor de citit.

Configurarea coordonatorului

Configurarea endpointului

4.2.4 Configurarea modulelor Arduino

Prezentăm în continuare secvențele de cod ce trebuie uploadate pe plăcuțele Arduino Uno pentru a se îndeplini funcționalitatea propusă în cadrul scenariului. În cadrul codului au fost inserate comentarii pentru a se explica ce se dorește implementat cu fiecare element în parte.

Configurarea coordonatorului

const int potPin1 = A0;

int valoarePotentiometru1;

void setup() {

Serial.begin(9600);

}

void loop() {

//Se citesc valoarile de la porturile analogice si se stocheaza in variabile corespunzatoare

valoarePotentiometru1 = analogRead(A0);

//Mapam valoarile citite de la potentiometru la o valoare de tensiune PWM

valoarePotentiometru1 = map (valoarePotentiometru1, 0, 1023, 0, 255);

//Trimitem mesajul

Serial.print('<'); //Simbol de start pentru transmisiune

Serial.print(valoarePotentiometru1);//Valoarea citita va avea valori intre 0 si 255

delay(10);

Serial.println('>');//Simbol pentru sfarsitul transmisiunii

}

Configurarea endpointului

const int ledRosu = 3; //Vom lega led-urile la pini de tip PWM (Pulse-Wide-Modulation)

//Variables

bool transmisiuneInceputa= false; //Adevarat daca mesajul a fost inceput

bool transmisiuneIncheiata = false;//Adevarat daca mesajul este incheiat

char byteCurent ;

char mesaj[3];

byte index;

void setup() {

pinMode(ledRosu, OUTPUT);

Serial.begin(9600);

}

void loop() {

while (Serial.available()>0){

//Se citeste byte-ul primit

byteCurent = Serial.read();

//Mesajul incepe cu simbolul '<'

if(byteCurent == '<')

{

transmisiuneInceputa = true;

index = 0;

mesaj[index] = '\0'; // Se arunca orice pachete incomplete – punem null in locul lor

}

//Mesajul se termina cu simbolul '>'

else if(byteCurent == '>')

{

transmisiuneIncheiata = true;

break; //Iesirea din bucla dupa terminarea citirii

}

//Se citeste mesajul primit

else

{

if(index < 4) // Ne asiguram ca vectorul nu este plin

{

mesaj[index] = byteCurent; // Add caracterul in vector

index++;

mesaj[index] = '\0'; // Adaugam null la final

}

}

}

if(transmisiuneInceputa && transmisiuneIncheiata)

{

int valoareLedRosu = atoi(mesaj);

analogWrite(ledRosu, valoareLedRosu);

//Serial.println(value); //Folosit pentru depanare

index = 0;

mesaj[index] = '\0';

transmisiuneInceputa = false;

transmisiuneIncheiata = false;

}

}

4.2 Aprinderea automată a sistemului de iluminat

În cadrul acestui proiect ne propunem să automatizăm procesul de aprindere a sistemului de iluminare, cu ajutorul unui senzor, reprezentat de către un fotorezistor. Mai exact, unul dintre modulele XBee va achiziționa în mod direct (fără o placă de dezvoltare Arduino) informații legate de luminozitatea dintr-un anumit punct – relevant ar fi de lângă un geam, pentru a fi monitorizată luminozitatea de afară, în timp ce un alt modul XBee se va ocupa de aprinderea sistemului, prin intermediul unei plăcuțe Arduino.

În cadrul proiectului vom folosi aproximativ aceleași componente ca în cadrului celui de mai sus, cu excepția faptului că vom elimina necesitatea uneia dintre plăcuțele Arduino și a potențiometrului, dar vom folosi în schimb un fotorezistor pentru măsurarea luminozității.

4.2.1 XBee Direct

Orice modul radio XBee este dotat cu capabilitatea de a colecta informații de la un număr de senzori și a transmite aceste informații în cadrul unei rețele, fără a se utiliza un microcontroler suplimentar. Pe lângă această funcționalitate, XBee mai oferă simple funcționalități de generare a semnalelor, pentru activarea diverșilor acuatori – de exemplu se pot transmite informații prin intermediul unui astfel de modul radio pentru a putea controla un motor, un sistem de iluminat sau alte lucruri asemănătoare – această funcție se regăsește în literatura de specialitate cu titlul de XBee Direct.

Există un număr de avantaje ce vin la pachet cu folosirea acestui concept – cele ce merita specificate sunt reprezentate de reducerea dimensiunii proiectului și a greutății (lucruri care sunt relevante pentru proiectele specifice Internet of Things). Pe lângă acestea, cel mai important avantaj este consumul de energie care este redus în mod semnificativ, prin eliminarea microcontrolerului. Alimentarea necesară unui modul radio XBee este de doar 3.3V, iar amperajul are valori semnificativ mai mici decât o placă Arduino, de exemplu.

Totuși, există și dezavantaje prezentate, cum ar numărul limitat de pini – pentru un microcontroler putem cu ușurință să adăugăm pini suplimentari sau să înlocuim microcontrolerul cu totul, în timp ce XBee se prezintă cu această limitare. Modulele din Series 2 nu au pini de ieșire analogici, ceea ce înseamnă că nu vom putea în niciun moment să aprindem un LED la valori intermediare, în mod asemănător proiectului de mai sus. Pe scurt, nu se pot lua decizii independente cu ajutorul acestor plăcuțe, ci doar să se transmită datele achiziționate sau cel mult să se schimbe starea unui pin.

XBee Series 2 vin încorporate cu un număr de 10 pini ce oferă o flexibilitate relativă proiectelor în care sunt folosite. Aceștia pot fi configurați atât ca și intrări digitale pentru a putea urmări activitatea unui buton sau a unui întrerupător, dar și ca ieșiri digitale pentru aprinderea unui LED sau controlului direct al unui motor.

În scenariile în care este necesar să se folosească surse de curent alternativ, se pot adăuga pinilor cu ieșiri digitale relee care să controleze instalații ce necesită alimentare mai mare. Primii patru pini din cei pe care îi avem la dispoziție pot fi configurați pentru a citi date de tip analogic – cum ar fi datele generate de către senzorii de luminozitate, temperatură, forța, accelerare, umiditate, gaz etc. Nu avem la dispoziție pini de ieșire analogică, pentru a putea configura o ieșire de tip PWM în vederea controlării directe a unui motor sau a unui altfel de sistem asemănător, dar un firmware corespunzător acestei funcționalități va fi lansat în curând.

4.2.2 Schema electrică a proiectului

Senzorul de lumină va fi conectat la primul pinul analogic al modulului XBee, ce va fi configurat în mod analogic de intrare. Conectăm fotorezistorul în mod indirect la alimentare, folosind o rezistență de valoare dublă a acestuia (în cazul nostru, 20k – vom folosi de fapt două rezistențe înseriate). Folosim această măsură pentru a modera valoarea generată de către senzor, în vederea prelucrării la destinație.

Alimentarea se va face, pentru senzor, cu ajutorul unor baterii. În cadrul proiectului ne-am propus înlocuirea acestor baterii cu panouri fotovoltaice care să furnizeze energia necesară alimentării modulului XBee.

Sistemul de iluminat va fi în continuare conectat la o placă de dezvoltare Arduino, datorită motivelor prezentate în subcapitolul anterior. În acest caz, alimentarea microcontrolerului se poate face într-un mod diferit (nu direct de la calculator printr-un cablu serial), pentru a oferi mobilitate sistemului de iluminare, iar în locul unui LED pot fi conectate benzi de LED-uri ce pot fi alimentate cu ajutorul unui releu.

Se poate observa că cele două scheme sunt în continuare destul de simplu de configurat.

4.2.3 Configurarea modulelor XBee

Configurarea senzorului de luminozitate

În cadrul acestui scenariu, modulul XBee conectat la senzorul de luminozitate va fi configurat ca și router, fiind responsabil cu trimiterea mesajelor către coordonator. Îi vom configura cele două părți ale adresei destinație, DH/DL cu cele două părți corespunzătoare ale nodului coordonator. În felul acesta, toate mesajele vor fi direcționate către acesta.

Vom configura de asemenea pinul 0 în mod analogic de achiziție a datelor și vom seta frecvența de achiziție la 100ms (în hexazecimal – 0x64) – echivalent cu 10Hz.

Comanda ATIR64 este cea cu care am setat frecvența de eșantionare, ATD02 este cea cu care am setat pinul 0 în mod analogic, iar cu ajutorul comenzii ATJVR1 ne-am asigurat că nodul va încerca reconectarea la coordonator în cazul în care, pentru o perioada de timp, se pierde legătura dintre cei doi.

Configurarea sistemului de iluminat

În acest scenariu, baza – respectiv sistemul de iluminat de sine stătător, va fi configurat în mod API. Acest lucru înseamnă că nu vom mai putea seta informațiile asemănătoare celor de mai sus cu ajutorul unui terminal prin care să trimitem comenzi seriale, ci vom folosi direct programul XCTU pentru a transmite toate informațiile relevante.

În acest caz, configurările trebui să includă selectarea aceluiași PAN ID ca și routerul (2001 în cazul nostru) și configurarea adreselor destinație. Ultimul lucru nu este obligatoriu, întrucât în scenariul curent, coordonatorul nu trebuie decât să primească mesaje, nu să și trimită.

4.2.4 Configurarea modului Arduino

În cadrul acestui proiect am folosit un singur modul Arduino, cel responsabil cu aprinderea sistemului de iluminare.

int luminaAmbientala = 11;

int troubleShootLED = 13;

int valoareAnalogica = 0;

void setup() {

pinMode(luminaAmbientala,OUTPUT);

pinMode(troubleShootLED,OUTPUT);

Serial.begin(9600);

}

void loop() {

if (Serial.available() >= 21) {

// Cautam byte-ul care semnaleaza inceputul transmisiei

if (Serial.read() == 0x7E) {

Serial.println("Citesc ce trebuie");

//Pentru debug am folosit un LED ca sa confirmam primirea datelor

digitalWrite(troubleShootLED, HIGH);

delay(10);

digitalWrite(troubleShootLED, LOW);

//citim variabilele pe care nu le vom folosi in afara bufferului

for (int i = 0; i<18; i++) {

byte discard = Serial.read();

}

//memoram valorile de referinta

int valoareAMare = Serial.read();

int valoareAMica = Serial.read();

valoareAnalogica = valoareAMica + (valoareAMare * 256);

}

}

//in continuare mapam pe trei intervale aprinderea

//scrierile seriale sunt folosite doar pentru troubleshoot

if (valoareAnalogica > 0 && valoareAnalogica <= 350) {

digitalWrite(luminaAmbientala, LOW);

Serial.println("Citesc valoare foarte mare – lumina mica");

}

if (valoareAnalogica > 350 && valoareAnalogica <= 750) {

digitalWrite(luminaAmbientala, HIGH/2);

Serial.println("Citesc valoare mare – lumina la jumatatea intensitatii");

}

if (valoareAnalogica > 750 && valoareAnalogica <= 1023) {

digitalWrite(luminaAmbientala, HIGH);

Serial.println("Citesc valoare mica – lumina mare");

}

}

4.3 Concluzii

Am configurat cu succes două scenarii în care am integrat folosirea protocolului ZigBee – aprinderea sistemului de iluminat de la distanță, atât manual cât și automat în funcție de luminozitatea achiziționată de un senzor. În cadrul aplicării practice am observat că distanța la care nodurile radio pot comunica între ele este de aproximativ 20 de metri, distanță care este mai mult decât suficient pentru un mediu casnic de lucru, sau unul office.

Concluzionăm că această aplicație practică este utilă într-un număr foarte mare de locuri, iar protocolul prezentat de noi se pliază fără nicio problema într-un mediu în care există deja conexiuni wireless, cum ar fi Wi-Fi sau Bluetooth. Totuși, pentru viitor, ne propunem extinderea sistemului de iluminat, respectiv aprinderea unei benzi de LED-uri care să aibă puterea de iluminare într-o încăpere de dimensiuni mari.

Capitolul 5. Proiectarea unei sonerii wireless pentru un bloc de apartamente

Ne propunem în continuare să folosim modulele XBee împreună cu plăcuțele de dezvoltare Arduino pentru a ilustra un scenariu în care scopul principal este reducerea numărului de cabluri folosite. Dacă în cazul sistemului de iluminare ne propusesem și o mobilitate ridicată, în acest caz ne dorim să eliminăm numărul de fire trase prin pereții unei clădirii, păstrând în continuare funcționalitatea soneriei.

Ne vom folosi tot de protocolul ZigBee pentru a configura la intrarea în clădire un router care să achiziționeze date cu ajutorul unei plăcuțe Arduino, de la butoanele apăsate și în același timp să ofere un feedback vizual vizitatorului (cu ajutorul unei plăcuțe de LED-uri să se afișeze numărul apartamentului care a fost contactat). În cadrul clădirii vom configura un coordonator care să primească datele trimise de la intrare și împreună cu o altă placa Arduino Uno, să sune soneria corespunzătoare apartamentului pentru care a fost apăsat butonul.

Acest proiect a fost testat pentru 3 apartamente în cadrul unui imobil mic de înălțime, dar cu foarte mare ușurință poate să fie scalat și la un număr mai mare de apartamente, respectiv la un bloc de dimensiuni mai mari.

5.1 Schema electrică a proiectului

5.2 Configurarea modulelor XBee

5.3 Configurarea modulelor Arduino

Capitolul 6. Proiectarea unui sistem wireless de monitorizare a temperaturii

Figura 2-1 3

Figura 2-2 5

Figura 2-3 8

Figura 2-4 10

Figura 2-5 12

Figura 2-6 13

Figura 3-1 22

Figura 3-2 23

Figura 3-3 23

Figura 3-4 24

Figura 3-5 25

Figura 3-6 26

Figura 3-7 28

Figura 3-8 30

Figura 3-9 32

Figura 3-10 33

Figura 3-11 34

Figura 3-12 34

Figura 3-13 35

Figura 3-14 35

Figura 3-15 36