Memòria

Treball final de grau
Estudi:Grau en Enginyeria Electrònica Industrial i
Automàtica
Títol: Xarxa de sensors sense fils per a la millora de l’eficiència
energètica en edificis
Document: 1. Memòria
Alumne: Ivan Piñero Fuertes
Tutor: Carles Pous Sabadí
Departament: Enginyeria Elèctrica, Electrònica i Automàtica
Àrea: ESA
Convocatòria (mes/any): setembre/2015

Xarxa de sensors sense fils per a la millora de l’eficiència energètica en edificis Memòria
1
Índex
1 INTRODUCCIÓ ..............................................................................................................4
1.1 Antecedents.............................................................................................................4
1.2 Objecte....................................................................................................................5
1.3 Especificacions i abast ............................................................................................5
2 ESTAT ACTUAL.............................................................................................................6
2.1 Descripció de l’entorn ..............................................................................................6
3 WSN...............................................................................................................................7
3.1 Característiques generals........................................................................................8
3.2 Topologia.................................................................................................................9
3.3 Aplicacions ............................................................................................................ 12
3.4 Fabricants en el mercat ......................................................................................... 12
4 ESTUDI DE LES POSSIBILITATS................................................................................ 16
4.1 Estàndards de comunicació................................................................................... 16
4.1.1 Infrarojos ........................................................................................................ 16
4.1.2 Bluetooth ........................................................................................................ 17
4.1.3 Wifi ................................................................................................................. 17
4.1.4 Zigbee ............................................................................................................ 18
4.2 Plataforma de desenvolupament ........................................................................... 20
4.2.1 Característiques generals............................................................................... 21
4.2.2 Microcontorlador ATmega1281....................................................................... 25
4.2.3 Interrupcions................................................................................................... 26
4.2.4 Timers ............................................................................................................ 27
4.2.5 Mòduls XBee .................................................................................................. 28
5 ENTORN DE DESENVOLUPAMENT ........................................................................... 30
5.1 IDE per a Waspmote ............................................................................................. 30
5.2 Comunicació entre la placa Waspmote i el mòdul XBee ........................................ 32

2
5.2.1 Comunicació AT ............................................................................................. 33
5.2.2 Comunicació API............................................................................................ 33
6 SOLUCIÓ APLICADA................................................................................................... 35
6.1 Configuració mòduls XBee .................................................................................... 35
6.2 Waspmote ............................................................................................................. 40
6.2.1 Visualització de dades.................................................................................... 42
6.2.2 Format de les dades....................................................................................... 43
6.2.3 Estudi de consum........................................................................................... 44
6.3 LabVIEW ............................................................................................................... 45
6.3.1 Recepció i retenció de dades.......................................................................... 45
6.3.2 Lectura ........................................................................................................... 47
6.3.3 Tractament de la informació ........................................................................... 49
6.3.4 Connexió LabVIEW i MySQL.......................................................................... 51
6.3.5 Inserció a la base de dades............................................................................ 54
6.4 MySQL .................................................................................................................. 55
6.5 Apache 2.2 ............................................................................................................ 56
6.5.1 DNS Dinàmic.................................................................................................. 57
6.5.2 Seguretat........................................................................................................ 58
6.5.3 Configuració Router........................................................................................ 59
7 RESUM DEL PRESSUPOST........................................................................................ 61
8 CONCLUSIONS ........................................................................................................... 62
9 RELACIÓ DE DOCUMENTS ........................................................................................ 64
10 BIBLIOGRAFIA ......................................................................................................... 65
11 GLOSSARi................................................................................................................ 66

3
A CODI INFORMÀTIC ..................................................................................................... 67
A.1 CODI WASPMOTE............................................................................................... 67
A.2 CODI MySQL........................................................................................................ 74
A.3 CODI INSERCIÓ MySQL A SERVIDOR WEB....................................................... 75
A.4 CONFIGURACIÓ SEGURETAT APACHE............................................................. 77

4
1 INTRODUCCIÓ
1.1 Antecedents
Les WSN consisteixen en la distribució geogràfica de dispositius, autònoms, anomenats
Sensor Nodes instal·lats al voltant d’un fenomen objecte per monitoritzar-lo, amb capacitat de
realitzar mesures, emmagatzemar i comunicar sobre una xarxa connectada sense fils.
Aquesta tecnologia es cada cop més emprada a nivell d’estudi de l’eficiència energètica en
edificis i on les directives marcades per la Unió Europea per al 2020 estableixen que, tant
edificis nous, com edificis ja existents i que són objecte de renovacions importants, han
d’acomplir uns mínims en matèria d’eficiència energètica, considerant així una reducció de
costos produïts per desbaratament de l’energia.
La combinació de la gran varietat de sensors de baix cost, baix consum i petita grandària, junt
amb les tecnologies de transmissió sense fils donen lloc a les WSN capaces de processar
enormes quantitats de dades. Essent la comunicació sense fils un tipus de comunicació en la
que no s’utilitza cap medi físic per la propagació de les ones electromagnètiques de baixa
potència i una banda específica per transmetre entre dispositius.
Cada Sensor Node compta amb un dispositiu autònom format per un microcontrolador, una
bateria, un ràdio transceptor i un element sensor. La capacitat de processament dependrà del
tipus de microprocessador que s’utilitzi, la font d’alimentació limitarà la vida útil de la xarxa, la
comunicació es realitza mitjançant un transceptor que fa les funcions de transmissió i recepció
i per últim, l’element sensor s’encarregarà de recollir la informació d’interès.
Al grup eXiT de la UdG s’ha instal·lat una xarxa de sensors sense fils per a la captura de
dades ambientals, tals com temperatura o il·luminació, i de detecció de persones mitjançant
un sensor PIR a l’edifici P-4. Les dades recollides, juntament amb les de consum elèctric,
s’estudien per aconseguir els objectius marcats per la UE. Actualment, la xarxa està
composada per mòduls sense fils anomenats Wapsmotes i per un concentrador que recull les
dades de tots els sensors i les emmagatzema en una base de dades interna.
A nivell de tractament de les dades, aquestes nomes poden ser visualitzades dins de l’entorn
on es troben els dispositius, es a dir, a P-4.

5
1.2 Objecte
Una WSN consisteix en una xarxa de Sensor Nodes capaços d’obtenir informació del seu
entorn, processa-la localment, i comunicar-la a traves d’enllaços sense fils fins a un node
central de coordinació.
Sumat això a les directrius marcades per la UE en matèria d’eficiència energètica d’edificis
per al 2020, es fa necessària la creació d’aplicacions que facilitin la consecució d’aquests
objectius. A l’edifici P-4 de la UdG s’analitza la informació obtinguda de la WSN instaurada i
es procedeix
En aquest marc, l’objecte d’aquest projecte es dissenyar i implementar una xarxa WSN on es
millori el consum energètic de les bateries dels mòduls Waspmote i que la xarxa sigui
independent del concentrador (Meshlium) que hi ha actualment on es recullen les dades.
Els Waspmotes funcionen amb bateries, d’acord amb això es fa palesa la millora del consum
energètic d’aquestes fent que els dispositius prolonguin per més temps les seves funcions.
Actualment, la instal·lació a l’edifici P-4 recull les dades dels Waspmotes mitjançant un
concentrador/router (Meshlium) i les emmagatzema en una base de dades interna. Per això,
també es objecte d’aquest projecte la creació d’una base de dades, un servidor i una aplicació
WEB per poder consultar aquestes dades per Internet
1.3 Especificacions i abast
Per a la consecució d’aquests objectius serà necessari realitzar els algorismes dels
Waspmotes.
El Meshlium serà substituït per un Gateway connectat a un ordinador, on es recolliran les
dades de tots els sensors. Aquestes, seran introduïdes a una base de dades que ha de poder
ser consultada per internet mitjançant una aplicació WEB.

6
2 ESTAT ACTUAL
Un edifici energèticament eficient es aquell que minimitza l’ús de les energies convencionals,
principalment les no renovables, a fi d’estalviar i fer us racional de la mateixa.
La Directiva d’eficiència energètica en edificis es la principal norma europea dirigida a garantir-
ne el compliment en referència a emissió de gasos d’efecte hivernacle, de consum energètic
i la generació d’energia a partir de fonts renovables.
Per a la consecució d’aquests objectius en matèria d’eficiència energètica, la Directiva es
recolza sobre tres eines concretes: l’establiment de requisits de l’ús de l’energia en edificis
nous, y existents on es portin a terme grans renovacions; la introducció de certificats
d’eficiència energètica i les inspeccions de sistemes de climatització de relativa grandària i
mitjana. Derivant sobre les tres eines anteriorment anomenades, la Directiva introdueix un nou
concepte resultat de la implementació d’aquestes, edificis de consum energètic quasi nul.
Un edifici de consum energètic quasi nul es defineix com un immoble amb un nivell d’eficiència
energètica molt elevat. La quantitat d’energia convencional emprada per aquest es nul·la o
mínima, i ha d’estar cobert en àmplia mesura per energia procedent d’energies renovables ja
sigui produïdes in situ o a l’entorn.
Amb les premisses abans mencionades, es fa palesa la utilització d’una metodologia de càlcul
de l’eficiència energètica. En aquest sentit entren en joc les WSN, les quals son capaces de
recollir informació de l’entorn per posteriorment elaborar un estudi que permetrà assolir els
objectius marcats per la Directiva.
2.1 Descripció de l’entorn
Actualment, el grup eXiT de la UdG ha implementat una WSN per a la captura de dades
ambientals a l’edifici P-4. Aquestes dades juntament amb les de consum elèctric son
utilitzades per a l’estudi de l’eficiència energètica en edificis marcada per la UE per al 2020.
El sistema instal·lat disposa de diversos nodes que capten la informació de l’entorn i la
transmeten a un Meshlium o router central. Acte seguit s’ emmagatzema en una base de
dades interna.

7
3 WSN
Una WSN es un conjunt de nodes mòbils, connectats per enllaços sense fils anomenats nodes
o “motes” que no precisen d’una infraestructura fixa per operar. En un principi van ser ideades
per treballar en entorns hostils e irregulars, estan capacitades per canviar la seva topologia
per obtenir noves formes i mantenir la mateixa funcionalitat en la xarxa. Generalment l’
informació recollida es enviada a un element d’enllaç de la xarxa que actua com a pont,
traslladant l’ informació obtinguda a l’usuari.
En la figura 1 es pot veure un exemple de xarxes sense fils, que usualment consisteix en una
xarxa d’adquisició de dades i una xarxa de distribució de dades, en la que un centre de control
s’encarregarà de la seva monitorització i control.
Figura 1. Exemple Xarxes sense fils
El protocol de comunicació emprat per al present projecte es ZigBee, el qual es troba explicat
a l’apartat 4.1.4.

8
El protocol ZigBee conté els següents elements bàsics: Node sensor o End Device, Router i
Coordinador.
El Node sensor o End Device es l’element autònom capaç de recollir l’ informació que es vol
mesurar (temperatura, humitat, ...) i transmetre-la al medi per a que aquestes dades siguin
gestionades pel Coordinador. Consta d’un microcontrolador, una font d’alimentació
(normalment una bateria), un transceptor (transmissor/receptor) i un sensor.
El Router es el dispositiu que té la funció d’encaminar el paquets per la xarxa entre Nodes
sensors i Coordinador, es a dir, interconnecta dispositius separats en la topologia de la xarxa,
a més d’oferir un nivell d’aplicació per a l’execució de codi d’usuari, es a dir també pot
enregistrar i enviar dades. Cal esmentar que no poden “dormir” i sempre han d’estar pendents
per si hi ha paquets d’informació a dirigir.
El Coordinador es el responsable d’establir la xarxa, gestionar les comunicacions entre tots
els elements i enviar l’ informació obtinguda dels Nodes sensors a l’usuari.
Aquests elements es veuran representats seguint un tipus de topologia determinada, com es
veurà a l’apartat 3.2.
3.1 Característiques generals
Les xarxes de sensors posseeixen unes característiques pròpies, essent algunes d’elles
adaptacions de les xarxes Ad-Hoc. Aquest tipus de xarxa té la principal característica de poder
realitzar transmissions de paquets entre tots els dispositius, funció normalment associada a
routers, y que a més a més poden funcionar com a dispositius finals.
Les xarxes de sensors posseeixen una topologia dinàmica, ja que poden canviar amb facilitat
de forma, requisit molt important, així com la capacitat d’adaptació a una topologia en constant
canvi i poder comunicar les noves dades rebudes.
En una transmissió de dades pot haver-hi fenòmens indesitjables, el canal de ràdio es un
canal molt variable que pot estar exposat a freqüents variacions que poden perjudicar la
comunicació, com l’atenuació o les interferències que poden produir errors en les dades. Per
això, es important realitzar salts de freqüència per canviar d’un canal a un altre de forma
dinàmica segons es produeixi cap efecte no desitjat per preservar la fiabilitat de la xarxa. Es

9
important també que la xarxa tingui una tolerància a errors produïts per la caiguda d’un node,
de forma que sigui capaç de seguir funcionant tot i tenint errors en el seu propi sistema.
La distribució del tràfic de dades depèn del tipus de fenomen a controlar al qual sotmetem a
la xarxa. En cas de realitzar un seguiment d’un paràmetre ambiental, aquest generarà de
forma periòdica petits paquets de dades que indicaran l’estat del paràmetre objecte a una
estació central de monitorització, situació que requereix un ample de banda baix. Per un altre
banda, si es tracta d’una detecció d’intrusió en un camp de seguretat, es generarà un tràfic de
detecció d’ events amb limitacions en la transmissió a temps real.
El consum energètic es un paràmetre molt important a tenir en compte. Per aconseguir un
consum ajustat s’ha de tenir en consideració la col·locació dels nodes per al desenvolupament
del suport físic. Per això, es fonamental que el hardware sigui el més senzill possible, cosa
que limita la capacitat de procés. Tot i això, compaginar autonomia amb capacitat de procés
es possible, tenint en compte que les xarxes compten amb unitats d’energia limitada,
normalment una bateria per node, han d’estar proveïdes amb un processador i un transceptor
amb un consum molt baix a més d’un software que també combini aquesta característica
limitant encara més el seu consum.
3.2 Topologia
La topologia es basa en la configuració dels components del hardware i en com les dades son
transmeses a través d’aquesta.
La xarxa estrella, representada a la figura 2, es aquella xarxa on tots els End Devices es troben
connectats a un node central o Coordinador i on totes les comunicacions han de passar
necessàriament per aquest. Aquest tipus de xarxa es molt utilitzada a nivell local, on a més a
més, permet obtenir una sèrie d’avantatges entre els quals si un End Device deixa de funcionar
nomes aquest dispositiu queda fora d’aquesta. La pròpia estructura de la xarxa permet també
incorporar fàcilment nous dispositius i prevenir possibles danys o conflictes que es donin entre
els End Devices i Coordinador. Per altra banda, la gran desavantatge que presenta es que si
per qualsevol cas el Coordinador falla, tota la xarxa deixa de transmetre.

10
Figura 2. Xarxa Estrella
La topologia d’arbre indicada a la figura 3 es una variant de la xarxa tipus estrella. Els
dispositius enllaçats al Coordinador són Routers, sota dels quals s’hi connecten End Devices.
Per tant, una de les grans avantatges que ofereix aquesta topologia és l’ampliació del camp
d’actuació, es a dir, els dispositius poden cobrir més distàncies. Com a contrapartida, d’un
mateix node o Router poden penjar varis End Devices i si fos cas que qualsevol Router fallés,
aquest cauria amb tots els seus dispositius immediatament associats.
Figura 3. Xarxa Arbre
La xarxa Malla o “Mesh” mostrada a la figura 3 es un sistema multi-hop en la que tots els
nodes son idèntics, a demés de Routers. Cada node pot enviar i rebre informació d’un altre
node i de la porta d’enllaç. Una diferència respecte la topologia d’estrella es que en aquesta
els nodes poden enviar missatges entre ells, mentre que en estrella els nodes només poden
comunicar-se amb la porta d’enllaç.

11
Figura 4. Xarxa Malla o Mesh
La topologia híbrida de la figura 5 busca combinar les avantatges que ofereix la topologia
estrella en qüestió de baix consum i simplicitat, i la capacitat de cobrir una gran quantitat de
terreny i reorganitzar-se davant de falles de la topologia Malla. La idea es la creació d’una
xarxa en estrella al voltant de Routers que pertanyen a una xarxa en Malla, la qual cosa permet
ampliar la xarxa i corregir errors en aquests nodes. Els Nodes Sensors es connecten amb els
Routers propers aconseguint un estalvi d’energia.
Figura 5. Xarxa híbrida

12
3.3 Aplicacions
Dins del camp de la monitorització actualment existeixen una gran quantitat de WSN
implementades en diferents sectors, i la previsió en un futur pròxim es que la seva utilització
creixi encara més. A continuació es detallen algunes d’elles com les Smart cities i les
utilitzades en el sector agrícola.
El sector agrícola desenvolupa una activitat alimentària tot abastint a la població d’aliments
necessaris per a la seva supervivència, aquests aliments necessiten d’atenció constant. Les
WSN instal·lades sobre una producció agrícola poden registrar de mode simultani diversos
paràmetres en diferents llocs per realitzar models precisos sobre el medi. Els sensors sense
fils permeten disposar de cents de dispositius preparats per prendre dades d’una forma no
invasiva i a un baix cost, garantint exactitud i veracitat de les dades subministrades de forma
continua i a temps real.
Les Smart cities o ciutat intel·ligent es refereix a un tipus de desenvolupament urbà basat en
la sostenibilitat. Els nodes sensors poden ser utilitzats per monitoritzar dades com la qualitat
de l’aire tot controlant e informant sobre indicis de contaminació mediambiental, o en qüestió
de mobilitat indicant estacionaments lliures. Com ja s’ha comentat anteriorment, la
monitorització de l’entorn es una de les primeres aplicacions de les WSN i, en aquest sentit,
s’ha de tenir en consideració en aquestes aplicacions el temps de vida dels sensors i la
sincronització entre nodes sensors, per a que els esmentats sensors durin un determinat
període de temps i proporcionin els valors precisant l’instant de la mesura per realitzar un
historial de mesures significatiu.
3.4 Fabricants en el mercat
En quant a la fabricació de nodes sensors es pot trobar un mercat molt divers. Alguns dels
seus fabricants son Crossbow, Arduino, Beaglebone i Libelium.
Crossbow es una empresa orientada al desenvolupament de plataformes hardware i software
especialitzada en el mon dels sensors, en especial el de les xarxes sense fils. Entre els seus
productes es troben el nodes sensors MICA, que funcionen amb un sistema operatiu TinyOS,
MICA2 (868/916 MHz), MICAz (2.4 GHz) e IMOTE2, dissenyat per Intel. En la figura 6 es
poden veure les parts d’un sensor MICAz i de la placa de sensors, enfocades a la mesura de
paràmetres ambientals.

13
Figura 6. Node MICAz i placa MTS420
Arduino es una plataforma de hardware lliure per a la creació de prototips basada en una placa
amb un microcontrolador i un entorn de desenvolupament flexible i de fàcil utilització, essent
una de les més utilitzades pels usuaris. Aquesta tecnologia pot ser combinada amb Zigbee de
tal forma que la placa es capaç de comunicar-se en una xarxa sense fils amb altres nodes
formant una xarxa de sensors, proporcionant un sistema de xarxa simple, fiable i flexible ja
que atorga la capacitat d’ampliar la xarxa si es desitja. Una de les causes del seu èxit comercial
es el seu espectre de possibilitats de desenvolupament, des de petites joguines robòtiques,
passant per implementacions de monitorització ambiental, aplicacions mèdiques, elements
musicals, etc. Com a contrapartida, no pot accedir a un mode de somni profund, per tant la
autonomia de xarxa pot quedar reduïda. La figura 7 mostra una placa Arduino UNO.
Figura 7. Placa Arduino UNO

14
La figura 8 mostra una placa Beaglebone, aquesta es una plataforma dissenyada per
funcionar a un nivell més alt i amb major capacitat que Arduino. Un exemple d’això son els
seus convertidors analògics/digitals de gran resolució, útil per aplicacions de certa exigència.
Pot ser executada per Linux o Android.
Figura 8. Placa Beaglebone
Libelium es una empresa de disseny i fabricació de hardware per a la implementació de xarxes
sensorials sense fils, xarxes en malla i protocols de comunicació per a tot tipus de xarxes
sense fils distribuïdes. Alguns dels seus productes son Meshlium i Waspmote.
Meshlium es un Router únic que integra en un element les tecnologies Wifimesh (2.4 GHz – 5
GHz), Zigbee, GPRS, GPS i Bluetooth. Es un sistema capaç de detectar el dispositiu encara
que no estigui connectat a la xarxa sense fils. Per altra banda, Waspmote es un dispositiu de
baix consum per al disseny de xarxes sensorials sense fils complint amb uns requeriments
bastant específics, la funció del qual es ser desplegat en un escenari real, indispensable en
un estudi de condicions mediambientals. La següent figura 9 mostra una placa Waspmote.

15
Figura 9. Placa Waspmote
La plataforma escollida per al desenvolupament del present projecte es Waspmote, ja que
Waspmote permet entrar en modes de funcionament de molt baix consum, capacitat que les
altres plataformes no tenen. A més a més, disposa de gran versatilitat de components
(plaques, sensors, etc.). Un punt interessant es l’entorn de programació del seu compilador,
ja que es molt similar a Arduino, motiu per el qual facilita la tasca a aquells usuaris que no
hagin utilitzat mai Waspmote i hagin treballat amb Arduino.

16
4 ESTUDI DE LES POSSIBILITATS
Les xarxes sense fils treballen amb uns determinats estàndards de comunicació els quals
tenen unes certes característiques que cal tenir en consideració a l’hora d’escollir una
determinada xarxa sensorial.
4.1 Estàndards de comunicació
Les transmissions sense fils son una eina eficaç que permet la transferència de dades sense
necessitat de cablejat. Aquesta transferència d’informació s’aconsegueix a través de l’emissió
d’ones de ràdio obtenint dues grans avantatges, mobilitat i flexibilitat del sistema en general.
El seu principal actiu es el seu baix cost i la capacitat per ser distribuïdes en grans quantitats.
Degut entre altres coses al gran espectre d’actuació, es interessant estandarditzar alguns dels
elements de les xarxes sensorials per facilitar l’operació entre productes de diferents
fabricants. Realment, avui dia, no existeix cap estàndard que els englobi a tots, en primer lloc
perquè les tecnologies es troben sempre en constant canvi, i també per la enorme amplitud
de les aplicacions de les xarxes sensorials.
4.1.1 Infrarojos
Els infrarojos son ones electromagnètiques que es propaguen en línia recta que poden ser
interrompudes per cossos opacs. La seva utilització no precisa de llicències administratives i
no es veu afectat per interferències radioelèctriques externes, podent arribar a distàncies de
fins a 200 metres entre emissor i receptor.
El principi de funcionament es basa en un transmissor que envia un que envia un feix de llum
infraroja cap a un receptor. La transmissió de llum es codifica en l’enviament i es descodifica
en la recepció sobre un protocol de xarxa existent. Aquest tipus de comunicació es útil, per
exemple, per enviar dades a un robot des de un sensor, establir i detectar balises en un entorn,
o per a que una persona canviï de canal utilitzant un aparell convencional de control remot.

17
4.1.2 Bluetooth
Bluetooth es el nom comú de l’especificació industrial IEE 802.15.1, que defineix l’estàndard
global de comunicació sense fils que possibilita la transmissió de veu i dades entre diferents
dispositius mitjançant un enllaç per radiofreqüència segura de curt abast, globalment i sense
llicència.
Els principals objectius que es pretenen aconseguir amb aquesta norma son: facilitar les
comunicacions entre equips mòbils i fixos, eliminar cables i connectors entre aquests i oferir
la possibilitat de la creació de petites xarxes sense fils, a més de facilitar la sincronització de
dades entre equips personals.
L’Especificació de Bluetooth defineix un canal de comunicació d’un màxim de 720 Kb/seg amb
un abast òptim de 10 metres.
El rang de freqüències de ràdio amb les que treballa es de 2.4 GHz a 2.48 GHz amb un ampli
espectre i salts de freqüència amb possibilitat de transmetre en Full Duplex amb un màxim de
1600 salts/seg. Els salts de freqüència es donen entre un total de 79 freqüències amb intervals
de 1 MHz; això permet donar seguretat i robustesa.
La potència de sortida per transmetre a una distància màxima de 10 metres es de 0dBm
(1mW), mentre que la versió de llarg abast transmet entre -30 i 20 dBm (100mW).
4.1.3 Wifi
WiFi o WLAN es un conjunt d’estàndards per xarxes sense fils basats en especificacions
IEEE.802.11. Aquesta xarxa requereix l’activitat quasi ininterrompuda dels dispositius
associats a aquesta. El gran avantatge d’aquest estàndard es la enorme quantitat de dades
que es poden transmetre d’un punt a multipunts, però la seva corrent de transmissió es
elevada.
Funciona a una freqüència de 2.4 GHz, de la mateixa forma que el Bluetooth, tot i així, en la
versió 1.2 i majors de l’estàndard Bluetooth s’ha actualitzat la seva especificació per a que no
hi hagi interferències en la utilització simultània d’ambdues tecnologies.

18
Aquest tipus de sistemes requereixen de 0.6 Watts de potència. La màxima potència del
senyal que es transmet pot ser superior a 20 dBm.
Un del problemes més greus als quals s’ha d’enfrontar actualment la tecnologia WiFi es la
seguretat. Un elevat percentatge de xarxes son instal·lades per administradors de sistemes i
xarxes per la seva simplicitat d’implementació sense tenir en consideració la seguretat i, per
tant, convertint les xarxes en xarxes obertes, sense protegir la informació que per elles circula.
4.1.4 Zigbee
ZigBee es el nom de l’especificació d’un conjunt de protocols d’alt nivell de comunicació sense
fils per a la utilització en radiodifusió digital de baix consum, basat en l’estàndard IEEE
802.15.4 de xarxes WPAN.
ZigBee esta dissenyat per operacions amb baixa potència. Un dispositiu ZigBee pot deixarse
en standby per un període de temps prolongat sense necessitat de tornar a carregar la bateria
d’aquest. Això elimina la necessitat de l’operador de recarregar la bateria freqüentment.
ZigBee es similar al Bluetooth però amb algunes diferències, com oferir un major abast, menor
consum elèctric i menor velocitat de transferència. Es troba dissenyat per donar servei a
dispositius amb baixa taxa de transmissió de dades.
En quant a les comunicacions, ZigBee realitza les comunicacions sobre la banda de 2.4 GHz.
A diferència del Bluetooth no utilitza FHSS (Frequency hooping), sinó que realitza les
comunicacions a través d’una única freqüència, es a dir, un canal.
L’Abast depèn de la potència d’emissió del dispositiu així com el tipus d’antenes emprades
(ceràmiques, dipols, etc.). L’abast normal d’una antena amb dipol en visió directa sol ser
aproximadament (prenent com a exemple el cas MaxStream, en la versió d’ 1mW) de 100
metres i en interiors de 30.
La màxima velocitat de transmissió de dades d’una xarxa ZigBee es de fins a 256 Kbps i el
seu consum es d’aproximadament uns 120 mW.

19
Per últim dir que una xarxa Zigbee pot ser formada, teòricament, fins a 65535 equips, es a dir,
el protocol esta preparat per poder controlar dins de la mateixa xarxa aquesta quantitat enorme
de dispositius. Sobre la realitat es menor, essent de totes formes, de milers d’equips..
Un cop analitzats els detalls principals dels estàndards WiFi, Bluetooth i ZigBee, s’ha realitzat
un quadre resum, recollit a la Taula 1, on es poden veure més detalladament les
característiques de cada sistema.
COMPARATIVA PRINCIPALS ESTÀNDARDS DE COMUNICACIÓ
Protocol de
comunicació
ZigBee Bluetooth WiFi
Freqüència
d'operació
868 MHz, 902-928 MHz, 2,4 GHz 2,4GHz
2,4 GHz i 5,8
GHz
Taxa de dades 250 Kbps 1 Mbps Fins a 54 Mbps
Consum de
transmissió
TX 35 mA TX 40 mA TX > 400 mA
Consum en repòs Standby 3 µA Standby 200 µA Standby 20 mA
Aplicacions
Il·luminació, sensors, control
remot..
Telecomunicaci
ons, àudio…
Internet..
Xarxes suportades
Xarxa en malla, punt a punt o
punt a multipunt
Punt a multipunt
Punt a
multipunt
Taula 1. Diferències entre ZigBee, Bluetooth i WiFi
Entre totes les possibilitats al nostre abast, per escollir el tipus de tecnologia sense fils que
s’adapti a les nostres necessitats ens hem fixat en uns determinats paràmetres de cada
estàndard com son: el consum, freqüència de treball i el protocol de comunicació.
Després d’aquest anàlisi, s’ha decidit utilitzar la tecnologia ZigBee mitjançant l’ús de mòduls
XBee per diversos motius. Aquests motius son la creació de xarxes sensorials, tenen una taxa
de transferència baixa en Kbs, un consum reduït i el seu funcionament es per radiofreqüència
a 2.4 GHz. A més a més, té un abast considerable d’entre 100 metres a camp obert i de 30
metres amb parets dins d’un edifici, es poden unir xarxes, i per al seu ús només es necessari
un ordinador, el cable de comunicació amb aquest i l’alimentació del mòdul al que vagi unit
l’emissor.
Cal esmentar, que aquests mòduls utilitzen un software gratuït anomenat X-CTU, que permet
configurar els paràmetres del mòdul i es com un hyperterminal.

20
4.2 Plataforma de desenvolupament
La placa Waspmote v1.1 es una plataforma de codi obert que s’encarrega de recollir la
informació sol·licitada processar-la i enviar-la. La seva principal qualitat es proporcionar un
consum mínim amb el màxim rendiment i capacitats. Waspmote compta amb un consum de
0.7 μA en el mode hibernació i set models diferents de ràdios de comunicació que poden ser
escollits en funció de freqüència (2.4 GHz, 900 MHz, 868 MHz), protocol (802.15.4, ZigBee) i
potència (1mW,100mW).
L’alta sensibilitat en recepció (RX) i la potència de transmissió (TX) permeten que, a 2.4 GHz
puguin cobrir una extensió aproximada de 7 Km, per 900 MHz una distància de 24 Km i amb
868 MHz 40 Km. Això ens permetrà monitoritzar quasi qualsevol lloc. La plataforma esta
basada en una arquitectura modular, això significa que podem implementar mòduls
addicionals en funció de les nostres necessitats, com mòduls GPS o targes SD. Aquesta
filosofia modular permet la connexió al Waspmote de diverses plaques de sensors de gasos
(CO,CO2, SH2, NH3, ...), pes, lluminositat, etapes d’amplificació, i les ja esmentades com el
sector agrícola i les Smart Cities. Altra funció que porta incorporada es l’acceleròmetre de tres
eixos útil per obtenir la màxima precisió i estabilitat i controlar en temps real qualsevol tipus
de moviment o vibració.
Waspmote s’alimenta amb una bateria de liti que pot recarregar-se a través d’un connector
preparat per panells solars. Aquesta opció es especialment interessant per desplegaments en
entorns naturals com boscos e inclòs ciutats.
Per treballar amb la plataforma, es disposa d’un entorn de programació, el IDE de Waspmote,
de codi obert. La taula 2 mostra les especificacions de la placa.
Microcontrolador Atmega 1281
Freqüència 8 MHz
SRAM 8 KB
EEPROM 4 KB
FLASH 128 KB
Tarja SD 2 GB
Pes 20 gr
Dimensions 73,5 x 51 x 13 mm
Rang de Temperatura [-20 ºC, + 65 ºC]
Taula 2. Especificacions Waspmote

21
4.2.1 Característiques generals
A continuació abordarem algunes de les característiques més específiques que conté aquesta
placa.
L’estructura de Waspmote en relació a totes les funcions que posseeix es senzilla, tal i com
es mostra en la figura 10.
Figura 10. Diagrama de blocs i senyals de Waspmote

22
Waspmote pot comunicar-se amb altres dispositius externs a través dels seus ports entrada /
sortida tal i com mostra la figura 11.
Figura 11. Connectors E/S
En la figura 12 es poden veure els tres ports principals amb els identificadors corresponents:
Figura 12. Descripció dels pins d’E/S
Waspmote te 7 entrades analògiques accessibles per a la connexió de sensors. Cada entrada
es troba directament connectada al microcontrolador, que utilitza un convertidors analògic /
digital (ADC) d’aproximacions successives de 10 bits. La tensió de referència en les entrades
es de 0V (GND), i el valor màxim de tensió d’entrada es de 3.3V, que es correspon a la tensió
general d’alimentació del microcontrolador.

23
Per a l’obtenció dels valors d’entrada s’utilitza la funció analogRead(entrada analògica), el
paràmetre d’entrada de la funció serà el nom de l’entrada que serà llegida (ANALOG1,
ANALOG2, ..). El valor obtingut d’aquesta instrucció serà un nombre enter entre 0 i 1023, on
0 correspon a 0V i 1023 a 3.3V.
Els pins d’entrada analògica també poden ser utilitzats com pins d’entrada / sortida digitals.
En aquest cas, cal tenir en compte la figura 13 mostra la correspondència per al nom dels
pins:
Figura 13. Correspondència pins analògics a E/S digitals
Els pins digitals poden ser configurats com entrades o sortides en funció de les necessitats de
l’aplicació. Els valors de tensió corresponents als diferents valors digitals son 0V per un 0 lògic
i 3.3V per a un 1 lògic.
El pin DIGITAL1 també es pot utilitzar com a sortida PWM (modulació per ample de banda)
amb la que la senyal analògica pot ser “simulada”. Val a dir, que es tracta d’una ona quadrada
entre 0V i 3.3V per a la qual la proporció de temps quan la senyal es alta pot canviar de 0% a
100%, es a dir el cicle de treball. Posseeix una resolució de 8 bits podent configurar fins a 255
valors entre 0 i 100%.
Waspmote posseeix sis ports sèrie: una UART del microcontrolador es troba connectada
simultàniament amb el mòdul de comunicació XBee i el port USB. L’altre UART del
microcontrolador esta connectada a un multiplexor de quatre canals on es possible per codi
de programació seleccionar quin d’ells es requereix. Aquestes 4 noves UARTs estan
connectades de la següent forma: Una d’elles esta connectada amb la placa 3G/GPRS, una
altra amb el GPS i les altres dos son accessibles a l’usuari en el connector I2C – UART.

24
El bus de comunicació I2C també s’utilitza en Waspmote, on tres dispositius es troben
connectats en paral·lel: l’acceleròmetre, la RTC i el potenciòmetre digital que configura el nivell
d’alarma de bateria baixa. En tots els casos, el microcontrolador actua com a master (mestre),
mentre que els altres dispositius del bus son slaves (esclaus).
El port SPI del microcontrolador comunica amb la tarja micro SD. Totes les operacions que
utilitzen el bus son realitzades per la biblioteca específica.
El port USB s’utilitza per a la comunicació amb un ordinador. Aquesta comunicació permet la
càrrega del programa al microcontrolador. Per a la comunicació USB s’utilitza la UART0, on
el chip FT232RL porta a terme la conversió a l’estàndard USB.
La placa conté cinc indicadors LED: Indicador de càrrega de bateria, indicador LED USB,
indicador LED RSSI, LED0 i LED1. L’indicador de bateria te associat un LED vermell que
indica que hi ha una bateria connectada a Waspmote que s’està carregant. Un cop la bateria
es troba completament carregada, el LED s’apaga automàticament. L’indicador LED USB es
troba encès quan Waspmote detecta un cable USB connectat correctament, al retirar aquest
automàticament el LED corresponent s’apaga. Els indicadors de RSSI son tres LED els quals
mostren el valor de la trama Zigbee. Aquests LEDS han sigut incorporats per mesurar la
qualitat del senyal de l’últim paquet rebut. Per últim, els LED0 i LED1, representats per el color
verd i vermell respectivament, poden ser programats per l’usuari a nivell de codi de
programació, a més a més, el LED0 indica el reset de Waspmote en cas d’haver-hi.

25
En la figura 14 es pot veure els principals components de la placa amb els seus respectius
identificadors.
Figura 14. Part superior del Waspmote v1.1
4.2.2 Microcontorlador ATmega1281
El ATmega1281 es un microcontrolador de baix consum amb tecnologia CMOS de 8 bits basat
en l’arquitectura RISC millorada de AVR. Mitjançant l’execució de potents instruccions en un
sol cicle de rellotge, el ATmega1281 aconsegueix rendiments propers a 1MIPS per MHz,
permetent optimitzar el consum d’energia en comparació amb la velocitat de processament.
A continuació, a la taula 3 les característiques genèriques del ATmega1281.
Dispositiu ATmega1281
FLASH 128 KB
EEPROM 4KB
RAM 8KB
Pins E/S propòsit general 54
Canals PWM resolució 16 bits 6
Ports USART serie 2 2
Canals ADC 8
Taula 3. Característiques microcontrolador ATmega1281

26
Per maximitzar les prestacions, el AVR esta dotat d’arquitectura Harvard (amb busos i
memòries separades per programes i dades). Mentre que s’executa una instrucció, es realitza
la fase de cerca en memòria de la següent. Aquest concepte permet que s’executi una
instrucció en cada cicle de rellotge, tal i com mostra la figura 15.
Figura 15. Diagrama de blocs del microcontrolador AVR
4.2.3 Interrupcions
Les interrupcions son senyals rebudes pel microcontrolador que indiquen que ha de deixar
una tasca que esta executant en aquell instant per assistir a un event que acaba d’ocórrer. El
control de les interrupcions allibera al microprocessador d’haver d’ocupar-se de vigilar els
sensors tot el temps. També fa que els sensors adverteixin a Waspmote quan alguna variable
arriba a un cert llindar.
Les interrupcions poden ser de dos tipus: síncrones i asíncrones. Les interrupcions síncrones
es programen a través de timers, i permeten establir la seva activació segons l’usuari desitgi.
En canvi, les interrupcions asíncrones son aquelles que no es troben programades, per la qual
no se sap quan seran activades, alguns exemples poden ser l’activació d’un sensor al arribar
a un cert llindar, bateria baixa o l’acceleròmetre si cau des de un determinat lloc.

27
El diagrama de funcionament amb les seves diverses interrupcions pot veure’s en la figura 16.
Figura 16. Diagrama de modes de funcionament
4.2.4 Timers
Tal i com s’ha esmentat a l’apartat 3.2.3 les interrupcions síncrones poden ser programades,
tals com alarmes i modes de baix consum, això s’aconsegueix a través de timers. Waspmote
incorpora dos tipus WDT i RTC.
El microcontrolador ATmega1281 incorpora un WDT. El WDT compta de forma precisa els
cicles de rellotge generats per l’oscil·lador de 128 KHz, d’aquesta manera el microcontrolador
pot despertar d’un mode “Sleep” i generar la interrupció. Donat la seva precisió WDT només
pot establir petits instants de temps: 16ms, 32ms, 64ms, 128ms, 256ms, 500ms, 1s, 2s, 4s i
8s. Per intervals superiors a aquests cal utilitzar RTC la qual permet modes més profunds de
somni “Deep Sleep” i “Hibernate”.
Waspmote integra una RTC a 32 KHz permetent una base de temps absoluta per ser
configurada. Les alarmes poden programar-se especificant dia/hora/minuts/segons donant
com a resultat un control total sobre el temps que es trigarà a despertar i executar les
instruccions necessàries. La RTC es una eina molt útil per fer que un node sensor romangui
adormit estalviant energia i aixecar-se en el moment requerit.

28
En la taula 4 es pot veure de forma sintetitzada els diferents modes de treball sota els timers
mencionats.
Consum Micro Cicle Interrupcions acceptades
ON 9 mA ON - Síncrones i asíncrones
Sleep 62 uA ON 32 ms - 8s Síncrones (Watchdog) i asíncrones
Deep Sleep 62 uA ON 8s-min/hores/ dies Síncrones (RTC) i asíncrones
Hibernate 0,7 uA OFF 8s-min/hores/ dies Síncrones (RTC)
Taula 4. Modes d’operació del Waspmote
4.2.5 Mòduls XBee
Els mòduls XBee son transceptors de radiofreqüència que treballen amb protocol de
comunicació IEEE 802.15.4. Aquest protocol defineix la capa física i el nivell d’enllaç o capa
MAC, tal i com mostra la figura 17.
Figura 17. Model OSI i model Zigbee

29
A les operacions aportades pel protocol de comunicació, a XBee se li afegeixen certes
funcionalitats com el descobriment de nodes i la detecció de paquets duplicats. El
descobriment de nodes es realitza afegint als capçals dels paquets certa informació de forma
que els altres nodes poden trobar diferents nodes dins de la mateixa xarxa. En quant a
detecció de paquets duplicats, aquesta funció no s’estableix a l’estàndard i es implementada
als mòduls. La figura 18 mostra un mòdul XBee sèrie 2.
Figura 18. Mòdul XBee sèrie 2
La freqüència utilitzada es la banda lliure de 2.4 GHz, utilitzant 16 canals amb un ample de
banda de 5 MHz per canal, dels quals XBee PRO en soporta 12 (0x0C) al canal 23 (0x17), tal
i com es mostra a la figura 19.
Figura 19. Canals de freqüència suportats a la banda de 2.4 GHz

30
5 ENTORN DE DESENVOLUPAMENT
En l’actualitat l’estudi de les xarxes sensorials sense fils es troba contínuament en
desenvolupament i, en moltes ocasions, es necessari abans de la seva implementació utilitzar
algun tipus de simulador que permeti avaluar els resultats obtinguts per la xarxa, així com
poder realitzar canvis en els paràmetres dels sensors per estudiar els seus resultats i mesurar
també el rendiment i el consum de potència abans de provar-la en la plataforma real. El
compilador emprat en aquest projecte ha sigut el IDE propi de Waspmote.
5.1 IDE per a Waspmote
Es un entorn de desenvolupament ideat per treballar amb Waspmote pràcticament idèntic al
compilador d’Arduino, ja que posseeixen el mateix estil i funcionament, a més d’incloure totes
les llibreries API necessàries per la compilació dels programes. La figura 20 mostra l’aspecte
del software de programació.
Figura 20. IDE de Waspmote

31
Les opcions son el menú en el que es poden configurar els paràmetres generals tals com
l’elecció del port sèrie, la placa, etc.
La barra de comandes permet verificar, obrir, carregar o guardar en la placa el codi de
programa, tal i com es pot veure a la figura 21 amb més detall.
Figura 21. Barra de comandes
El codi de programa es el codi que es carrega a Waspmote.
Els missatges de sortida son aquells que mostren possibles errors de compilació o càrrega
que hagin pogut succeir, i si el codi es correcte, els missatges de compilació satisfactòria.
En la pestanya “Tools/Board” s’ha de seleccionar la placa Waspmote ( waspmote-avi-v024 en
aquest cas), mentre que en la opció inferior, “Serial Port”, es selecciona el port USB en el que
s’ha connectat la placa. El port no te perquè coincidir en diferents ordinadors, de fet el més
normal es que no coincideixi, per la que la opció més recomanable es verificar el port abans
de compilar el programa.
Per a la càrrega del programa s’ha de clicar sobre el botó “Upload” amb la placa connectada
a l’ordinador, l’interruptor activat i acte seguit començarà la compilació, en la que Waspmote
es reiniciarà automàticament i donarà començament a la càrrega. El IDE mostrarà un missatge
quan la càrrega estigui completa, o sorgirà un missatge d’error en vermell, indicant l’errada en
color groc sobre el codi. A l’hora de guardar els programes, també anomenats sketches, tenen
una extensió *.pde.

32
Com s’ha vist en l’apartat 3.2.2, l’arquitectura del Waspmote es basa en el microcontrolador
ATmega1281. Aquesta unitat de processament executa el bootloader, que es el responsable
de carregar en la memòria els programes i les biblioteques compilades prèviament
emmagatzemades en la memòria flash, per la qual el programa principal pot començar a
executar-se. Quan Waspmote es connecta e inicia el bootloader, hi ha un temps d’espera de
62.5ms abans de començar la primera instrucció per iniciar la càrrega de noves versions de
programes compilats.
L’estructura dels codis es divideix en 2 parts bàsiques: setup i loop. Ambdós parts del codi
tenen un comportament seqüencial, seguint l’execució de les instruccions en l’ordre establert.
Setup es la primera part del codi, que només s’executa una vegada a l’inici del codi. En
aquesta part es recomanable incloure-hi la inicialització dels mòduls que s’utilitzaran, així com
la part del codi que només es important quan s’inicia Waspmote.
Loop s’executa contínuament, formant un bucle infinit. Degut al comportament d’aquesta part
de codi, es recomanable l’ús d’interrupcions per realitzar accions amb Waspmote.
Quan Waspmote s’encén o es reinicia, el codi comença de nou a partir de la funció de
configuració i després seguidament la funció bucle. Per defecte, els valors de les variables
declarades en el codi i modificades en execució es perdran quan es produeixi un reset o no hi
hagi bateria. Per emmagatzemar de forma permanent els valors, es necessari utilitzar la
EEPROM del microcontrolador (4 KB). Les direccions EEPROM de 0 a 1023 son utilitzades
per Waspmote per les dades importants, raó per la qual no han de ser sobreescrites. Per
aquest motiu les direccions d’emmagatzemat disponibles van de 1024 a 4095. Altra opció es
utilitzar la tarja SD (2 GB).
5.2 Comunicació entre la placa Waspmote i el mòdul XBee
El projecte ha sigut dissenyat seguint les següents consideracions: es disposa de dos plaques
Waspmote, en les que es carrega el codi amb les instruccions necessàries per transmetre les
dades a un ordinador amb Gateway incorporat al corresponent port USB, per posteriorment
ser tractats per una interfície en Labview. Per això es d’una importància vital conèixer
l’estructura de dades que s’utilitzarà en la comunicació, on els possibles modes que s’utilitzen
son AT i API.

33
5.2.1 Comunicació AT
La comunicació en mode AT compren dos casos, el mode comandes i el mode transparent.
En el mode de comandes, s’utilitzen les comandes AT per conèixer la configuració del mòdul
o canviar-la. El mode transparent s’utilitza per enviar dades a través de l’XBee a un destí
remot, prèviament configurat al mode de comandes, on s’envia a través del port tal i com va
ser rebut. Per tant, en cas de voler enviar trames de dades contínuament aquest mode de
funcionament no serveix per a l’aplicació que es vol desenvolupar.
5.2.2 Comunicació API
La comunicació API es defineix com el protocol d’informació o normes que s’estableixen per
a la transmissió de dades. El procés d’enviar informació es complex i necessita d’estructures
especials i funcions per dur-ho a terme. Tenint en compte que hi ha un límit màxim de càrrega
o “Payload”, un paquet sol necessitar ser fragmentat. Per fer front a aquest procés, Zigbee
incorpora un “aplication header”. Aquesta aplicació es enviada internament amb el paquet
seguint l’estructura API frame, com es mostra a la figura 22.
Figura 22. Estructura API frame

34
L’estructura emprada per enviar informació via RF es específica de cada mòdul emprat. En el
cas de Waspmote-Zigbee, aplication header ha sigut adherit tal i com mostra la figura 23.
Figura 23. Aplication Header
Aplication header es omplert pel transmissor (operació API interna) i es emprada pel receptor
per tractar el paquet o fragment de forma adequada. Es enviat juntament amb les dades, per
tant la màxima longitud de les dades es reduïda a una longitud variable tot depenent del tipus
de source ID escollit.
Les diferents parts del header i la seva estructura dins del API Frame Structure son:
AplicationID, Fragment number, First Fragment Indicator, Source type ID, Source ID i Data.
AplicationID especifica l’ID a nivell d’aplicació. Permet identificar un sol paquet entre diversos
paquets al receptor.
Fragment number indica la posició del fragment en el paquet. El primer fragment sempre
mostra el nombre total de fragments del paquet. El següent indicador es opcional, first
Fragment Indicator inclou en el primer fragment una identificació que indica que es el primer.
Source type ID indica l’elecció de Source ID escollida. Les opcions son MAC(64 bits direcció
física del dispositiu), 16 bits (adreça de la Xarxa) o NI (20 bytes màxim identificant el node).
Source ID es troba íntimament relacionada amb el paràmetre anterior i especifica la
identificació del node que ha creat el paquet de dades.

35
6 SOLUCIÓ APLICADA
Per assolir els objectius del projecte s’ha dividit la tasca a realitzar en diferents fases:
Comunicació i enviament de dades, interfície nexe, base de dades i servidor. Als següents
apartats es detallaran explicacions d’alt nivell fins als detalls de la solució aportada en cada
fase realitzada.
6.1 Configuració mòduls XBee
El primer pas consisteix en la comunicació dels mòduls XBee, aquests son configurats
emprant el software X-CTU. Es disposa de dos versions d’aquest programa, la raó es ben
senzilla, la versió més actual no mostra les dades en un format llegible, sinó en hexadecimal.
La combinació entre ells permet la lectura de dades i la configuració dels mòduls de forma
més intuïtiva. Només la lectura s’efectua pel software amb la versió més antiga.
Amb la col·locació del Gateway al port USB del PC, es procedeix a executar X-CTU. Tal i com
mostra la figura 24, la primera finestra demana la busca del mòdul, on l’usuari ha de
seleccionar el port concret i les opcions de connexió per accedir al mòdul. Sense la correcte
relació de paràmetres no es podrà accedir al menú de configuració.
Figura 24. Busca del mòdul XBee

36
Un cop dins del menú de configuració del mòdul tal i com mostra la figura 25, es mostra el rol
actual, la versió del firmware i l’adreça MAC del dispositiu. A més a més, cal donar-li un rol, el
qual executarà dins de la xarxa. Com s’ha explicat a l’apartat 3, cal que hi hagi un Coordinador
i que aquest crei la xarxa on els altres mòduls han d’enllaçar-se. La configuració d’aquest
contempla aspectes molt importants: la PANID, la taxa de transferència de dades (BAUD), la
forma de rebre les dades i de qui rebrà la informació.
Figura 25. Configuració mòdul XBee

37
La següent figura 26 il·lustra la direcció per accedir al mode BROADCAST. Per tant, tota la
informació enviada pels End Devices serà escoltada.
Figura 26. Accés al mode BROADCAST

38
La taxa de transferència de dades per defecte es de 9600 BAUDS, per aquest projecte s’ha
elevat aquesta transferència a 38400. Aquesta ha de ser la mateixa per a tots els mòduls que
composin la xarxa, de la mateixa manera que per unir-se cal tenir la mateixa PAN ID. La
següent figura 27 mostra els paràmetres actuals del nostre Coordinador.
Figura 27. BAUD rate i configuració API
AP determina la forma en què rebrà les dades dels End Devices. En aquest cas, recepció per
frame API.
Els mòduls End Device es configuren de la mateixa forma. Es defineix la PAN ID creada pel
Coordinador, el mode de difusió BROADCAST (sense especificar direcció del mòdul), la taxa
de transmissió de les dades (BAUDS), i com a diferència, AP ha de ser igual a 2. Aquest
assegura el caràcter d’escapada del frame.

39
Un aspecte de seguretat es l’encriptació del missatges que circulen per l’aire, amb X-CTU
s’habilita el mode d’encriptació ta i com mostra la figura 28.
Figura 28. Encriptació paquets

40
6.2 Waspmote
Un cop configurats els mòduls XBee s’ha de programar la plataforma Waspmote amb les
instruccions de codi necessàries per realitzar l’enviament de dades. La figura 29 representa
el diagrama de flux del codi implementat sobre la placa Waspmote.
Figura 29. Diagrama de flux codi Waspmote
Inicialment, es declaren les variables que s’utilitzaran al llarg del codi. Acte seguit, al setup,
s’inicialitza les llibreries del protocol de comunicació ZigBee, s’habilita el mòdul XBee a on es
fa una operació per obtenir la direcció física MAC del dispositiu, després d’aquesta es
desconnecta el mòdul, i finalment s’inicialitza i configura la RTC.

41
Normalment, les operacions solen ser executades sobre el loop, però en aquest cas, la
direcció MAC no canvia mai, ja que es única per a cada dispositiu.
En aquest punt del codi comença la part que es repetirà contínuament, el loop. Per a la
preparació del paquet es necessari efectuar algunes operacions. Aquestes són l’obtenció de
les dades temporals i el nivell de bateria. Les dades temporals son recollides en un format per
defecte de la instrucció encarregada de l’obtenció d’aquestes, i més endavant caldrà
modificar-les de cares al posterior ús que se li donarà a aquesta informació. Per altra banda,
el nivell de bateria es mostra en hexadecimal, i de la mateixa forma que l’obtenció de la MAC
cal convertir-la a un format llegible.
La condició d’associació a la xarxa es necessària de cares al comportament del mòdul i el
somni profund d’aquest. Cada vegada que el mòdul desconnecta de la xarxa es perd
l’associació, i per tant, cal tornar a demanar-la. Si passats 30 segons no s’ha rebut, es
prepararà el paquet i s’enviarà, ja que es possible que un altre mòdul estigués enviant
informació.
La preparació del paquet comprèn el format de les dades per a què es mostrin d’una
determinada forma. Aquestes venen determinades per la base de dades MySQL, la qual
accepta unes especifiques formes per poder ser introduïdes i que seran explicades a l’apartat
6.2.2.
Un cop el paquet ja es troba preparat, s’envien les dades i a continuació s’allibera el buffer per
a la següent trama de dades.
El somni profund o Deep Sleep, permet al Waspmote romandre en un mode de consum molt
baix, tot estalviant bateria. En el cas proposat, el somni dura 30 segons i passat aquests
despertarà. La configuració del temps pot també efectuar-se indicant una hora concreta en
comptes d’un lapse de temps com el proposat.
Després de que el node desperti, cal que els mòduls s’engeguin de nou com es el cas de la
RTC per poder tornar a captar les dades temporals. El mòdul XBee s’activa cada cop que es
demana l’associació de xarxa i es desactiva després d’enviar les dades.

42
6.2.1 Visualització de dades
La visualització de les dades s’ha efectuat tant pel monitor sèrie que incorpora el IDE de
Waspmote com per X-CTU. S’han connectat a la xarxa dos End Devices, un amb el cable
USB i l’altre sense.
La figura 30 mostra el monitor sèrie de IDE. A la vegada que es mostren les dades son
enviades via ràdio al Coordinador.
Figura 30. Visualització de dades per monitor sèrie IDE

43
Per altra banda, la figura 31 mostra el codi rebut d’ambdós Waspmote pel software X-CTU.
Figura 31. Visualització de dades per X-CTU
6.2.2 Format de les dades
Tal i com s’ha vist a l’apartat 6.2.1, les dades apareixen d’aquesta forma perquè han sigut
modificades per poder ser introduïdes a la base de dades. La forma original en què la RTC
captura el temps es el dia de la setmana, any/mes/dia – hores:minuts.segons.
Amb la modificació introduïda ens assegurem que el format emprat es el que MySQL accepta
i es per la data: YYYY/MM/DD, i per la hora: HH:MM:SS, les quals son les dades que més
problemes ocasionaven en la seva divisió en LabVIEW i posterior inserció a la base de dades.

44
6.2.3 Estudi de consum
La capacitat nominal de les bateries utilitzades pels nodes es de 2300 mA h, amb això es pot
calcular el temps de descàrrega amb la fórmula mostrada a l’equació 1.
t=
Càrrega de la bateria
Consum del dispositiu
(Eq.1)
L’equació 1 mostra la fórmula que s’utilitza per conèixer el temps de descàrrega, on la càrrega
elèctrica es en Ah i el consum en A. D’aquesta forma se’n extreu la taula 5 el temps de
funcionament si només s’utilitzés cap d’aquests modes ininterrompudament. Càrrega elèctrica
de la bateria
Mode Consum Duració
ON 9 mA 255 hores = 10,5 dies
SLEEP 62 uA 4,3 anys
DEEP SLEEP 62 uA 4,3 anys
HIBERNATE 0,7 uA 380.3 anys
Taula 5. Duració de la bateria
De la taula se’n pot extreure que, efectivament, l’ús dels modes de baix consum augmenten
ostensiblement la duració de les bateries essent especialment significatiu el mode hibernació.
No obstant, la placa haurà de despertar-se en algun moment per realitzar la tasca que se li
hagi programat. Prenent com a exemple el programa dissenyat en aquest projecte, es pot
calcular el consum total del programa:
Execució (Mode ON)=(9 x 10-3
)A x
1 hora
60 min
x
0.5min
30s
x 30 s = 7.5 x 10−5
A (Eq.2)
Deep Sleep= (0.7 x 10-6
)A x
1 hora
60 min
x
0.5min
30s
x 30 s= 5.8333 x 10−9
A = 5.833 pA (Eq.3)
Amb els càlculs obtinguts es pot considerar que el consum del mode Deep Sleep es negligible
en comparació al d’execució i per tant la placa només consumirà recursos durant aquest. Amb
tot l’exposat, s’esbrina quina seria la duració de la bateria per aquest programa funcionant de
forma contínua.

45
t=
2300 x 10-3
Ah
7.5x 10-5
A
=30.666,57 h= 3.54 anys (Eq.4)
Com es pot veure, de una duració de casi 10.5 dies s’ha passat a 3 anys i mig. Per aquesta
raó l’ús d’interrupcions resulta molt útil per aquest tipus de programes, multiplicant el
rendiment de la bateria de forma excepcional.
6.3 LabVIEW
El codi dissenyat en LabVIEW s’estructura en tres parts, la recepció i retenció de les dades,
la lectura, i la divisió i inserció sobre la base de dades.
6.3.1 Recepció i retenció de dades
Els drivers VISA són un estàndard per a la configuració, programació i sistemes
d’instrumentació que comprenen GPIB, VXI, PXI, serial, Ethernet i/o interfície USB. Per a
l’aplicació que es desitja desenvolupar es de cabdal importància, ja que les dades son
introduïdes per port USB. La figura 32 mostra la primera part del codi:
Figura 32. Recepció i retenció de dades
Tal i com s’ha esmentat, la programació amb LabVIEW es visual, i els diferents colors de les
connexions ens indica quin tipus de dades tractem. La connexió es produeix pel COM Port i
s’especifica el recurs a ser obert a través del cable de color lila (VISA Resource Name), en
canvi les constants o variables que han de ser especificades en les funcions es troben en color
blau marí. Per altra banda, els errors acumulats passen pel cable de color groc i negre (VISA
Error).

46
El COM Port ha de ser seleccionat en funció de quin port USB es utilitzat pel Gateway, per
posteriorment utilitzar les funcions VISA. La primera funció es VISA OPEN i es l’encarregada
d’obrir la connexió del port USB.
La segona funció mostrada es VISA SERIAL i ha de ser complimentada degudament amb les
mateixes característiques que el port USB, es a dir, mateix BAUD, data bits, paritat, etc. El
paràmetre més important es el timeout, aquest temps ha de ser suficient per poder rebre les
dades, sinó en conseqüència la lectura no es produirà i l’aplicació no funcionarà.
VISA FLUSH I/O BUFFER buida i descarta els continguts del buffer de memòria de recepció,
d’aquesta forma cada cop que es reben dades el buffer queda lliure per a la pròxima entrada.
VISA SET BUFFER I/O SIZE determina la grandària del buffer que contindrà les dades
rebudes, per defecte aquest valor es de 4096 bytes, la càrrega estimada de dades es de 100
bytes per transmissió, per tant molt superior al nivell que necessitem.

47
6.3.2 Lectura
Tot el codi a partir d’aquest moment es troba implementat dins d’un bucle while, el qual al seu
interior s’hi defineixen casos booleans, cert o fals. La figura 33 mostra el primer d’ells:
Figura 33. Lectura de dades del buffer
Si al buffer de dades existeixen bytes per ser llegits, el controlador de casos serà diferent de
0, i per tant el cas es cert. Dins d’aquest, VISA Read s’encarrega de la lectura i a les sortides
trobem una lectura del port USB on es mostren les dades rebudes per Waspmote i una
bifurcació (String dades) que connectarà amb la segona part del codi. VISA Read conté una
constant on s’indica el nombre de bytes que ha de controlar, per aquesta raó el node de
propietats de VISA insereix a cada cicle el nombre exacte de bytes, d’aquesta forma la
constant sempre serà el nombre de bytes entrants.
El control de repeticions es necessari per LabVIEW, ja que per a cada iteració del while,
LabVIEW genera un número de referència associat a l’objecte, en aquest cas la connexió amb
el mòdul XBee.

48
En la següent figura 34 es mostra la condició de fals indicada per el controlador de casos. Tal
i com es pot apreciar en aquest cas no hi ha cap acció a executar.
Figura 34. Acció en cas fals

49
6.3.3 Tractament de la informació
Si existeixen dades i aquestes han sigut llegides en el cas cert, explicat a l’apartat 6.3.2, el
controlador de casos també indica la certesa en la segona part de codi mostrada a la figura
35, on es tracta la informació rebuda:
Figura 35. Divisió de la informació
Per a la correcte inserció de la informació a la base de dades es necessari conèixer el format
que s’ha fet servir, a més cal dividir la informació rebuda en les parts útils que necessitem. La
funció emprada per seccionar les dades es Match substring, on cal indicar la paraula, nombre
o caràcter que s’està buscant, d’aquesta forma en el cas concret de la MAC especifiquem la
paraula que volem trobar dins del string de dades, el següent caràcter es una coma i indica
que entre la paraula MAC i la coma, que separa les dades unes de les altres, es troba la
informació que ens interessa.

50
La figura 36 mostra el panell de control que ens mostra les dades seccionades:
Figura 36. Panell de control amb les dades seccionades

51
6.3.4 Connexió LabVIEW i MySQL
La connexió a la base de dades MySQL s’efectua a dos bandes, la primera indicant sobre el
PC la creació de la connexió amb la base de dades ja operativa, i en segon lloc sobre el codi
LabView. Cal esmentar que s’ha de tenir instal·lat el driver connector ODBC per a que
LabVIEW pugui establir dita connexió.
Per poder crear la connexió sobre el PC, cal anar a Panell de control i seguidament a eines
administratives. En la següent llista s’ha de clicar sobre orígens de dades ODBC, en la figura
37 es mostra el llistat de connexions existents.
Figura 37. Llistat connexions existents
Per poder definir una connexió cal clicar sobre agregar. Seguidament una llista apareixerà
amb els drivers de què disposa el PC, i en aquesta, cal buscar el driver ODBC. La figura 38
mostra la finestra que crearà la configuració i les dades que cal introduir per efectuar-la.

52
Figura 38. Creació de la connexió a MySQL
En Database cal introduir el nom de la base de dades a la qual volem crear la connexió, en
aquest cas base1. A més a més, podem veure que es posseeix un servidor local anomenat
localhost, el qual serà tractat a l’apartat 6.5

53
Un cop el PC ha creat la connexió, LabVIEW ha de ser configurat per poder inserir les dades
a la base. La forma de procedir es utilitzant LabADO funcions, creant la connexió i obrint-la.
En l’apertura de la connexió cal indicar el nom amb la que s’ha creat la connexió, tal i com
mostra el panell de control de LabVIEW en la figura 39.
Figura 39. Connexió a MySQL per panell de control LabVIEW

54
6.3.5 Inserció a la base de dades
Fins a aquest punt, les dades rebudes del Waspmote han sigut dividides en les parts útils que
s’introduiran a la base de dades. La figura 40 mostra el codi que insereix les dades a la base
i les funcions relacionades amb la connexió a MySQL descrita a l’apartat 6.3.4.
Figura 40. Inserció de dades a MySQL
La inserció de les dades es duu a terme mitjançant una query, es a dir una instrucció en
MySQL. En aquest cas volem introduir les dades, i la instrucció encarregada de fer-ho es:
INSERT INTO nomdelataula (dada1, dada2, dada3, dada4) VALUES (‘’,’’,’’,’’,’’); (Instr.1)
En la instrucció 1, dada1 ha de coincidir amb el nom de la primera dada de la base, MAC, i
així consecutivament. Per la introducció dels valors, cal que aquests vagin amb cometes
simples, separats per comes i tancant la instrucció amb punt i coma. LabVIEW introdueix totes
aquestes dades amb un Concatenate string sobre un ADODB Connection, finalment es tanca
la connexió.

55
6.4 MySQL
Per a la creació de bases de dades s’utilitza llenguatge SQL. Al annex d’aquesta memòria es
detalla el codi que crea la base i la taula. La figura 41 mostra l’aspecte de la base de dades i
la seva estructura.
Figura 41. Aspecte de la base de dades en phpmyadmin
La base es troba composada per 5 dades. Sobre LabVIEW només apareixen 4, la raó es que
la dada id es auto incremental, un identificador únic per a cada trama inserida, i a més a més
es la clau primària de la taula creada a la base, per tant no hi pot haver dos id iguals. Tot els
valors de la taula son NOT NULL, es a dir, cap valor de la taula pot ser buit.

56
6.5 Apache 2.2
El servidor fa possible la consulta de les dades des de internet. El llenguatge emprat es HTML
i PHP.
Per poder visualitzar les dades es requereix la configuració del router on s’ha implementat el
servidor local, obtenir un DNS dinàmic i les instruccions necessàries per connectar amb la
base de dades a la pàgina que es vol mostrar.
L’Aplicació desenvolupada es mostra a la figura 42, on apareixen les dades rebudes de
Waspmote, tot passant per LabVIEW i MySQL.
Figura 42. Consulta de dades per Internet
Per a que les dades puguin ser visualitzades només cal accedir al domini del servidor local,
tant per IP o pel nom que se li hagi donat.

57
6.5.1 DNS Dinàmic
Per a que les dades puguin ser consultades des de l’exterior es imprescindible que el PC que
fa de servidor local utilitzi DNS dinàmic, es a dir, el PC canvia la seva IP cada cop que reinicia
o s’apaga i cal que aquesta sigui fixa, sinó cada vegada que algun usuari volgués consultar
les dades no tindria el mateix domini i no podrien ser consultades.
Al present projecte s’ha instal·lat un DNS proporcionat per un proveïdor d’internet anomenat
DonWeb. Aquest proporciona un domini associat a una IP estàtica, tal i com mostra la figura
43.
Figura 43. DNS dinàmic

58
6.5.2 Seguretat
La consulta de les dades s’ha de produir de forma segura i que cap usuari que les vulgui
consultar no accedeixi a altres dominis del nostre servidor, tot visualitzant dades importants
que poden ser emprades per malmetre’l, com la versió de PHP, contrasenya MySQL, etc.
En qüestió de seguretat, s’ha modificat l’arxiu de configuració httpd.conf de la pàgina web on
es mostren les dades, i que conté certes instruccions que impedeixen que qualsevol usuari
que no sigui superusuari (root) accedeixi a informació detallada del servidor o pugui modificar-
lo.
Les instruccions ‘ServerSignature Off’ permet la desactivació de la signatura del servidor que
per defecte Apache mostra en la part inferior de les pàgines. A més a més, la directiva
‘ServerTokens Full’ s’utilitza per determinar què es mostrarà a la capçalera de la resposta
HTTP del servidor.
La versió d’Apache corre sota un usuari i grup que usualment es nobody o daemon, això
compromet la seguretat de forma que qualsevol usuari pot introduir-se en dominis que no es
desitja que siguin vistos. Les instruccions User Apache i Group Apache efectuen aquestes
modificacions respectivament. D’aquesta manera l’arxiu httpd.conf inicialitzarà sobre les
especificacions indicades.
Un dels aspectes més importants es la restricció d’accessos al directori arrel del servidor. Per
aquesta raó s’ha utilitzat les instruccions Allow o deny (permetre o denegar). La utilització
d’aquestes instruccions es detalla en la figura 44, on només poden accedir els que siguin d’un
domini especificat. Per a l’aplicació que s’ha desenvolupat poden accedir els usuaris que
provinguin d’un domini conegut.
Figura 44. Permetre l’accés a un determinat domini

59
Aquestes són algunes de les mesures utilitzades en qüestió de seguretat. Totes les
restriccions es troben especificades a l’annex d’aquesta memòria.
6.5.3 Configuració Router
L’aplicació desenvolupada s’ha implementat sobre un router domèstic. Per dur a terme la
visualització de dades des de l’exterior, primerament cal conèixer la porta d’enllaç que utilitza
el PC per connectar-se a internet. La forma de conèixer aquesta dada es accedir al CMD del
PC i introduir la sentència ipconfig, tal i com mostra la figura 45.
Figura 45. Símbol del sistema

60
Entrant al navegador amb la direcció IP de la porta d’enllaç s’accedeix al router, on cal
especificar nom i contrasenya. En les opcions avançades cal buscar la funció DMZ, que junt
amb el DNS dinàmic proporcionat cal introduir les dades i activar-lo. La figura 46 mostra les
dades introduïdes per a la correcte configuració.
Figura 46. Configuració DMZ

61
7 RESUM DEL PRESSUPOST
El cost del projecte es de dos mil vuit-cents cinquanta tres euros amb seixanta cèntims sense
IVA.

62
8 CONCLUSIONS
Amb la implementació de l’aplicació desenvolupada s’han assolit els objectius que inicialment
s’havien proposat.
Primerament, el disseny i incorporació del mode somni profund als codis creats per als End
Devices, tot permetent estalviar bateria. La configuració del temps d’aquest mode pot arribar
a ser de dies en cas de ser necessari la monitorització cada dos dies per exemple. A més a
més, la recepció de les dades es realitza mitjançant un Gateway, per tant fora de l’enrutador
que actualment composava la xarxa.
Segonament, s’ha dissenyat i implementat una interfície amb LabVIEW que tracta la
informació per després inserir-la en una base de dades. El tractament de les dades s’efectua
independentment del node que es tracti, per tant es tracta d’un codi que es útil per a tots els
End Device.
Tercerament, s’ha creat una base de dades amb MySQL que relaciona les dades enviades
amb LabVIEW i el servidor creat per fer la consulta de dades.
Finalment, la creació del servidor amb la base de dades inserida i les corresponents mesures
de seguretat, per a que cap usuari excepte el superusuari pugui accedir a l’arrel d’aquest.
Com a objectius secundaris, s’ha treballat amb diferents llenguatges de programació abans
desconeguts, com es el cas de MySQL i PHP.
Cal destacar les dificultats que han anat apareixent al llarg del desenvolupament del projecte,
ja que la unió de les diferents parts en que s’ha dividit la tasca a realitzar, en cas d’haver-hi
cap anomalia era precís tornar a la fase anterior per poder avançar. Com es el cas del format
necessari de les dades per al correcte funcionament de LabVIEW i MySQL o les connexions
LabVIEW – MySQL.
Resta assenyalar el treball futur. Aquesta implementació es només un principi, el següent pas
seria que en cas de caure el servidor, es a dir el PC s’apagués, un node en segon plànol com
a Coordinador reculli les dades que estaven destinades a perdre’s, i les emmagatzemi en una
tarja SD per posteriorment introduir-les a la base de dades del servidor un cop restablert.

63
La conclusió final es que es tracta d’un projecte que es troba en continu desenvolupament i
no es pot donar per acabat podent realitzar futures millores.
Ivan Piñero Fuertes
Graduat en Enginyeria Electrònica Industrial i Automàtica
Pineda de Mar, 24 de Agost de 2015

64
9 RELACIÓ DE DOCUMENTS
Aquest projecte consta de quatre documents: Memòria, plec de condicions, estat
d’amidaments i pressupost.

65
10 BIBLIOGRAFIA
APACHE SOFTWARE FOUNDATION. Puertos de escucha, ficheros de configuración i
Seguridad. (www.apache.org/docs/2.2 , 8 de Agost de 2015)
LAZARA, JOSE RAFAEL; PELEGRI, JOSE. LabVIEW: Entorno gráfico de programación.
Editorial S.A MARCOMBO. Madrid. 2012.
LIBELIUM. Development v1.1. (https://www.libelium.com/development v-11, 26 de Maig de
2015)
MySQL. Documentation MySQL 5.5 Manual. (https://dev.mysql.com/doc/refman/5.5/en, 30 de
Juliol de 2015 )
PÉREZ, CÉSAR. MySQL para Windows y Linux. Editorial RA-MA. Madrid. 2004.
NATIONAL INSTRUMENTS. VISA serial port. ( www.ni.com/t5/LabVIEW/visa-serial-port, 19
de Juliol de 2015)

66
11 GLOSSARI
WSN: Wireless Sensor Network
MAC: Media Acces Control
VISA: Virtual Instrument Software Architecture
COM: Communication port
PC: Personal Computer
MySQL: Structure Query Lenguage
ODBC: Open DataBase Connectivity
ADODB: Active Data Objects Data Base
DNS: Domain Name System
HTML: Hyper Text Markup Lenguage
PHP: Hypertext Pre Processor
DMZ: DesMilitarized Zone

67
A CODI INFORMÀTIC
En aquest apartat es detallarà amb exactitud la implementació dels codis emprats, per a que
el conjunt del sistema funcioni correctament.
A.1 CODI WASPMOTE
El codi implementat sobre els nodes End Device es el següent:
packetXBee* paq_sent; // Estructura de paquet XBee
int8_t state=0; // Estat actual del dispositiu
long previous=0; // Estat previ del node
char dades_enviar[74]; // Buffer dades útils, 74 bytes
char* macHigh=" "; // Part alta de la MAC del dispositiu, 8bits
char* macLow=" "; // Part baixa de la MAC del dispositiu, 8bits
char Bat_s[10]; // Variable Bateria
// Direcció Genèrica de BROADCAST
uint8_t direccion[8]={0x00,0x00,0x00,0x00,0x00,0x00,0xFF,0xFF};
void setup()
{
////////////////////////////////////////////////
// 0. Inicialització USB per depuració de codi
////////////////////////////////////////////////
USB.begin();
USB.println("E_D_X");
////////////////////////////////////////////////
// 1. Inicialització ZigBee
////////////////////////////////////////////////
// Inicialització de les llibreries necessàries
xbeeZB.init(ZIGBEE,FREQ2_4G,NORMAL);
xbeeZB.ON(); // Habilitació de ZigBee
delay(3000);
// Retard de 3 segons
int counter = 0; // Obtenció de la direcció física del dispositiu MAC
while(xbeeZB.getOwnMac()==1&&counter<4)
{
xbeeZB.getOwnMac();
counter++;
}
// El resultat de la obtenció de la MAC es troba en HEX, per tant cal
passar-la a string per poder visualitzar-la.
Utils.hex2str(xbeeZB.sourceMacHigh,macHigh,4);
Utils.hex2str(xbeeZB.sourceMacLow,macLow,4);
xbeeZB.OFF(); // Deshabilitació ZigBee
delay(100); // Retard de 0.1 segons

68
////////////////////////////////////////////////
// 2. Inicialització RTC i introducció de la data
////////////////////////////////////////////////
RTC.ON(); // Habilitació de la RTC
// Introducció de l'any, mes, dia, dia de la setmana, hores, minuts i
segons
RTC.setTime("15:09:15:06:08:00:00");
}
void loop()
{
////////////////////////////////////////////////
// 3. Operacions anteriors a la preparació paquet
////////////////////////////////////////////////
// Adquisició de dades temporals, en format: dia de la setmana, any/mes/dia
- hora:minuts.segons
RTC.getTime();
// Adquisició del nivell de bateria, el resultat cal que sigui convertit a
format string per ser visualitzat.
Utils.float2String(PWR.getBatteryLevel(),Bat_s,2);
////////////////////////////////////////////////
// 4. Associació a la xarxa
////////////////////////////////////////////////
xbeeZB.ON();
delay(3000);
// ZigBee espera una indicació per associar-se a la xarxa.
xbeeZB.getAssociationIndication();
// L'estat previ del node es igualat a la variable millis()
previous = millis();
// Mentre l’associació no sigui igual a 0
while( xbeeZB.associationIndication != 0 )
{
delay(2000);
// S'obté l'associació
xbeeZB.getAssociationIndication();
// Condició per evadir overflow (SEMPRE HI HA DE SER)
if (millis() < previous)
{
previous = millis();
}

69
// Surt quan el temps s'ha esgotat
// temps d'espera de 30 segons per obtenir l'associació
if( previous-millis() > 30000 )
{
break;
}
}
// Allibera buffer
xbeeZB.flush();
////////////////////////////////////////////////
// 5. Preparació del paquet de dades
////////////////////////////////////////////////
// Preparació de les dades i el format que es desitja
sprintf(dades_enviar,"-mac:%s%s,-Date:%04d/%02d/%02d,-
Hour:%02d:%02d:%02d,-
Bat:%sd",macHigh,macLow,RTC.year+2000,RTC.month,RTC.date,RTC.hour,RTC.minut
e,RTC.second,Bat_s,'%','r','n');
////////////////////////////////////////////////
// 6. Adreçament del destí de les dades
////////////////////////////////////////////////
// Reserva espai de memòria per al paquet
paq_sent=(packetXBee*) calloc(1,sizeof(packetXBee));
// Mode d'enviament BROADCAST
paq_sent->mode=BROADCAST;
paq_sent->MY_known=0; //
paq_sent->packetID=0x52; //
paq_sent->opt=0; //
xbeeZB.hops=0; //
// Paràmetres d'origen del paquet
xbeeZB.setOriginParams(paq_sent,MAC_TYPE);
// Paràmetres de destí del paquet
xbeeZB.setDestinationParams(paq_sent,direccion, dades_enviar, MAC_TYPE,
DATA_ABSOLUTE);
////////////////////////////////////////////////
// 7. Enviament del paquet
////////////////////////////////////////////////
// Enviament del paquet
xbeeZB.sendXBee(paq_sent);

70
////////////////////////////////////////////////
// 8. Alliberació del paquet
////////////////////////////////////////////////
// Allibera la memòria reservada per el paquet anterior
// Defineix el paquet com buit
free(paq_sent);
paq_sent=NULL; .
////////////////////////////////////////////////
// 9. Deshabilitació de ZigBee
////////////////////////////////////////////////
xbeeZB.OFF();
////////////////////////////////////////////////
// 10. Mode Somni profund
////////////////////////////////////////////////
USB.println("Going to sleep...");
USB.println();
// Entrant en somni profund, introducció del temps que ha de romandre
dormit, el mode d'alarma i definició de l'estat dels mòduls.
PWR.deepSleep("00:06:00:00", RTC_OFFSET, RTC_ALM1_MODE1,ALL_OFF);
USB.begin();
USB.println("wake");
// Habilitació de la RTC
RTC.ON();
}
L’estructura del codi esta dividida en tres parts principals: Declaració de variables i llibreries
API, setup i loop. A més a més, es troba dividit en subgrups enumerats del 0 al 10. La relació
de subgrups es només una forma visual per fer el codi més entenedor, però a part d’això, cal
posar especial èmfasi en la forma del codi.
Waspmote executa el codi de forma lineal, es a dir, relacionant l’estructura del codi amb la
funció especifica de cada part, no es el mateix utilitzar una funció específica al principi que al
final del codi. Donant un exemple, el mode de somni profund usualment es col·loca al final del
codi, ja que la seva posició al principi del codi pot ocasionar problemes d’inicialització com els
esmentats a la memòria.
En la declaració de variables s’engloba totes aquelles estructures i variables necessàries per
poder executar el codi. En aquest cas es crea l’estructura de paquet XBee, es declaren les

71
variables i el tipus de dada que contenen, ja sigui char, int, float, long o boolean, i la direcció
de destí al qual s’enviarà el paquet. Aquesta, podria donar-se en cas de ser un enviament
punt a punt o MULTICAST amb la direcció específica MAC del dispositiu o es pot treure de la
declaració i ser inclosa en la funció setOriginParams.
uint8_t direccion[8]={0x00,0x13,0xA2,0x00,0x40,0x7A,0xCB,0xAE}; // Direcció física MAC
xbeeZB.setOriginParams(paq_sent,”0013A200407ACBAE”,MAC_TYPE);
Void setup sempre inicialitza els mòduls a utilitzar. Els subgrups inclosos en aquesta part de
codi engloben els nombres 0 fins al 2.
La inicialització del port USB es exclusivament utilitzada en aquesta aplicació per a la
depuració de codi i la detecció d’errors.
El subgrup 1 inicialitza la comunicació ZigBee, de tal forma que, primerament es defineix la
funció de càrrega de llibreries necessàries per a la comunicació, i acte seguit habilitem el
protocol i el mòdul XBee. Aquesta acció comporta un gran pes en l’execució del codi, i es
aconsellable acompanyar-lo d’un retard o delay suficient.
La captura de la direcció física del dispositiu XBee MAC s’efectua mitjançant una condició
while, en la que fent ús de la funció que la demana guarda els 4 dígits superiors i inferiors. Es
necessari aplicar una funció per poder mostrar la direcció, ja que aquesta es troba en format
hexadecimal. La seva integració al setup es degut a que la direcció MAC no canviarà amb els
cicles i només cal executar-la un cop.
El subgrup 2 inicialitza i configura la RTC, i es d’especial importància ja que a partir d’aquestes
dades marcarem el temps que el node estarà en somni profund. Per ingressar-les s’ha de
definir primerament l’any, el mes, el dia, el dia de la setmana, les hores, els minuts i els segons,
de manera que si es desitja introduir el dia 24/02/2015 i les 10:15:00 la instrucció resultant
tindria l’estructura següent:
RTC.setTime("15:02:24:02:10:15:00”);

72
On els primers dos dígits indiquen l’any, seguidament del mes, el dia, el dia de la setmana,
les hores, minuts i segons. El dia de la setmana compren els nombres 01, indicant que es
diumenge, fins al 07 que es dissabte.
Void loop incorpora els subgrups 3 fins al 10, i inclou el gruix del codi i les funcions que es
repetiran cíclicament. Cal esmentar que, aquest void pot contenir altres voids en cas que
determinades línies de codi siguin emprades de forma contínua.
En l’estructura de codi es important que les línies de codi que englobin operacions per a la
preparació d’un paquet de dades, siguin ubicades a l’inici del cicle, com es el cas del subgrup
3. Tot i que RTC.getTime() ens retorna les dades temporals en format:
dia de la setmana, any/mes/dia – hores :minuts .segons ,
Sunday, 14/02/2014 – 15:36.48;
Es necessària la modificació del format per al posterior tractament en Labview i la seva
introducció a la base de dades.
El treball amb nodes finals conté una certa complexitat, i en el cas que ens ocupa cada cop
que el node desperta del seu somni no és suficient amb l’habilitació del protocol ZigBee.
Durant el somni es perd la comunicació amb la resta de la xarxa i per tant, l’associació. Es
necessari que, tot dispositiu que romangui dormit la gran majoria del seu temps contingui les
línies de codi que s’agrupen al subgrup 4. Dins d’aquest subgrup es defineix la variable millis(),
aquesta realitza un comptatge del temps que porta el codi executant-se, i juntament amb
previous es controla el temps d’espera per a una determinada execució. Finalment, cal
alliberar el buffer del mòdul XBee.
La preparació del paquet de dades es conforma en el subgrup 5, juntament amb les
operacions realitzades pel subgrup 3. Tot i que la RTC ja ens dóna un format correcte, les
dades han de ser modificades per poder ser enregistrades en la base de dades, on s’accepta
el format YYYY/MM/DD per la data i HH:MM:SS per al temps. La modificació es porta a terme
indicant exactament com es vol que es mostri el paquet, de tal forma que la direcció MAC es
troba en format string ‘%s’ i la seva capçalera, la data especifica que l’any ha de ser mostrat
amb 4 dígits ‘%04d’, els mesos i dies amb dos ‘%02d’, i la visualització del nivell de bateria en

73
%s. La part final de les dades que es volen mostrar incorpora una lletra ‘d’ la qual es emprada
per separar posteriorment la informació sobre Labview.
Els subgrups 7, 8 i 9 comprenen l’enviament del paquet, l’alliberació de memòria ocupada per
aquest i la desconnexió del mòdul XBee per entrar en el mode de somni profund.
La RTC es troba configurada per a un somni de 6 hores, temps després del qual despertarà i
el cicle tornarà a ser executat. Després de cada somni tots els mòduls resten apagats, i per
tant cal tornar a inicialitzar-los.

74
A.2 CODI MySQL
// Creació de la base de dades
CREATE DATABASE base1;
// Especifica la utilització de la base a la qual se li vol crear una taula
USE base1;
// Creació la taula
CREATE TABLE tabla1 (
// Variable autoincremental i clau primària de la taula
Id INT(11) NOT NULL AUTO_INCREMENT PRIMARY KEY,
// Creació de les files de dades que introduirem, cap d’elles tindrà
un valor buit.
MAC VARCHAR (20) NOT NULL,
DATA DATE NOT NULL,
HORA TIME NOT NULL,
BATERIA FLOAT NOT NULL);

75
A.3 CODI INSERCIÓ MySQL A SERVIDOR WEB
<html>
<head>
<title>TFG-Xarxa de sensors sense fils</title> (títol header de la pàgina)
</head>
<body>
<div>
<fieldset>
<center><H1>CONSULTA DADES WASPMOTE</H1> (Títol página web)
<div>
<?php (inici de codi php dins de codi html)
//Connexió a base de dades
$con = mysql_connect("localhost","root","XXXX") or die ("<h2>No es troba el
servidor</h2>");
// Selecciona base de dades
mysql_select_db("base1",$con) or die ("<h2>Error de conexio</h2>");
// Instrucció que executarà la selecció de totes les dades
$dades=mysql_query("SELECT id, MAC, DATA, HORA, BATERIA FROM tabla1",$con);
if ($row = mysql_fetch_array($dades))
{
// Creació d’un recuadre al voltant de la taula que mostrarà les
dades
echo "<table border = '1'> n";
echo
// títol dels capçals de les dades en la taula
"<tr><td>id</td><td>MAC</td><td>DATA</td><td>HORA</td><td>BATERIA</td></tr>
n";
do
{
echo
// Mostra les dades en el ordre de la creació de la taula
"<tr><td>".$row["id"]."</td><td>".$row["MAC"]."</td><td>".$row["DATA"]."</t
d><td>".$row["HORA"]."</td><td>".$row["BATERIA"]."</td></tr> n";
}
while ($row = mysql_fetch_array($dades));
echo "</table> n";
}
else
{
echo "¡ No s’ha trobat cap registre !";
}
?> ( tancament codi php)
</div>
</fieldset>
</div>
</body>
<footer>

76
</footer>
</html>

77
A.4 CONFIGURACIÓ SEGURETAT APACHE
#
# Archiu principal de configuració d’Apache. Conté les directives de
#configuració.
#
# ServerRoot: Directori més elevat que conté la configuració, error i els
#archius log on es registren els errors de la pàgina.
#
ServerRoot "C:/Apache2.2"
#
# Listen: Defineix el port per el què Apache escoltarà les peticions. En
#cas de posar una dirección IP es protegirà al servidor de multiples
#consultes al mateix temps.
Listen 80
#
# Dynamic Shared Object (DSO) Support
#
# Per fer servir les funcionalitats del servidor es carreguen els mòduls
#d’objectes definits com DSO que fan falta corresponents a archius ubicats
#en la carpeta on es troba el servidor.
#
LoadModule actions_module modules/mod_actions.so
LoadModule alias_module modules/mod_alias.so
LoadModule asis_module modules/mod_asis.so
LoadModule auth_basic_module modules/mod_auth_basic.so
LoadModule authn_default_module modules/mod_authn_default.so
LoadModule authn_file_module modules/mod_authn_file.so
LoadModule authz_default_module modules/mod_authz_default.so
LoadModule authz_groupfile_module modules/mod_authz_groupfile.so
LoadModule authz_host_module modules/mod_authz_host.so
LoadModule authz_user_module modules/mod_authz_user.so
LoadModule autoindex_module modules/mod_autoindex.so
LoadModule cgi_module modules/mod_cgi.so
LoadModule dir_module modules/mod_dir.so
LoadModule env_module modules/mod_env.so
LoadModule include_module modules/mod_include.so
LoadModule isapi_module modules/mod_isapi.so
LoadModule log_config_module modules/mod_log_config.so
LoadModule mime_module modules/mod_mime.so
LoadModule negotiation_module modules/mod_negotiation.so
LoadModule setenvif_module modules/mod_setenvif.so
<IfModule !mpm_netware_module>
<IfModule !mpm_winnt_module>
#
# Per fer córrer httpd amb un grup I usuari diferent, cal iniciar com a
#root inicialment, i automàticament es comutarà a les noves directrius.
#
User Apache
Group Apache

Memòria

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (20)

Similar to Memòria

Similar to Memòria (20)

Memòria