Vous êtes sur la page 1sur 92

Sensoriamento de ambiente utilizando o padro

ZigBee

Ferdinando Monsignore

Dissertao apresentada Escola


de Engenharia de So Carlos da
Universidade de So Paulo, como
parte dos requisitos para a obteno
do ttulo de Mestre em Engenharia
Eltrica.

Orientadora: Profa. Dra. Maria Stela Veludo de Paiva

So Carlos
2007
Dedico este trabalho aos meus amados pais,
Vera Teresa Moretti Monsignore e Simplicio Monsignore.
Agradecimentos

Ao Pai Celestial, pela proteo e luz dada durante todo o


desenvolvimento deste trabalho;

A minha orientadora Profa. Dra. Maria Stela Veludo de


Paiva, por me ensinar e por sua amizade durante todo o percurso;

A todos os amigos de repblica, por sua amizade e pre-


sena em todas as horas;

A N3E, que teve papel muito importante na realizao


deste trabalho;

Aos meus avs, pais e irmos, pelo apoio irrestrito e cari-


nho em todos os momentos desde sempre;

Em especial a minha namorada Mnica C. Miranda, por


seu amor, companheirismo e incansvel apoio durante a realizao
deste trabalho.
i

Resumo

MONSIGNORE, F. (2007), Sensoriamento de ambiente utilizando o padro ZigBee. Disserta-

o (Mestrado) - Escola de Engenharia de So Carlos, Universidade de So Paulo, So Carlos,


2007. 74p.

A comunicao sem fio (wireless) vem sofrendo uma enorme expanso nos ltimos anos. Para
esse tipo de comunicao foram criados alguns padres, destacando-se o Wi-Fi, o Bluetooth

e mais recentemente o ZigBee. Este ltimo, o ZigBee, engloba aplicaes de monitorao e


sensoriamento de sistemas, o que o torna adequado para aplicaes residenciais. Essa carac-

terstica do ZigBee motivou o desenvolvimento desse trabalho, cujo objetivo foi o de avaliar o
padro ZigBee atravs de uma aplicao de monitorao e sensoriamento para uso residencial,
utilizando um kit de desenvolvimento da Microchip. Esse trabalho consiste em dois ns se co-

municando via ZigBee, onde um n possui um sensor de movimento, uma lmpada e um LED
(que simula um aparelho de ar condicionado) e um segundo n, que pode ser conectado a um

PC via USB utilizando um hardware externo desenvolvido. Esse n ainda possui um sensor de
temperatura, um sensor de luminosidade(LDR) e um sinalizador acstico.

Os resultados obtidos mostram que o ZigBee um padro eficiente para aplicaes de monito-
rao e sensoriamento de ambientes.

Palavras-chave: ZigBee; Domtica; Sensoriamento; USB


ii

Abstract

MONSIGNORE, F. (2007), Environment sensing using ZigBee standard. M.Sc. Dissertation -


Escola de Engenharia de So Carlos, Universidade de So Paulo, So Carlos, 2007. 74p.

A huge expansion has occurred in wireless communication in the last few years. Some wireless
standards were created, like Wi-Fi, Bluetooth and more recently the ZigBee standard, that inclu-

des monitoring and sensing systems application. This characteristic makes the ZigBee standard
appropriate for residencial applications. This ZigBee characteristic motivated the development

of this work, wich objective was evaluate the ZigBee standard through a monitoring and sensing
application for residencial use, using a development kit by Microchip. This application has two
nodes communicating through ZigBee. One node has a motion sensor, a lamp and a LED (that

simulates an air conditioner device) and the second one can be connected to a PC through USB
using a developed external hardware. This node also has a temperature sensor, a light dependent

resistor (LDR) and a beep.

The reached results shows that ZigBee is an efficient standard for environment monitoring and
sensing.

Keywords: ZigBee; Smart building; Sensing; USB


SUMRIO

Lista de abreviaturas e siglas vii

Lista de smbolos xi

Lista de Figuras xiii

Lista de Tabelas xv

1 Introduo 1

1.1 Contextualizao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Motivao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.4 Contribuies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.5 Estrutura do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Comunicao Wireless 5

2.1 Consideraes Iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 Comunicao Wireless: Introduo . . . . . . . . . . . . . . . . . . . . . . . . 5

2.3 Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.4 Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.5 ZigBee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
iv

2.6 Consideraes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3 A norma 802.15.4 e o padro ZigBee 19

3.1 Consideraes Iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.2 O Padro ZigBee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.2.1 Topologias de Rede . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.2.2 Pilha Protocolar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2.3 Camada PHY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2.4 Camada MAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.2.5 Camada de Rede . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.2.6 Camada de Aplicao . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.2.7 Binding e Binding Table . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.3 Consideraes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4 Trabalho Desenvolvido 31

4.1 Consideraes Iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.2 Funes Implementadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.3 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.3.1 Comunicao Entre os Ns . . . . . . . . . . . . . . . . . . . . . . . . 33

4.3.2 Implementao e Validao do Hardware . . . . . . . . . . . . . . . . 34

4.4 Ferramentas de Desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.5 Consideraes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5 Descrio, Resultados e Discusses 37


v

5.1 Consideraes Iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.2 Descrio da Lgica dos Sensores e da USB . . . . . . . . . . . . . . . . . . . 37

5.2.1 Sensor de Temperatura . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5.2.2 Sensor de Movimento . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5.2.3 Sensor de Luminosidade . . . . . . . . . . . . . . . . . . . . . . . . . 38

5.2.4 USB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.3 Descrio do Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.3.1 PICDEM Z . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.3.2 Sensor de Temperatura . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.3.3 Sensor de Luminosidade e Sinalizador Acstico . . . . . . . . . . . . . 43

5.3.4 USB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.3.5 Sensor de Movimento . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.3.6 Led . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.3.7 Lmpada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.3.8 Real Timer Clock (RTC) . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.4 Descrio do Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.4.1 Pilha ZigBee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.4.2 Software Desenvolvido . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.5 Resultados e Discusses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

6 Concluses 55

6.1 Concluses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

6.2 Contribuies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
vi

6.3 Proposta para Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . 56

Referncias Bibliogrficas 59

Apndice A -- Cdigos Fonte 63

A.1 Coordenador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

A.1.1 Inicializao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

A.1.2 Sensor de Temperatura . . . . . . . . . . . . . . . . . . . . . . . . . . 63

A.1.3 Sensor de Luminosidade (LDR) . . . . . . . . . . . . . . . . . . . . . 67

A.1.4 Sinalizador Acstico (Buzzer) . . . . . . . . . . . . . . . . . . . . . . 69

A.2 End Device (RFD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

A.2.1 Inicializao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

A.2.2 Sensor de Movimento . . . . . . . . . . . . . . . . . . . . . . . . . . 71

A.2.3 Lmpada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

A.2.4 LED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
LISTA DE ABREVIATURAS E SIGLAS

AC Alternate Current

Ack Acknowledgment
ADC Analogic Digital Conversor

AES Advanced Encryption Standard


AF Application Framework

APS Applications Support


CAP Contention Access Period
CD Compact Disc

CE Chip Enable
CLK Clock

CNPq Conselho Nacional de Desenvolvimento Cientfico e Tecnolgico


CSMA-CA Carrier Sense Multiple Access with Collision Avoidance

DSSS Direct Sequence Spread Spectrum


FDM Frequency Division Multiplexing
FFD Full-Function Device

FHSS Frequency Hopping Spread Spectrum


GND Ground

GPRS General Packet Radio Service


GSM Global System for Mobile Communications

GTS Guaranteed Time Slots


HAN House Area Network
IEEE Institute of Electrical and Electronics Engineers
viii

IP Internet Protocol

ISM Industrial, Scientific and Medical


KVP Key-Value Pair
LAN Local Area Network

LCD Liquid Crystal Display


LDR Luminosity Dependent Resistor

LQI Link Quality Indication


MAC Medium Access Control

MAN Metropolitan Area Network


MSG Message Service Type
NWK Network

PAN Personal Area Network


PC Personal Computer

PCI Placa de Circuito Impresso


PDA Personal Digital Assistant

PHY Physical
QoS Quality of Service
RF Rdio Freqncia

RFD Reduced-Function Device


RS232 RETMA Standard 232

RTC Real Time Clock


SDI Serial Data In

SDI/O Serial Data In/Out


SDO Serial Data Out
SNR Sinal Noise Relation

SPI Serial Peripheral Interface


ix

TTL Transistor - Transistor Logic

UART Universal Assynchronous Receiver Transmitter


USB Universal Serial Bus
UWB Ultra Wide Band

WAN Wide Area Network


Wi-Fi Wireless Fidelity

ZDO ZigBee Device Object


x
LISTA DE SMBOLOS

Ohm
oC Graus Celsius
A Ampere

B Byte
bps Bits Por Segundo

G Giga
Hz Hertz
k Kilo

M Mega
V Volts
xii
LISTA DE FIGURAS

2.1 Posicionamento das tecnologias wireless. Fonte: (FRIAS, 2004) . . . . . . . . 6

2.2 Comparao de redes Wireless. Fonte: (BRANQUINHO; REGGIANI; AN-

DREOLLO, 2005) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3 Tecnologias sem fio LAN/PAN. Fonte: (FRENZEL, 2004) . . . . . . . . . . . 8

3.1 Topologias de Rede. Fonte: (MALAFAYA; TOMS; SOUSA, 2005) . . . . . . 20

3.2 Modelo de camadas da pilha protocolar ZigBee. . . . . . . . . . . . . . . . . . 22

3.3 Estrutura de canais do IEEE 802.15.4. Fonte:(LEE, 2005) . . . . . . . . . . . . 23

3.4 Estrutura Superframe, Fonte: (ONDREJ et al., 2006) . . . . . . . . . . . . . . 24

3.5 Transmisso direta em redes (a) beacon habilitado, e (b) beacon no habilitado.
Fonte: (LEE, 2005) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.6 Transmisso indireta em redes (a) beacon habilitado, e (b) beacon no habili-
tado. Fonte: (LEE, 2005) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.7 Formato da mensagem ZigBee . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.8 Binding e Tabela de Binding. Fonte: (ZIGBEE-ALLIANCE, 2005) . . . . . . . 29

4.1 Diagrama de blocos do n do tipo coordenador. . . . . . . . . . . . . . . . . . 32

4.2 Diagrama de blocos do n do tipo RFD. . . . . . . . . . . . . . . . . . . . . . 33

4.3 Placa PICDEM Z com placa de RF acoplada. Fonte: (MICROCHIP, 2006b) . . 36

5.1 Trabalho Desenvolvido . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.2 PICDEM Z adequado para o desenvolvimento. . . . . . . . . . . . . . . . . . 41


xiv

5.3 Parte inferior do PICDEM Z aps adequao. . . . . . . . . . . . . . . . . . . 41

5.4 Circuito do Sensor de Temperatura. Fonte: (MICROCHIP, 2004e) . . . . . . . 42

5.5 Localizao do TC77 no kit PICDEM Z. . . . . . . . . . . . . . . . . . . . . . 42

5.6 (a) Circuito do LDR implementado, (b) Circuito do Sinalizador Acstico im-
plementado. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.7 Sensor de Luminosidade e Sinalizador Acstico. . . . . . . . . . . . . . . . . . 44

5.8 Placa USB-RS232-TTL desenvolvida. . . . . . . . . . . . . . . . . . . . . . . 45

5.9 Conexo da placa USB no modo USB - TTL. . . . . . . . . . . . . . . . . . . 46

5.10 Circuito implementado para leitura do sensor de movimento. . . . . . . . . . . 46

5.11 Sensor de Movimento da ICCEA. . . . . . . . . . . . . . . . . . . . . . . . . 46

5.12 Circuito do Sensor de Movimento implementado. . . . . . . . . . . . . . . . . 47

5.13 Circuito do LED implementado. . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.14 Circuito de acionamento da lmpada. . . . . . . . . . . . . . . . . . . . . . . . 48

5.15 Circuito de referncia para o comparador. . . . . . . . . . . . . . . . . . . . . 48

5.16 Circuito do RTC implementado. . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.17 Real Timer Clock. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5.18 Fluxograma do n do tipo coordenador. . . . . . . . . . . . . . . . . . . . . . 53

5.19 Fluxograma do n do tipo RFD . . . . . . . . . . . . . . . . . . . . . . . . . . 54

6.1 PIXIE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
LISTA DE TABELAS

1.1 Comparao de tecnologias sem fio. Fonte: (MALAFAYA; TOMS; SOUSA, 2005) . . . . . 2

2.1 Comparao de caractersticas desejveis entre Bluetooth e ZigBee. Fonte: (BAKER, 2005) . . 8
1

1 INTRODUO

1.1 Contextualizao

A comunicao wireless j est presente h algum tempo no cotidiano das pessoas,

tendo sofrido uma enorme expanso nos ltimos anos. Os mais difundidos padres wireless so
o Wi-Fi e o Bluetooth. Apenas recentemente comeou a se pensar num padro especfico para

se trabalhar com sistemas de monitorao e sensoriamento, tais como sistemas de automao


domstica, segurana, controle de iluminao e de acesso, etc. Os principais requisitos deste

tipo de sistema so baixa latncia, otimizao para baixo consumo de energia, possibilidade de
implementao de redes com elevado nmero de dispositivos e baixa complexidade dos ns de
rede.

O padro ZigBee (ZIGBEE-ALLIANCE, 2006) um padro mais recente, criado

com o objetivo de suprir esses requisitos, e juntamente com o padro IEEE1 802.15.4 (GUTI-
ERREZ et al., 2001), visa a uniformizao das redes pessoais (PAN) e das redes domsticas
(HAN) de ltima gerao, garantindo a confiabilidade, a segurana na comunicao e a maxi-

mizao do tempo de vida til das baterias.

Cabe lembrar que o Zigbee no foi idealizado para substituir o Bluetooth. Cada
um especfico para um tipo de aplicao. A tabela 1.1 apresenta a comparao entre as duas

tecnologias sem fio. O ZigBee engloba aplicaes de monitorao e sensoriamento de sistemas,


enquanto que o Bluetooth mais apropriado para sistemas de transmisso de udio ou dados
ponto a ponto, sistemas que exigem uma taxa de transferncia mais alta.

1 Institute of Electrical and Electronics Engineers


2 1 Introduo

Especificao Camada Taxa Durao das Recursos Ns Alcance


Fsica Baterias
Bluetooth 802.15.1 1Mbps 1 a 7 dias 250KB 7 1 a 10m
ZigBee 802.15.4 250Kbps 100 a 1000 dias 4 a 32KB 65535 100m

Tabela 1.1: Comparao de tecnologias sem fio. Fonte: (MALAFAYA; TOMS; SOUSA, 2005)

O ZigBee o mais apropriado para aplicaes que envolvam dispositivos remo-

tos alimentados por baterias, sensores e atuadores, j que permite baixo consumo, taxas de
transferncia adequadas para este tipo de aplicao (de 20 a 250kbps) e possui uma pilha pro-
tocolar mais simples que possibilita a sua implementao em sistemas com recursos limita-

dos.(MALAFAYA; TOMS; SOUSA, 2005)

1.2 Motivao

Este trabalho parte de um projeto do CNPq em conjunto com a N3E Nova Empresa,

que tem por objetivo a implementao de um sistema para monitorao e sensoriamento de am-
bientes residenciais utilizando comunicao sem fio.

A busca por um padro de comunicao sem fio, especfico para esse fim, levou
implementao desse presente trabalho, que visa principalmente avaliar o padro ZigBee para

tal aplicao.

1.3 Objetivos

O objetivo deste trabalho avaliar o protocolo de comunicao sem fio ZigBee

atravs de uma aplicao para uso residencial utilizando um kit de desenvolvimento da Microchip.
1.4 Contribuies 3

1.4 Contribuies

Uma rede de comunicao sem fios minimiza a utilizao de cabos na instalao


eltrica de uma residncia. Os cabos que hoje fazem o papel de retorno para lmpadas, e os

cabos que ligam e alimentam os sensores espalhados pelas casas, entre outros, podero ser
substitudos por mdulos ZigBee com alimentao por baterias, que podem durar vrios anos.

Esse o maior diferencial desse trabalho, pois j existem aplicaes para uso resi-
denciais que visam conforto, segurana e economia para os usurios, como pode ser visto em

Home-Control (2006), mas a maioria possui cabeamento para tal.

Um outro aspecto muito importante a utilizao da interface USB2 na coleta dos


dados. Nos ltimos anos vem ocorrendo uma substituio gradativa das interfaces seriais no
padro RS232 pela do padro USB nos PCs, e visto que a tendncia aponta para um total desa-

parecimento das interfaces seriais do padro RS232, torna-se de suma importncia a presena
de uma conexo USB no n ZigBee que se comunicar com um PC para descarga de dados.

1.5 Estrutura do trabalho

Este trabalho est dividido em 6 captulos e 1 apndice.

No primeiro captulo foi apresentada a introduo, destacando a aplicabilidade, im-


portncia, e o objetivo do trabalho.

No captulo 2 apresentada uma breve descrio da comunicao wireless e de


alguns tipos de implementaes existentes, enfatizando as que se encaixam no conceito de rede

de rea pessoal (PAN).

No captulo 3 so apresentados mais detalhadamente os padres ZigBee e 802.15.4.

No captulo 4 apresentada a metodologia e as ferramentas utilizadas para o desen-

volvimento do trabalho proposto.

2 Universal Serial Bus


4 1 Introduo

No captulo 5 apresentada a descrio da lgica, do hardware e software imple-

mentados, os resultados e as discusses.

No captuo 6 so apresentados as concluses, as contribuies deste trabalho e as

propostas para trabalhos futuros.

No apndice A apresentado o cdigo fonte utilizado na implementao proposta.


5

2 COMUNICAO WIRELESS

2.1 Consideraes Iniciais

Neste captulo realizada uma reviso dos trabalhos mais recentes na literatura

sobre comunicao wireless e sobre alguns dos padres mais difundidos.

2.2 Comunicao Wireless: Introduo

A tecnologia wireless descreve os sistemas de telecomunicao em que as ondas


eletromagnticas carregam o sinal sobre parte ou todo o trajeto de comunicao sem a utilizao

de cabos (JINDAL; JINDAL; GUPTA, 2005).

As redes wireless mantm a promessa do acesso informao em qualquer lugar.


Esta promessa conduziu distribuio difundida dos servios de voz e dados baseados em
tecnologia wireless, exemplificado por redes de celulares e por redes de rea local sem fio

(WLAN) (NUGGEHALLI; SRINIVASAN; RAO, 2006).

apresentado a seguir um breve histrico da comunicao wireless:

1839 - 1a mensagem telegrfica em cdigo morse - o 1o SMS !

1867 - Fundao da indstria telefnica, a Bell, precursora da AT&T.

1900 - 1a Transmisso Wireless - MARCONI, ondas de rdio.

1972 - 1a Demonstrao de telefonia celular - MOTOROLA

1999 - Criao da Wi-Fi Alliance.

1999 - Formalizado o Bluetooth Special Interest Group (SIG).


6 2 Comunicao Wireless

2000 - Revoluo de voz & dados na telefonia celular.

2002 - Revoluo de banda larga - CableModem, xDSL, VoiceIP...

2004 - ZigBee Alliance termina primeira verso do padro ZigBee em Dezembro.

A Figura 2.1 ilustra o posicionamento do padro ZigBee no mercado de tecnologias


wireless, levando em considerao o alcance e a taxa de transmisso. Apesar do padro ZigBee
ter sido projetado para ter um alcance de at 10 metros, ele pode chegar a algumas dezenas de

metros, ultrapassando um pouco o limite de uma PAN e entrando na regio de alcance de uma
rede de rea local (LAN).

Figura 2.1: Posicionamento das tecnologias wireless. Fonte: (FRIAS, 2004)

Conforme j mencionado na introduo, o ZigBee veio preencher uma lacuna refe-


rente s aplicaes de monitorao e sensoriamento.

Como pode ser visto na Figura 2.2, existem vrios tipos de redes, classificadas de
acordo com a distncia de alcance de cada uma delas como segue:

PAN

Esse tipo de rede geralmente tem alcance bem restrito, da ordem de alguns metros.
2.2 Comunicao Wireless: Introduo 7

LAN

Esse tipo de rede j possui um alcance de algumas dezenas de metros.

MAN (Metropolitan Area Network)

O alcance desse tipo de rede j da ordem de dezenas de quilmetros.

WAN (Wide Area Network)

A proposta deste tipo de rede ter um alcance global, a exemplo do que acontece com a
tecnologia GSM (Global System for Mobile Communications) .

Figura 2.2: Comparao de redes Wireless. Fonte: (BRANQUINHO; REGGIANI; ANDRE-


OLLO, 2005)

O padro ZigBee, juntamente com os padres Bluetooth e Ultra Wide Band (UWB)

pertencem ao mesmo tipo de rede, a PAN, que possui um alcance restrito, da ordem de at 10
metros para o UWB, de 10 metros para o Bluetooth e de 10 a 100 metros para o padro ZigBee,
conforme especificado na Figura 2.3. Tambm pode ser visto nessa figura o alcance do Wi-Fi,

que de 100 metros para os padres 802.11b e 802.11g e de 50 metros para o padro 802.11a.
1 Depende do rdio
8 2 Comunicao Wireless

Figura 2.3: Tecnologias sem fio LAN/PAN. Fonte: (FRENZEL, 2004)

Caracterstica ZigBee Bluetooth


Alcance
Projetado 10 a 100 metros 10 metros
Kits especiais ou at 400 metros acima de 100 metros1
ambiente externo
Taxa de transmisso 20 a 250kbps 1Mbps
Latncia (tpica)
Insero de novo escravo 30ms 20s
Mudana de estado do escravo 15ms 3s
de sleep para ativo
Acesso de canal Escravo ativo 15ms 2ms
Perfil de Alimentao Anos Dias
Requer Alimentao Funcionalidades
do escravo otimizada adhoc maximizadas
Segurana 128 bit AES e definvel na 64 bit, 128 bit
camada de aplicao de usurio
Freqncia de Operao 868MHz, 902-928 MHz, 2,4 GHz ISM
2,4 GHz ISM
Complexidade Simples Complexo
Topologias de Rede Adhoc, estrela, Adhoc piconets
malha hbrida
Nmero de dispositivos por rede 2 a 65.000 8
Escalabilidade/ Extendabilidade muito alta/ sim baixa/no
Flexibilidade Muito alta Mdia,
dependente do perfil
Elasticidade e confiabilidade Muito alta Mdia

Tabela 2.1: Comparao de caractersticas desejveis entre Bluetooth e ZigBee. Fonte: (BAKER, 2005)
2.2 Comunicao Wireless: Introduo 9

A Tabela 2.1 mostra uma comparao feita por Baker (2005), entre os padres

ZigBee e Bluetooth, das caractersticas desejveis em uma rede wireless, onde AES significa
Advanced Encryption Standard e elasticidade seria o equivalente mobilidade. A freqncia
de operao industrial, cientfica e mdica (ISM) uma freqncia livre.

Sakuragui (2006) diz que:

Redes ad hoc so redes desprovidas de infra-estrutura ou organizao central, com-

postas por dispositivos mveis sem fio que, dada sua mobilidade e liberdade, podem
entrar ou sair da rede de modo aleatrio.

Ainda na tabela 2.1 o termo Piconet refere-se a um tipo de rede ad hoc de disposi-
tivos, que utiliza a tecnologia Bluetooth para permitir que o dispositivo mestre se conecte com
at sete dispositivos escravos ativos.

De acordo com a Tabela 2.1 o ZigBee apresenta as seguintes diferenas mais mar-

cantes em relao ao Bluetooth: tempo de insero de um novo escravo na rede bem menor,
uma complexidade bem menor e um nmero de dispositivos por rede bem mais elevado, entre
outras.

No que se refere alimentao desejvel, para o tipo de aplicao que o ZigBee

engloba, que ela tenha uma longa durao.

O problema de eficincia energtica em um ambiente wireless foi abordado em


Nuggehalli, Srinivasan e Rao (2006), onde se considerou um transmissor wireless como sendo
limitado por seu recurso de bateria finito. O objetivo deste artigo foi desenvolver um esquema

de transmisso que maximizasse a vida til da bateria sujeitando os delays a algumas restries.
Para tal foram exploradas duas idias no conexas:

1. a codificao do canal pode ser usada para conservar energia, transmitindo em nveis de
potncia reduzidos, atravs de intervalos de tempo maiores;

2. uso de mecanismos eletro-qumicos nas baterias, permitindo que elas recuperem energia
durante os perodos de inatividade.
10 2 Comunicao Wireless

Foi atingido um ganho de at 50% com a primeira estratgia e at 90% no segundo

caso.

2.3 Wi-Fi

Em Lansford, Stephens e Nevo (2001) apresentada uma introduo sobre a coe-


xistncia entre Bluetooth e Wi-Fi (dado que os dois operam na mesma banda de freqncia de

2,4GHz), com uma ateno especial para cenrios que requerem uma operao simultnea. O
artigo contm tambm uma explicao bsica sobre os mecanismos de interferncia e quanti-

fica seu impacto atravs de medidas atuais e simulaes. O resultado chave desse trabalho
que enquanto a performance dos dois sistemas pode degradar quando eles so co-alocados, um

nmero de tcnicas pode ser empregado para eliminar virtualmente os problemas, tais como
buscar uma banda de freqncia alternativa (5GHz), ou promover alteraes nas camadas de
controle de acesso ao meio (MAC) ou fsica (PHY).

Em Jindal, Jindal e Gupta (2005) o termo WI FI encontrado com o significado de

wireless fidelity (fidelidade sem fio) e geralmente se refere a qualquer tipo de rede que usa o
padro 802.11, entre eles o 802.11b, o 802.11a e o 802.11g. WI-FI uma tecnologia sem fio

que usa freqncias de radio para transmitir dados.

Em Ferro e Potort (2005) feita uma comparao entre os padres Wi-Fi e Blue-

tooh. Segundo o artigo, o objetivo do padro IEEE 802.11 fornecer a conectividade sem fio
aos dispositivos que requerem uma instalao rpida, tal como computadores portteis, PDAs

(Personal Digital Assistant), ou dispositivos geralmente mveis dentro de uma rede de rea
local sem fio (WLAN). A comparao foi feita em termos de capacidade, topologias de rede,
segurana, suporte a qualidade de servio (QoS) e consumo de potncia. Algumas das carac-

tersticas, como tipos de conexo de dados, performance, topologias, e MAC, esto estveis
e bem definidas pelos padres. Outras, como consumo de potncia, QoS, e segurana, so

desafios ainda em aberto, onde a tecnologia est melhorando continuamente.


2.3 Wi-Fi 11

Os trs tipos de rede citados acima (802.11b, 802.11a e 802.11g) apresentam as

seguintes caractersticas:

802.11b

o tipo de rede de maior alcance, bem suportado, estvel e de melhor relao custo
benefcio. Opera na banda de 2.4 GHz, o que o deixa mais propenso a sofrer in-

terferncia de outros dispositivos (fornos de microondas, telefones sem fio, etc) e


tambm possui desvantagens de segurana;

O nmero de pontos de acesso se limita a trs;

Composto de 11 canais, com 3 no sobrepostos, e possui taxas de 1 a 11Mbps;

Usa a tecnologia DSSS2 (PETERSON; ZIEMER; BORTH, 1995).

802.11g

uma extenso do 802.11b, com as mesmas desvantagens (segurana e interfern-


cia);

Possui um alcance menor que o do 802.11b;

compatvel com o 802.11b, permitindo uma transio suave do 11b para o 11g;

flexvel, pois vrios canais podem ser combinados para uma rpida transferncia,

mas limitado a apenas um ponto de acesso;

Suporta taxas de 54Mbps;

Usa a tecnologia de multiplexao por diviso de freqncia (FDM) (PROAKIS,


2001).

802.11a

completamente diferente do 11b e do 11g;

flexvel porque vrios canais podem ser combinados para uma rpida transferncia
e mais de um canal pode ser utilizado;
2 Direct Sequence Spread Spectrum
12 2 Comunicao Wireless

O alcance menor que o do 11b e do 11g;

Opera na banda de 5GHz, sofrendo uma menor interferncia de outros dispositivos;

Possui 12 canais, sendo 8 no sobrepostos, e suporta taxas de 6 a 54 Mbps;

Usa a tecnologia de multiplexao por diviso de freqncia.

Em Ferrari et al. (2006) apresentada a implementao de uma rede de sensores

utilizando o 802.11. Uma rede mestre-escravo foi proposta, para permitir que vrios sensores
pudessem se conectar com dispositivos Wi-Fi genricos, como PCs. Foram desenvolvidos para

este estudo um protocolo de comunicao sobre IP 3 e alguns prottipos de baixo custo para
testar a performance do comportamento na rede quanto s caractersticas de tempo de latncia

e potncia dissipada. Os resultados para as caractersticas de tempo foram satisfatrios, mas o


consumo de potncia mostrou-se especialmente alto, tornando-se uma grande desvantagem na
rede de sensores utilizando o 802.11.

2.4 Bluetooth

O nome Bluetooth tem sua origem no nome do rei Harald Bluetooth Gormson (911-

986), conhecido como Harald I of Denmark, que foi um rei do sculo 10 que se ocupou com a
diplomacia, facilitando a negociao entre diferentes grupos.

Bluetooth agora mais comumente, refere-se especificao sem fio Bluetooth,

projetada para permitir conexes livres de cabos entre computadores, telefones mveis, PDAs,
impressoras e outros equipamentos eletrnicos. O logo de Bluetooth consiste das runas nrdicas
para suas iniciais, H e B (WIKIPEDIA, 2006a).

Um transceptor Bluetooth um dispositivo FHSS4 (PETERSON; ZIEMER; BORTH,

1995) que usa a freqncia ISM no licenciada de 2,4 GHz. Na maioria dos pases existem 79
canais disponveis, mas alguns pases permitem o uso de apenas 23. A largura de banda nominal

para cada canal de 1MHz.


3 Internet Protocol
4 Frequency Hopping Spread Spectrum
2.4 Bluetooth 13

Segundo Haartsen (1998), Bluetooth uma interface de rdio que permite que dis-

positivos eletrnicos portteis possam se conectar e se comunicar sem fio, com um alcance
limitado em redes ad hoc. Cada unidade pode comunicar simultaneamente com at sete ou-
tras unidades por piconet. Alm disso, cada unidade pode simultaneamente pertencer a vrias

piconets.

McDermott-Wells (2004-2005) explica o conceito de piconet, ja mencionado na


seo 2.2. A especificao do Bluetooth define uma piconet como sendo um agrupamento
espontneo e especfico de dispositivos Bluetooth, ou seja, os dispositivos se conectam automa-

ticamente, criando uma rede sem a necessidade do usurio cri-la. Nessa rede, um dispositivo
assume o papel de mestre, enquanto que os outros dispositivos so escravos, podendo haver um

nmero mximo de sete escravos ativos na piconet.

Salonidis et al. (2001) apresenta uma maneira de construir topologias distribu-


das para redes PANs do tipo Bluetooth, atravs de um protocolo de construo de topologias
Bluetooth. um protocolo distribudo assncrono para a construo de scatternets que come-

am com ns que no possuem conhecimento da sua vizinhana e termina com a formao de


uma rede conectada satisfazendo todas as restries de conectividade propostas pela tecnologia

Bluetooth.

Segundo Zheng e Feng (2002), a tecnologia Bluetooth bastante complexa por ser
principalmente baseada no padro 802.11 e por utilizar o modo ad-hoc. Isto significa que cada
estao deve observar e dar a todas as outras unidades um acesso equivalente mdia sem

fios. Alm disso, Bluetooth uma tecnologia complexa que incorpora tanto hardware quanto
software. Embora dispositivos Bluetooth prometem ser simples e transparentes aos usurios,

eles so completamente complexos e caros para seus programadores. Para criar uma aplicao
Bluetooth completa, programadores precisam desenvolver ou adquirir tanto o hardware quanto
o software. O artigo conclui que o padro Bluetooth deveria ser simplificado para poder tornar

o desenvolvimento de uma interface Bluetooth mais simples e de menor custo.


14 2 Comunicao Wireless

Cordeiro et al. (2003a) apresenta um mtodo para fornecer acesso global a WPANs

Bluetooth utilizando WLANs 802.11. Para isso, faz uso de uma nova arquitetura Bluetooth,
denominada BLUESTAR, segundo a qual so selecionados dispositivos Bluetooth, chamados
Bluetooth Wireless Gateways (BWGs), que tambm possuem o padro IEEE 802.11. Assim

esses BWGs servem de pontos de conexo entre as redes sem fio do padro 802.11 (Wi-Fi) e
Bluetooth.

Cordeiro, Agrawall e Sadok (2003b) fez um estudo sobre a modelagem da interfe-


rncia e a performance do protocolo MAC Bluetooth. Utilizando vrias piconets numa mesma

vizinhana trabalhando na mesma banda de freqncia, empregou um modelo de captura de


sinais para estudar a performance da camada MAC da piconet. Os resultados obtidos indicam

que o rendimento do Bluetooth afetado pela interferncia de vrias piconets.

Um dos problemas do Bluetooth que opera na mesma banda de freqncia do mi-


croondas. Surgiu ento o receio de interferncia do forno de microondas sobre redes Bluetooth.
Para esclarecer essa questo, Rondeau, DSouza e Sweeney (2004) fez um estudo com o intuito

de caracterizar o comportamento do forno de microondas e entender seus efeitos sobre as redes


Bluetooth. Os resultados obtidos foram os seguintes: com dois dispositivos Bluetooth em uma

mesma piconet, a um metro de distncia do forno de microondas, os dados da rede obtiveram


um rendimento de 50% devido interferncia. J a mesma piconet a 10 metros de distncia do

forno no apresentou nenhuma perda devido interferncia no sinal. Aproximando a piconet do


forno, a interferncia no sinal comea a ser percebida apenas a partir de 5 metros, mas mesmo
a um metro de distncia a rede manteve a conexo e apresentou um rendimento aproveitvel.

Em Chakrabarti et al. (2004) apresentado um mtodo de controle de dispositivos

presentes em um ambiente, com Bluetooth habilitado remotamente, na casa ou escritrio, e em


qualquer parte do mundo conectado internet. Para controlar os parmetros dos dispositivos no
ambiente remoto Bluetooth, foi utilizado um applet Java para poder ser acessado por qualquer

navegador que estivesse conectado internet e com Java habilitado.


2.5 ZigBee 15

Em Marsan, Chiasserini e Nucci (2006) apresentado um estudo sobre a determi-

nao de uma topologia tima para as redes PAN baseadas no protocolo Bluetooth. Os resul-
tados mostraram que topologias otimizadas podem ser muito robustas a mudanas na forma
do trfego. Os resultados tambm podem ser usados para encontrar um ponto timo entre a

complexidade do sistema e a eficincia da rede.

2.5 ZigBee

Segundo Norris (2005), ZigBee um novo padro para redes de telemetria sem fio,

otimizadas para baixo consumo de potncia e um longo perodo de operao da bateria. A pilha
protocolar ZigBee tem suporte a rede auto organizvel de dispositivos nas topologias rvore,

malha e estrela, permitindo uma instalao rpida de um sistema de telemetria sem fio interno.

ZigBee um padro de comunicao wireless que prov uma rede de curto alcance

e boa relao custo benefcio. Foi desenvolvido com nfase em aplicaes de baixo custo
alimentadas por bateria, tais como automao predial, controle industrial e comercial, marinha

sem fio, assistncia mdica pessoal e sistemas de tag avanados.

Com um dcimo dos requisitos de memria do Bluetooth e uma frao do poder

de processamento necessrio aos dispositivos de rede 802.11, ZigBee est sendo considerado
como a melhor soluo para sistemas de comunicao de baixa taxa de dados (20 a 250 kbps) e

curto alcance (10 a 100 metros) (STREETON; STANFIELD, 2005).

Segundo Streeton e Stanfield (2005), ZigBee tambm oferece:

Baixo consumo de potncia - otimizado para operao com baterias;

Operao nas bandas no licenciadas de 2.4GHz, 868MHz e 915MHz;

Protocolo simples - pode ser implementado em microcontroladores de baixo custo;

Centenas de dispositivos por rede;

Flexibilidade de rede - configuraes Estrela, rvore ou Malha;


16 2 Comunicao Wireless

Taxa de dados de at 250kbps;

Tamanho do hardware reduzido.

Em Aakvaag, Mathiesen e Thonet (2005) so apresentados os resultados de um

experimento feito com uma rede ZigBee, em uma instalao de automao industrial em uma
companhia de minerao sueca, com o intuito de demonstrar que o novo padro ZigBee se com-

porta bem mesmo em ambientes industriais pesados. Umas das principais observaes feitas foi
que a rede de sensores wireless aparentava estar funcionando satisfatoriamente, mesmo alm da
mxima distncia especificada no padro ZigBee (30m). O ambiente industrial hostil a rdio

aparentemente no estava prejudicando a performance a um grau perceptvel. Um modelo de


sincronizao de tempo simples mostrou ser suficiente para o ciclo ativo da rede. Isto permitiu

um melhor gerenciamento de energia ao custo da reduo do rendimento de toda a rede.

Norris (2005) descreve um sistema de telemetria interno experimental, capaz de


monitorar tags mveis e prover uma assistncia local comum. A pilha ZigBee possui suporte
redes de dispositivos auto-organizveis em todas suas topologias, permitindo uma instalao

rpida de um sistema de telemetria interno. O sistema baseado em uma rede ZigBee semi-
esttica contendo uma mistura de ns wireless estticos e mveis. A rede esttica utilizada

para monitorar os ns mveis, que podem ser associados a pacientes em hospital ou equipa-
mentos de alto valor em um sistema prtico. As caractersticas de auto organizao e auto

recuperao presentes na pilha ZigBee so aproveitadas para traar as posies dos tags mveis
e reorganizar as rotas de dados conforme os tags vo se movendo pelo prdio.

Zhao e Cui (2005) utilizou sensores ZigBee em conjunto com GPRS5 , com o intuito
de realizar medidas de sinais vitais de pacientes e enviar esses sinais a um centro mdico onde

os dados seriam analisados. A concentrao de oxignio no sangue foi medida atravs de um


n desenvolvido e o resultado foi transmitido sem fios at uma estao base, onde a curva em
funo do tempo foi plotada em uma tela LCD6 . O padro mostrou-se eficiente para esse tipo

de aplicao.

5 General Packet Radio Service


6 Liquid Crystal Display
2.6 Consideraes Finais 17

2.6 Consideraes Finais

Este captulo descreve alguns trabalhos relacionados aos padres Bluetooth e ZigBee
para redes sem fio do tipo PAN, e tambm trabalhos relacionados ao padro Wi-Fi para redes

do tipo LAN.

Poucos trabalhos foram encontrados sobre a utilizao do padro Wi-Fi no sen-

soriamento, dado que esse padro no foi criado com esta finalidade. Nesses trabalhos, fica
claro que o consumo de potncia inviabilizaria a utilizao deste padro com a finalidade de

sensoriamento.

O padro Bluetooth mostrou ser complexo e de alto custo de implementao, alm


de sofrer interferncias at mesmo de outras redes Bluetooth colocadas num mesmo ambiente.

Os trabalhos relacionados, ao padro ZigBee, apesar de serem poucos por esse ser
um padro recente, confirmaram que o ZigBee se comporta bem mesmo para ambientes indus-

triais pesados. O tamanho reduzido do hardware, a flexibilidade da rede e a elevada autonomia


de bateria foram fatores amplamente citados nos trabalhos como pontos positivos do padro
ZigBee.
18 2 Comunicao Wireless
19

3 A NORMA 802.15.4 E O PADRO


ZIGBEE

3.1 Consideraes Iniciais

Neste captulo realizada uma reviso aprofundada dos padres ZigBee e 802.15.4

(IEEE-STANDARDS, 2003).

3.2 O Padro ZigBee

3.2.1 Topologias de Rede

Segundo Streeton e Stanfield (2005), a especificao do ZigBee permite que trs


topologias de rede diferentes possam ser implementadas (Figura 3.1), dependendo da aplicao.

So elas: Star (Estrela), Cluster tree (rvore) e Mesh (Malha). Estas topologias so discutidas
a seguir.

Estrela

Na configurao Estrela um dispositivo atua como o coordenador da PAN, o qual se en-

carrega de toda a comunicao em um dado canal de rdio. O coordenador da PAN deve


ser capaz de se comunicar com qualquer outro dispositivo na rede. Essa funcionalidade
existente em um dispositivo de funes completas (FFD) e implementada usando uma

pilha de software de aproximadamente 30Kbytes. Um coordenador de PAN deve estar no


modo de recepo quando ele no estiver transmitindo. Esta unidade provavelmente ir

consumir muita potncia para permitir operao com bateria, e provavelmente dever ter
uma fonte principal de alimentao. Um dispositivo de funes reduzidas (RFD) pode
20 3 A norma 802.15.4 e o padro ZigBee

ser implementado utilizando um microcontrolador de baixo custo e pequena quantidade

de memria. O RFD pode apenas se comunicar com um FFD. Ele dever receber ou
transmitir por um curto perodo de tempo para se tornar adequado para operao com
bateria.

rvore

A topologia rvore formada apenas modificando a topologia Estrela. Um ou mais dos


RFDs conectados ao coordenador da PAN substitudo por um FFD, e destes FFDs, mais
RFDs ou FFDs podem ser conectados. Uma vantagem desta topologia que ela pode ser

usada para aumentar a cobertura geogrfica da rede.

Malha

A terceira topologia suportada pelo ZigBee a Malha. Nessa configurao existe muita

conectividade de uma das FFDs, que est atuando como o coordenador da PAN, com
todas as outras FFDs participantes da rede. As RFDs tambm podem participar da rede,
mas estaro conectadas apenas ao seu FFD pai, e no participam no roteamento. A prin-

cipal vantagem da topologia malha a confiana e rendimento da rede provido atravs do


amplo nmero de caminhos.

Figura 3.1: Topologias de Rede. Fonte: (MALAFAYA; TOMS; SOUSA, 2005)


3.2 O Padro ZigBee 21

Os ns podem ser de trs tipos distintos:

1. Coordenador

O n do tipo coordenador o maior entre os trs, e o que possui uma maior complexi-
dade, dado que ele o responsvel por indicar a ligao entre os ns atravs da Binding

Table, que ser abordada na seo 3.2.7. Este n do tipo FFD.

2. Roteador

Este tipo de n tem uma funo muito importante, a de ampliar o alcance entre determi-
nados End Devices, fazendo com que os mesmos possam se encontrar a uma distncia

maior que a permitida entre dois ns. Este n tambm do tipo FFD.

3. End Device

Os End Devices so os ns que apenas possuem os End Points, que so os atuadores

propriamente ditos, podendo-se citar como exemplo as lmpadas, chaves, sensores de


temperatura, umidade, movimento, dependendo de qual a aplicao. Apenas este tipo
de n RFD.

3.2.2 Pilha Protocolar

A pilha protocolar ZigBee formada pelas camadas PHY e MAC, especificadas


conforme o padro 802.15.4 da IEEE, pela camada de rede (NWK) e pela camada de aplicao,
que contm as sub camadas de suporte aplicao (APS) e ZigBee Device Object (ZDO). Na

estrutura tambm so adicionados os objetos de aplicao definidos pelo usurio. A estrutura


completa mostrada na Figura 3.2 (ONDREJ et al., 2006).

3.2.3 Camada PHY

A camada mais baixa da pilha protocolar, a camada fsica, definida pelo padro

802.15.4 da IEEE, e implementada em silcio.


22 3 A norma 802.15.4 e o padro ZigBee

Figura 3.2: Modelo de camadas da pilha protocolar ZigBee.

A camada fsica codifica os bits que so enviados e decodifica os que so recebidos.


Parte da informao disponvel na camada fsica fornecida para a camada MAC, como por

exemplo, a estimativa de canal livre, a indicao da qualidade da conexo e a indicao da


potncia do sinal recebido.

Segundo Ding et al. (2005) a norma IEEE 802.15.4 define 27 canais na camada
PHY distribudos da seguinte forma:

16 canais com taxa de 250kbps na banda livre ISM 2,4 - 2,4835 GHz disponvel global-
mente;

10 canais com taxa de 40kbps na banda ISM 902 - 928 MHz, disponvel na Amrica do
Norte

1 canal com taxa de 20kbps na banda 868,0 - 868,6 MHz, disponvel na Europa.

Na Figura 3.3 pode-se ver a estrutura dos canais nas 3 bandas diferentes.
3.2 O Padro ZigBee 23

Figura 3.3: Estrutura de canais do IEEE 802.15.4. Fonte:(LEE, 2005)

A camada PHY fornece um parmetro, o indicador de qualidade do link (LQI), que


caracteriza a qualidade do sinal recebido. Pode ser a potncia recebida, a relao sinal rudo
(SNR) estimada, ou a combinao dos dois. O LQI passado para a camada MAC e finalmente

disponibilizado para as camadas superiores da rede. Outras caractersticas da camada PHY


incluem a ativao e desativao do transceptor do rdio, seleo do canal e transmitir/receber

os pacotes atravs do meio fsico.

3.2.4 Camada MAC

A camada MAC controla o acesso ao canal de rdio compartilhado. Ela gera e

reconhece os endereos, e verifica as seqncias das estruturas de controle (frame check).

A camada MAC tambm responsvel por sincronizar as transmisses dos frames

no modo non-beacon1 , usando o mtodo CSMA-CA2 , onde um n verifica a ausncia de tr-


fego antes de iniciar uma transmisso, com o intuito de diminuir a possibilidade de transmisses

simultneas. Depois que o canal encontrado e determinado como livre, o n inicia a transmis-
so. Quando o n suspeita de uma coliso, ele imediatamente para de transmitir e espera um
tempo aleatrio antes de tentar novamente.
1 No sinalizado
2 Carrier Sense Multiple Access with Collision Avoidance
24 3 A norma 802.15.4 e o padro ZigBee

No modo beacon3 existe uma estrutura de superframe (Figura 3.4) opcional, em-

pregada quando uma garantia de acesso ao canal obrigatrio. O superframe inicia com um
beacon e seguido por 16 intervalos de tempo iguais. Os primeiros nove intervalos (CAP) po-
dem ser usados por qualquer dispositivo, e os sete intervalos seguintes (denotados como GTS)

so reservados e podem ser alocados por um dispositivo atravs de um pedido.

Figura 3.4: Estrutura Superframe, Fonte: (ONDREJ et al., 2006)

Na topologia rvore, os beacons nos ns filhos so atrasados, e a retransmisso

dos beacons a partir dos ns filhos feita com uma compensao no tempo de transmisso.
Na topologia malha, os beacons no so suportados e no podem ser usados como meios de

sincronizao.

Segundo Lee (2005) o mecanismo para transferncia de dados depende se a rede su-
porta ou no a transmisso de beacons. Uma rede com beacon habilitado usada para dispositi-
vos de baixa latncia, tais como perifricos de PC. Se a rede no necessita estar preparada para

este tipo de dispositivo, pode-se optar por no utilizar o beacon para transferncias normais.

H dois modos de transferncia de dados:

Transmisso de dados direta: Este tipo de transferncia de dados o mecanismo para

transferir dados do dispositivo para o coordenador. Na rede com o beacon habilitado,


3 Sinalizado
3.2 O Padro ZigBee 25

quando um dispositivo deseja transferir dados ao coordenador, ele primeiro espera rece-

ber um beacon da rede, como mostrado na Figura 3.5 (a). Quando o beacon recebido,
o dispositivo sincroniza-se com a estrutura de superframe. Na hora apropriada, o disposi-
tivo transmite seu frame de dados ao coordenador. O coordenador confirma a recepo do

dado com sucesso, transmitindo um frame de confirmao. Por outro lado, em redes com
beacon no habilitado, quando um dispositivo deseja transferir dados, ele simplesmente

transmite seu frame de dados ao coordenador. O coordenador confirma a recepo do


dado com sucesso, transmitindo um frame de confirmao, como mostrado na Figura 3.5
(b).

Figura 3.5: Transmisso direta em redes (a) beacon habilitado, e (b) beacon no habilitado.
Fonte: (LEE, 2005)

Transmisso de dados indireta: Este tipo de transferncia de dados o mecanismo para


transferir dados do coordenador para o dispositivo. Em uma rede com o beacon habi-

litado, quando o coordenador deseja transferir dados para um dispositivo, ele indica no
beacon da rede que existe uma mensagem pendente. O dispositivo periodicamente ouve

o beacon da rede e, se houver mensagem pendente, transmite um comando MAC pedindo


o dado. O coordenador confirma a recepo da requisio do dado com sucesso, transmi-
tindo um frame de confirmao. O frame de dado pendente ento enviado. O dispositivo

confirma a recepo do dado com sucesso, transmitindo um frame de confirmao. Assim


que a confirmao recebida, a mensagem removida da lista de mensagens pendentes

no beacon. Esta seqncia mostrada na Figura 3.6 (a). Por outro lado, em uma rede
com o beacon no habilitado, o dado armazenado at que o dispositivo apropriado faa
26 3 A norma 802.15.4 e o padro ZigBee

contato e requisite o dado. Um dispositivo pode fazer contato enviando um comando

MAC, requisitando o dado ao coordenador, em uma taxa de pooling4 definida pela apli-
cao, como mostrado na Figura 3.6 (b). O coordenador confirma a recepo do frame
de dados com sucesso, transmitindo um frame de confirmao. Se o dado est pendente,

o coordenador transmite o frame de dados para o dispositivo. Se o dado no est pen-


dente, o coordenador transmite um frame de dados com um cabealho de comprimento

zero, para indicar que no existem dados pendentes. O dispositivo confirma o sucesso da
recepo dos dados transmitindo um frame de confirmao.

Figura 3.6: Transmisso indireta em redes (a) beacon habilitado, e (b) beacon no habilitado.
Fonte: (LEE, 2005)

3.2.5 Camada de Rede

A camada de rede (NWK) cuida do nvel de rede relativo comunicao. Controla a


estrutura de rede e cuida do roteamento e das funes de segurana das mensagens transmitidas.
A rede ZigBee uma rede dinmica e a camada de rede precisa manter as informaes sobre os

ns dentro da rede. As propriedades e parmetros da rede so especificados na aplicao como


configuraes de pilha da camada de rede. Isto inclui a topologia, segurana, etc.

4 verificao
3.2 O Padro ZigBee 27

3.2.6 Camada de Aplicao

A camada de aplicao carrega o cdigo de cada aplicao feita individualmente.


De acordo com a especificao ZigBee, este cdigo escrito dentro do objeto do dispositivo
ZigBee (ZDO) e a funo do dispositivo especificada. Aqui definido se o dispositivo ser

do tipo FFD ou RFD, as funes de segurana de rede, as resposta e atos para cada evento do
sistema.

A sub camada de suporte aplicao (APS) forma o nvel baixo da camada de


aplicao. Aqui onde as ligaes (binding) e a descoberta da vizinhana dos dispositivos so

feitas. A APS tambm responsvel por encaminhar as mensagens atravs dos dispositivos que
no esto habilitados para se comunicarem diretamente, e habilita a funcionalidade de modificar

a rede para uma rede do tipo malha.

3.2.7 Binding e Binding Table

Existem dois tipos de mensagem, as do tipo KVP5 , onde cada n conhece o en-
dereo do n destino, e a do tipo MSG6 , onde necessrio que seja feita e armazenada uma

ligao entre dois End Points.

Na Figura 3.7, onde AF significa Application Framework, pode-se ver como mon-
tada a mensagem ZigBee.

5 Key-Value Pair
6 Message Service Type
28 3 A norma 802.15.4 e o padro ZigBee

Figura 3.7: Formato da mensagem ZigBee


3.2 O Padro ZigBee 29

importante lembrar que os End Points podem ser lmpadas, sensores de movi-

mento ou temperatura, entre outros. Um n pode ter mais de um End Point, como pode ser
visto na Figura 3.8 (ZIGBEE-ALLIANCE, 2005).

O n Z1 possui duas chaves (switchs), que na rede so os End Points EP3 e EP21,
enquanto que o n Z2 possui 4 lmpadas, EP5, EP7, EP8 e EP17.

A Binding Table responsvel por fazer a conexo entre os End Points. Ainda
na Figura 3.8, nota-se que a chave 1 (EP3) est ligada s lmpadas 1(EP5), 2(EP7) e 3(EP8),

enquanto que a chave 2 (EP21) est ligada lmpada 4(EP17).

Existem tambm ns ZigBee que possuem chaves e lmpadas, ou lmpadas e sen-


sores. Nem sempre o n ZigBee possuir apenas sensores ou atuadores, ele pode ser de vrias

formas diferentes, dependendo da aplicao em que ele estiver inserido.

Figura 3.8: Binding e Tabela de Binding. Fonte: (ZIGBEE-ALLIANCE, 2005)


30 3 A norma 802.15.4 e o padro ZigBee

3.3 Consideraes Finais

As opes de configurao disponveis em uma rede ZigBee um de seus pontos


fortes, o que a deixa parte de alguns dos padres competidores, cujos protocolos torna-os

menos flexveis. Dessa forma o ZigBee satisfaz a necessidade de muitas aplicaes existentes
e certamente de outras que surgiro, mas sempre haver lugar para solues mais customizadas
em reas mais especficas (STREETON; STANFIELD, 2005).
31

4 TRABALHO DESENVOLVIDO

4.1 Consideraes Iniciais

Nesse captulo so apresentadas as funes implementadas no projeto de senso-


riamento, a metodologia que foi adotada e uma breve descrio das ferramentas que foram

utilizadas na criao e validao do software.

4.2 Funes Implementadas

No desenvolvimento do hardware e do software do projeto de sensoriamento foram


implementadas as quatro funes seguintes:

1. Leitura de um sensor de movimento em um n, enviando ao outro uma mensagem. Esse


segundo n aciona um sinalizador acstico, indicando que o sensor foi acionado;

2. Leitura de um sensor de temperatura em um n e, dependendo do intervalo de temperatura


selecionado, enviada uma mensagem ao outro n indicando se deve ligar ou desligar um

aparelho de ar condicionado (LED);

3. Leitura de um sensor de luminosidade (LDR) e, dependendo do valor encontrado, enviar


uma mensagem indicando se uma lmpada no outro n deve ser apagada, acesa a 40%,
acesa a 60% ou acesa a 100% de sua carga mxima;

4. No Hyperterminal mostrado o valor medido da temperatura e o valor lido pelo sensor

de luminosidade (LDR), comunicando-se com o PC via USB, atravs da placa de circuito


impresso (PCI) extra desenvolvida.
32 4 Trabalho Desenvolvido

Os desafios do trabalho foram: desenvolver o software que faz o controle dos sen-

sores e atuadores e implementar e validar o hardware referente a cada uma das quatro etapas de
desenvolvimento citadas anteriormente.

Foram utilizados dois ns ZigBee. Um deles (Figura 4.1) possui interface USB
para se comunicar com um PC, um sensor de luminosidade (LDR), um sinalizador acstico,

que simula uma sirene e um sensor de temperatura, atravs do qual o n decide a hora de ligar
ou desligar o aparelho de ar condicionado.

Figura 4.1: Diagrama de blocos do n do tipo coordenador.

Um segundo n ZigBee (Figura 4.2) possui uma lmpada, que acionada de acordo
com o sinal obtido no LDR do primeiro n, um LED, que simula um aparelho de ar condicio-

nado, apenas para indicar que ele foi acionado ou no, e um sensor de movimento, que quando
acionado faz com que o sinalizador acstico do outro n dispare.

4.3 Metodologia

A primeira fase desse trabalho consistiu no estudo da pilha protocolar ZigBee, pelo
fato deste ser um padro de comunicao wireless recente e pouco estudado.
4.3 Metodologia 33

Figura 4.2: Diagrama de blocos do n do tipo RFD.

A segunda fase deste trabalho constituiu na implementao e validao dos hardwa-


res descritos no item 4.2 e na implementao e validao da parte de comunicao e do software

implementado para realizar as funes descritas.

4.3.1 Comunicao Entre os Ns

Para a comunicao entre os ns foi desenvolvido um software, onde foram utiliza-


das funes desenvolvidas pela Microchip (2006a), que fazem parte da chamada ZigBee Stack,

ou pilha ZigBee. Algumas da funes utilizadas so:

HardwareInit()

Inicializa o hardware. Seleciona quais portas sero utilizadas como entrada ou sada, qual
o estado de cada uma delas na inicializao, inicializa o barramento de comunicao SPI

(Serial Peripheral Interface), entre outras coisas.

ZigBeeInit()

Inicializa a pilha ZigBee. Inicializa as camadas MAC, NWK, APS e ZDO.

ConsoleInit()
34 4 Trabalho Desenvolvido

Inicializa a UART (Universal Assynchronous Receiver Transmitter).

O formato de mensagem utilizado foi o KVP, onde cada n sabe o endereo do


outro, consequentemente no foi utilizada a tabela de ligaes (binding table). Tambm no foi

utilizado o beacon na comunicao.

4.3.2 Implementao e Validao do Hardware

Foi inserido em cada placa do kit de desenvolvimento, na rea disponvel para mon-

tagens, um hardware extra, que nas Figuras 4.1 e 4.2 ilustrado como mdulos adicionais
conectados ao microcontrolador. Abaixo segue uma breve descrio do hardware que foi im-
plementado e testado.

USB

O chip utilizado nesse item foi o FT232BL. Optou-se por criar uma PCI separada para o
hardware USB devido principalmente ao tamanho dos componentes.

RTC (Real Time Clock)

O chip utilizado foi o DS1305. Este item possui duas implementaes, o hardware e o

software. O hardware foi montado e validado, mas o software no funcionou como era
esperado em conjunto com a pilha ZigBee. A discusso feita no item 5.3.8.

Sensor de temperatura

Foi utilizado um sensor de temperatura digital acessado serialmente, que j estava pre-
sente no prprio kit de desenvolvimento da Microchip, o TC77.

Sensor de movimento

Foi utilizado um sensor de movimento que detecta a variao de infravermelho, desen-

volvido pela empresa ICCEA.

Sensor de luminosidade (LDR)

Foi utilizado um LDR de 200k .


4.4 Ferramentas de Desenvolvimento 35

Sinalizador acstico

Foi escolhido um sinalizador acstico da marca HXD de 5V, mas que funcionou bem em
3V3.

LED (simulando um aparelho de ar condicionado)

Lmpada

O acionamento da lmpada foi implementado com um triac. Para evitar algum dano a
uma das placas do kit, optou-se por montar o circuito em um protoboard.

4.4 Ferramentas de Desenvolvimento

Foi utilizado para o desenvolvimento do projeto, um kit da Microchip, denominado


PICDEM Z Demonstration Kit (MICROCHIP, 2006b), mostrado na Figura 4.3. Este kit

composto por duas PCIs PICDEM Z, onde cada uma delas contm:

Um microcontrolador PIC18LF4620 com tecnologia nanoWatt, 64 KB de memria Flash


e perifricos integrados;

Transceptor de rdio freqncia (RF) e interface de antena em uma placa separada visando
flexibilidade;

Interface serial no padro RS232;

Regulador de tenso de 9V para 3.3V;

Sensor de temperatura (Microchip TC77), LEDs e chaves de pulso para permitir demons-
traes.

Foram adquiridas duas fontes de 9V para serem utilizadas com as placas do kit

PICDEMZ, pois devido ao alto consumo de corrente durante a gravao dos PICs, as baterias
tiveram uma vida til muito reduzida, da ordem de uma semana.
36 4 Trabalho Desenvolvido

Figura 4.3: Placa PICDEM Z com placa de RF acoplada. Fonte: (MICROCHIP, 2006b)

Alm do kit descrito acima, foi utilizado o ambiente de desenvolvimento integrado

da prpria Microchip, denominado MPLAB IDE (MICROCHIP, 2006c). Neste ambiente foi
desenvolvido o software que foi gravado nas memrias internas aos microcontroladores dos kits
de desenvolvimento (PIC18LF4620).

O software foi escrito em linguagem C.

O compilador utilizado foi o C18 (MICROCHIP, 2006d), tambm da Microchip,

especfico para os microcontroladores PIC da famlia 18.

Para a gravao dos microcontroladores foi utilizado o gravador/depurador ICD2BR,

comercializado pela LabTools (LABTOOLS, 2006).

4.5 Consideraes Finais

Com as funes implementadas possvel simular sensores e atuadores utilizados

em uma residncia. A metodologia foi elaborada de forma a assegurar o funcionamento do


hardware e do software.
37

5 DESCRIO, RESULTADOS E
DISCUSSES

5.1 Consideraes Iniciais

Nesse captulo apresentada a descrio do projeto de sensoreamento, os resultados


e as discusses.

Ser feita uma descrio da lgica dos sensores e da USB, do hardware e do soft-
ware implementados.

5.2 Descrio da Lgica dos Sensores e da USB

A Figura 5.1 d uma viso melhor de qual sensor responsvel por qual atuador,

onde as setas indicam a direo de propagao da informao.

Figura 5.1: Trabalho Desenvolvido


38 5 Descrio, Resultados e Discusses

5.2.1 Sensor de Temperatura

A lgica para o acionamento do ar condicionado (LED) a seguinte: foram delimi-


tados dois patamares de temperatura, 35oC e 45oC. Quando a temperatura mensurada no sensor

de temperatura (TC77) do n do tipo coordenador est acima do patamar superior (45oC),


o n do tipo coordenador envia uma mensagem para o n do tipo RFD indicando que o ar
condicionado deve ser ligado. O ar condicionado permanece ligado at que a temperatura fique

abaixo dos 35oC. Quando a temperatura estiver abaixo do patamar inferior, o n do tipo coor-
denador envia uma mensagem ao n do tipo RFD indicando que o ar condicionado deve ser

desligado. O ar condicionado s religado quando a temperatura passar novamente dos 45oC.

Os valores de 35oC e 45oC foram escolhidos para testes e so pr-estabelecidos em


software, mas nada impede que futuramente se crie um modo de alterar esses valores, utilizando
o software hyperterminal, por exemplo, para a entrada desses valores.

5.2.2 Sensor de Movimento

O tempo de inicializao do sensor de movimento varia de 40 a 60 segundos. De-


vido a isso, o n do tipo RFD deve aguardar 60s antes de entrar em sua rotina de funcionamento

normal. Isso deve ser feito para garantir que o sensor de movimento tenha sido inicializado cor-
retamente.

Aps essa inicializao, quando o sensor de movimento acionado, o n do tipo


RFD envia uma mensagem ao n do tipo coordenador, indicando que o sinalizador acstico

deve ser acionado. Quando o sensor no mais detecta movimento, enviada uma mensagem ao
n do tipo coordenador indicando que o sinalizador acstico deve deixar de ser acionado.

5.2.3 Sensor de Luminosidade

O sensor de luminosidade funciona da seguinte forma:

Luminosidade VRA3 RLDR


5.2 Descrio da Lgica dos Sensores e da USB 39

Ou seja, quanto menor a luminosidade no ambiente, maior o valor da resistncia

do sensor de luminosidade, e consequentemente menor a tenso lida pelo conversor analgico


digital(ADC) da porta RA3.

Com os valores de tenso (0V e 3V3) e resistncia (200k para o LDR e 33k para
o resistor) utilizados, chegamos aos seguintes valores digitalizados lidos pelo conversor AD:

993

Este valor foi lido quando obtida a maior luminosidade possvel no ambiente.

Este valor foi lido com a menor luminosidade possvel no ambiente.

Para a lgica utilizada no acionamento da lmpada, foram estipulados trs patama-

res:

300;

500;

700.

E criados quatro estados para a lmpada:

apagado;

aceso a 40%;

aceso a 60%;

aceso a 100%.

De posse desses valores, foi criada a lgica a ser utilizada no algoritmo. Se a leitura
do conversor AD for maior que 700, a lmpada deve estar apagada. Se a leitura for um valor
40 5 Descrio, Resultados e Discusses

entre 500 e 700, a lmpada deve estar acesa a 40% de sua carga mxima. Se a leitura for

um valor entre 300 e 500, a lmpada deve estar acesa a 60%, e finalmente, caso a leitura do
conversor AD for um valor abaixo de 300, a luz deve estar acesa a 100% de sua carga mxima.
Sendo assim, quanto menor a luminosidade no ambiente lido pelo conversor AD, maior o grau

de luminosidade da lmpada.

5.2.4 USB

O intuito inicial foi desenvolver um hardware para a USB equivalente ao hardware


para RS232 existente na placa do kit PICDEM Z. Esse hardware seria montado no n do tipo
coordenador. Na busca pelo hardware, foi encontrado apenas um transceptor RS232-USB com

encapsulamento SMD. Devido dificuldade de manuseio de componentes SMD, surgiu a idia


de se criar uma PCI externa que tivesse a funcionalidade de comunicao USB e que pudesse ser

facilmente conectada ao hardware do kit PICDEM Z. Foi ento concebida essa PCI, de forma
a permitir a seleo entre trs modos diferentes. Dentre eles, o principal o USB-TTL. Neste
modo, pode-se conectar os fios RX, TX e GND na placa USB desenvolvida e comunicar com o

PC atravs da porta USB. O funcionamento desta placa ser melhor descrito na seo 5.3.4.

5.3 Descrio do Hardware

5.3.1 PICDEM Z

Para iniciar a montagem do hardware extra nas placas do kit de desenvolvimento,


foram colocados algumas barras de pino torneado a fim de transformar a rea livre em algo mais

parecido com um protoboard. As Figuras 5.2 e 5.3 mostram, respectivamente, as partes superior
e inferior de uma das placas do kit aps a adequao para a utilizao no desenvolvimento.

Os componentes agora podem ser apenas encaixados na placa, ao invs de soldados,


o que alm de deixar a montagem mais rpida e simples ainda aumenta a vida til da rea de

montagem, evitando a necessidade de soldas a cada troca de componente e consequentes danos


s ilhas, que seriam inevitveis.
5.3 Descrio do Hardware 41

Figura 5.2: PICDEM Z adequado para o desenvolvimento.

Figura 5.3: Parte inferior do PICDEM Z aps adequao.


42 5 Descrio, Resultados e Discusses

5.3.2 Sensor de Temperatura

O sensor de temperatura utilizado foi o TC77, por j fazer parte do hardware do kit.
Este sensor se comunica com o PIC via barramento de comunicao SPI. A Figura 5.4 mostra

o esquema eltrico do sensor de temperatura. A Figura 5.5 mostra o sensor de temperatura


implementado pela microchip no kit PICDEM Z.

Figura 5.4: Circuito do Sensor de Temperatura. Fonte: (MICROCHIP, 2004e)

Figura 5.5: Localizao do TC77 no kit PICDEM Z.


5.3 Descrio do Hardware 43

5.3.3 Sensor de Luminosidade e Sinalizador Acstico

O esquema eltrico do circuito implementado para o sensor de luminosidade pode


ser visto na Figura 5.6(a), enquanto que o esquema eltrico do circuito implementado para o
sinalizador acstico pode ser visto na Figura 5.6(b). Na Figura 5.7 pode-se ver o hardware

implementado para o sensor de luminosidade (LDR) e para o sinalizador acstico.

(a) (b)

Figura 5.6: (a) Circuito do LDR implementado, (b) Circuito do Sinalizador Acstico imple-
mentado.

O circuito do LDR um circuito simples e consiste apenas de um LDR de 200k


e um resistor de 33k . A porta do PIC do n do tipo coordenador utilizada foi a entrada
analgica RA3.

O circuito do sinalizador acstico ainda mais simples, como pode ser visto na

Figura 5.6(b). Uma das extremidades do sinalizador acstico conectada tenso de referncia
positiva do circuito (no caso 3,3V), e a outra extremidade conectada porta RA5 do PIC do

n do tipo coordenador, utilizada como sada digital. Nessa mesma extremidade conectado
um resistor (R1) de 470 . A outra extremidade desse resistor conectada em 3,3V. Esse
resistor denominado resistor de pull up. Esse resistor serve para manter a tenso na porta do

PIC em nvel lgico alto, evitando que a porta fique com um valor desconhecido e, provocando
eventuais acionamentos indevidos do hardware que est conectado na porta do PIC, nesse caso,

o sinalizador acstico. O sinalizador acstico acionado quando a porta RA5 do PIC estiver
em nvel lgico baixo (no caso 0V).
44 5 Descrio, Resultados e Discusses

Figura 5.7: Sensor de Luminosidade e Sinalizador Acstico.

5.3.4 USB

Como o transceptor USB-RS232 escolhido (FT232) possui encapsulamento SMD,


optou-se por criar uma placa onde houvesse um conector que pudesse ser ligado diretamente
aos pinos de RX e TX do PIC e o GND do circuito da PCI do PICDEM Z, de modo a permitir a

comunicao do PIC com o PC atravs do transceptor FT232, equivalente ao que j feito com
o transceptor MAX3221 no kit PICDEM Z.

Pode-se ver na Figura 5.8 a placa que foi desenvolvida. Na parte superior direita da

placa existem trs leds, onde o primeiro (superior) indica se a placa est alimentada (via USB
ou RS232), o segundo indica o fluxo de dados recebidos atravs da USB e o ltimo indica o
fluxo de dados enviados atravs da USB.

Para um melhor aproveitamento de tempo e recursos, a placa foi desenvolvida com

o intuito de permitir trs modos distintos de operao, que so os seguintes:


5.3 Descrio do Hardware 45

Figura 5.8: Placa USB-RS232-TTL desenvolvida.

1. USB - RS232

Este modo o mesmo utilizado nos cabos comerciais USB-Serial encontrados em lojas

de informtica.

2. USB - TTL

Este modo dispensa um transceptor RS232, conectando diretamente o PIC ao PC atravs


do transceptor USB (FT232), como pode ser visto na Figura 5.9.

3. RS232 - TTL

Este modo equivalente ao que j est implementado no kit PICDEM Z, que faz com que
o PIC comunique-se com o PC atravs de um transceptor RS232 (MAX3221).

5.3.5 Sensor de Movimento

A Figura 5.10 mostra o circuito que foi montado para poder isolar o sensor de

movimento do resto do circuito, de modo a no deixar que o sensor causasse algum tipo de
interferncia. Na Figura 5.11 pode-se ver um sensor de movimento desenvolvido pela ICCEA.
46 5 Descrio, Resultados e Discusses

Figura 5.9: Conexo da placa USB no modo USB - TTL.

Figura 5.10: Circuito implementado para leitura do sensor de movimento.

Figura 5.11: Sensor de Movimento da ICCEA.


5.3 Descrio do Hardware 47

Ainda na Figura 5.11 pode-se ver que o sensor de movimento da ICCEA possui

um led externo com a funo de indicar o acionamento do sensor de movimento. O sensor de


movimento est na porta RA5 do n do tipo RFD, como pode ser visto no esquema eltrico do
sensor de movimento na Figura 5.12.

Figura 5.12: Circuito do Sensor de Movimento implementado.

5.3.6 Led

Devido utilizao do comparador no n do tipo RFD, no foi possvel utilizar

os dois leds j implementados na placa do kit PICDEM Z utilizada. Portanto foi necessrio
conectar um LED porta RD0, cuja funcionalidade servir de referncia visual, ao invs de se

criar um acionamento de um ar condicionado. A Figura 5.13 mostra o circuito utilizado para a


implementao.

Figura 5.13: Circuito do LED implementado.


48 5 Descrio, Resultados e Discusses

5.3.7 Lmpada

No caso de acionamento de uma lmpada, por se tratar de uma tenso AC e elevada,

a fim de evitar algum dano a alguma das placas do kit de desenvolvimento, o circuito de acio-
namento da lmpada foi montado em um protoboard que foi conectado ao n do tipo RFD. A

Figura 5.14 mostra o circuito implementado para o acionamento da lmpada.

Figura 5.14: Circuito de acionamento da lmpada.

O triac (componente X1 da Figura 5.14) o responsvel pelo acionamento da lm-

pada. necessrio enviar um pulso no gate do triac para que o acionamento seja realizado (pino
RE1 do PIC). Para que esse pulso fosse dado no momento certo, foi necessrio implementar um
detector de zero do sinal de tenso da rede (pino RA0 do PIC) que, na Figura 5.14, composto

pelos componentes C1, D2, D3, R6, R7 e R8. A Figura 5.15 mostra o circuito que foi utilizado
como referncia para o comparador (pino RA3 do PIC).

Figura 5.15: Circuito de referncia para o comparador.


5.3 Descrio do Hardware 49

5.3.8 Real Timer Clock (RTC)

Na Figura 5.16 pode-se ver o esquema eltrico do circuito implementado para o


RTC. J a Figura 5.17 abaixo mostra uma foto do hardware implementado para o Real Timer
Clock no n do tipo coordenador.

Figura 5.16: Circuito do RTC implementado.

O hardware do RTC funcionou muito bem com um software desenvolvido apenas

para testar seu funcionamento. Ao tentar integrar este software com a pilha ZigBee, ocorreu
uma certa incompatibilidade no barramento de comunicao SPI. O barramento de comunica-
o SPI utilizado pelo transceptor ZigBee (CC2420), pelo sensor de temperatura (TC77) e

pelo RTC (DS1305).

O transceptor ZigBee funciona a quatro fios, ou seja, o transceptor utiliza os pinos


de clock (CLK), chip enable (CE), serial data in (SDI) e serial data out (SDO), enquanto que

o Real Timer Clock (DS1305) pode funcionar de duas formas distintas:


50 5 Descrio, Resultados e Discusses

Figura 5.17: Real Timer Clock.

3 fios

Os trs fios so o clock, o chip enable e o pino de entrada e sada de dados (SDI/O), ou

seja, o DS1305 teria seus pinos de entrada e sada de dados (SDI e SDO respectivamente)
curto circuitados. Para tal funcionamento, deveriam ser tambm curto circuitados os pinos

de entrada e sada de dados do PIC18LF4620, e caso isso fosse feito, o transceptor no


funcionaria corretamente.

SPI Motorola

Esta segunda forma foi a testada, como mencionado anteriormente, e funcionou como

o esperado sem a pilha ZigBee. Em conjunto com a pilha ZigBee apresentou algumas
falhas no funcionamento. Para que o RTC funcionasse corretamente seria necessrio que
o transceptor fosse inibido e o RTC habilitado quando fosse realizar a leitura do RTC,

e aps a leitura, o RTC teria de ser inibido e o transceptor habilitado novamente. Isto
tambm no seria possvel, pois a cada vez que o transceptor do n do tipo coordenador

fosse inibido, a rede entraria em colapso, pois para a rede seria como se o coordenador
no estivesse presente.
5.4 Descrio do Software 51

Desta forma observa-se que no h como utilizar o RTC no n do tipo coordena-

dor. Poderia se utilizar, ao invs disso, o RTC no n do tipo RFD, mas o funcionamento seria
o mesmo descrito anteriormente, e isso iria sem dvida desgastar bastante a bateria do n.

O sensor de temperatura (TC77) funciona com o barramento SPI a 3 fios, mas como
no necessrio enviar nenhum dado ao sensor na aplicao, e apenas ler dados, os pinos de

entrada e sada de dados do sensor de temperatura foram conectados apenas ao pino de entrada
de dados do microcontrolador (SDI).

5.4 Descrio do Software

5.4.1 Pilha ZigBee

Foi utilizado no trabalho, a verso 1.0-3.6 da pilha ZigBee fornecida pela Microchip
para download gratuito (MICROCHIP, 2006a). Nessa verso algumas funes foram melhor
organizadas e, para inicializar a pilha ZigBee, basta chamar a seguinte funo:

// Initialize the ZigBee Sta k.


ZigBeeInit();

A funo ZigBeeInit() est localizada no arquivo ZigBeeTasks.c, e entre outras ini-


cializaes, chama as seguintes funes:

MACInit();
NWKInit();
APSInit();
ZDOInit();

As funes acima so responsveis por inicializar, respectivamente, as camadas

MAC, NWK, APS e ZDO. Algumas das funes que existiam em verses anteriores da pilha
ZigBee da Microchip mantiveram sua funcionalidade. Abaixo so citados alguns exemplos.

#define APLEnable() MACEnable()


#define APLDisable() MACDisable()
#define APLGet() APSGet()
52 5 Descrio, Resultados e Discusses

As funes acima, na coluna da direita, por possuirem a mesma funcionalidade que

as funes da esquerda em verses antigas da pilha ZigBee, podem ser chamadas do modo
antigo (coluna da esquerda), de modo a facilitar a migrao do software para uma nova verso
da pilha. Isto o que faz as linhas de comando #define acima, retiradas do arquivo zAPL.h.

5.4.2 Software Desenvolvido

A Figura 5.18 representa o diagrama em blocos do funcionamento do arquivo prin-

cipal do n do tipo coordenador, enquanto que a Figura 5.19 representa o digrama em blocos
do arquivo principal do n do tipo RFD.

O software desenvolvido est detalhado no apndice A.

5.5 Resultados e Discusses

Quatro funes foram implementadas neste projeto de monitorao e sensoriamento.

A primeira, que foi o sensor de movimento em conjunto com o Buzzer, funcionou sem problema
algum. Cada vez que o sensor de movimento no n do tipo RFD acionado, a mensagem

enviada com sucesso para o n do tipo coordenador, onde o Buzzer aciona, e quando o sensor
de movimento deixa de detectar movimento, a mensagem que indica que o Buzzer deve deixar
de ser acionado tambm enviada com sucesso.

A segunda funo, que coompreende o sensor de temperatura e o LED, tambm

funcionou corretamente, acionando o LED quando a temperatura do n do tipo coordenador


supera o patamar superior de temperatura e desligando o LED quando a temperatura baixa

do patamar inferior. A terceira funo, que compreende o sensor de lumiosidade (LDR) e


o acionamento da lmpada tambm obteve xito. Quanto menor o grau de luminosidade do
ambiente, maior a porcentagem da carga da lmpada utilizada. Essa porcentagem da carga

mxima pode ser de 0%, 40%, 60% ou 100%.

A quarta funo funcionou corretamente no modo empregado (USB-TTL), mas pos-


sui dois erros de layout que precisam ser corrigidos, e s ocorrem no modo (RS232-TTL). O
5.5 Resultados e Discusses 53

primeiro que para se utilizar o hardware USB nesse modo, torna-se necessrio que a alimen-

tao venha via TTL, pois nesse caso o conector USB no estar conectado, e a tenso positiva
no foi prevista no conector. O segundo erro que da forma como o jumper de seleo foi con-
cebido, ao selecionar o modo RS232-TTL, o pino de RX do PIC fica conectado onde deveria

estar conectado o pino de TX, e vice-versa.

Uma quinta funo que seria implementada e foi testada sem sucesso a implemen-
tao de um Real Timer Clock no n do tipo coordenador. Os componentes que utilizam o
barramento de comunicao SPI so: o transceptor ZigBee, o sensor de temperatura e o RTC.

O problema encontrado foi que o transceptor e o RTC no poderem trabalhar simultaneamente,


no momento em que um estivesse sendo utilizado, o outro no poderia estar habilitado. Como

o transceptor ZigBee do n do tipo coordenador no pode ser desligado, torna-se impossvel


a utilizao do RTC escolhido em conjunto com a pilha ZigBee utilizada, disponibilizada pela

Microchip.

Figura 5.18: Fluxograma do n do tipo coordenador.


54 5 Descrio, Resultados e Discusses

Figura 5.19: Fluxograma do n do tipo RFD


55

6 CONCLUSES

6.1 Concluses

A proposta do projeto avaliar o padro sem fio ZigBee para sensoriamento de

ambientes. Para tal foi implementada uma aplicao com o kit PICDEM Z contendo sensores
e atuadores, baseados numa rede ZigBee. Essa implementao mostrou que o padro ZigBee

eficiente para a monitorao e sensoriamento de ambientes.

Foi testado com sucesso a comunicao entre os dois ns a 15 metros de distncia


um do outro e com duas paredes entre eles, o que era esperado, pois a especificao diz que o
padro ZigBee possui um alcance de at 100m em ambiente externo e at 30m em ambiente

fechado.

O consumo de corrente do n do tipo coordenador no ultrapassou 30mA durante


o funcionamento, o que est de acordo com o esperado. A corrente em modo de sleep no pode
ser mensurada, pois o n do tipo RFD no pode entrar neste modo, devido maneira como o

acionamento da lmpada realizado.

A quantidade de recursos necessria para implementar um n ZigBee, apenas con-


siderando a pilha ZigBee, foi 32kB no caso do n do tipo coordenador e 14kB no caso do n

do tipo RFD.

O nico imprevisto que ocorreu foi na implementao do RTC, que no funcionou

corretamente quando foram includas as funes do RTC no programa que j estava funcionando
com a pilha ZigBee.
56 6 Concluses

6.2 Contribuies

Como o ZigBee um padro recente e pouco estudado, este trabalho representa uma
contribuio para aqueles interessados em desenvolver aplicaes que utilizem esse padro.

Outra contribuio importante est relacionada com o RTC. O RTC utilizado na


aplicao foi o DS1305, que se comunica com o PIC via barramento SPI. Este RTC no funcio-

nou corretamente devido ao modo como o barramento SPI utilizado pelo transceptor ZigBee.
A explicao se encontra na seo 5.3.8. Cabe ressaltar que o hardware implementado para o

RTC foi testado e funcionou corretamente sem a pilha ZigBee. Essa informao importante
para aqueles que pretendem incluir um RTC em seu projeto.

6.3 Proposta para Trabalhos Futuros

Uma proposta a de implementar um prottipo como produto final e realizar a


avaliao deste em ambientes residenciais.

Outra proposta utilizar, ao invs do kit PICDEM Z, um hardware chamado PIXIE,


da Flexipanel (2006), cujo hardware compatvel com o do PICDEM Z e com a pilha ZigBee

fornecida gratuitamente pela Microchip, de modo a reduzir consideravelmente o tamanho dos


ns. Podemos ver uma foto do PIXIE na Figura 6.1.

Figura 6.1: PIXIE.


6.3 Proposta para Trabalhos Futuros 57

Pode-se utilizar tambm um outro microcontrolador PIC, no lugar do PIC18LF4620

utilizado, que j possua o hardware USB. J existem PICs com sada USB, que dispensam o
uso de um transceptor (FT232 ou qualquer equivalente), mas que no foram utilizados por no
possuir memria de programa suficiente para a aplicao. O PIC com USB de maior memria

disponvel no mercado, na poca da realizao do trabalho, possui 32kBytes de memria de


programa, quantidade que no seria suficiente para o coordenador, cuja pilha ZigBee a mais

complexa e com maior nmero de funes, e que somente ela j ocuparia algo da ordem de
32kBytes, e ainda seria necessrio colocar no PIC as funes de USB e o cdigo relativo
aplicao realizada.

Uma terceira proposta pode ser a utilizao de PICs com sada USB de maior me-

mria que esto para ser lanados pela Microchip, tornando assim desnecessria a utilizao de
um circuito externo para se comunicar com um PC atravs do barramento USB.

Estudos mais detalhados podem ser realizados com o RTC utilizado, o DS1305, ou
pode-se tentar utilizar um outro tipo diferente. Pode-se tentar tambm implementar o RTC em

um outro tipo de n, por exemplo no n do tipo RFD.


58 6 Concluses
59

REFERNCIAS BIBLIOGRFICAS

AAKVAAG, N.; MATHIESEN, M.; THONET, G. (2005). Timing and power issues in wireless
sensor networks - an industrial test case. In: IEEE 34th International Conference Workshops
on Parallel Processing. Oslo, Noruega: [s.n.], p. 419426.

BAKER, N. (2005). Zigbee and bluetooth strengths and weaknesses for industrial applications.
IEE Computing and Control Engineering Journal, 2, v. 16, n. 2, p. 2025.

BRANQUINHO, O. C.; REGGIANI, N.; ANDREOLLO, A. G. (2005). Redes de comunicao


de dados sem fio - uma anlise de desempenho. In: ISA SHOW SOUTH AMERICA Feira
Sul-Americana e 5 Congresso Internacional de Automao, Sistemas e Instrumentao. So
Paulo, Brasil: [s.n.].

CHAKRABARTI, S.; WU, L.; VUONG, S.; LEUNG, V. C. M. (2004). A remotely controlled
bluetooth enabled environment. In: 2004 IEEE Consumer Communications and Networking
Conference. Caesars Palace, Las Vegas, Nevada USA: [s.n.], p. 7781.

CORDEIRO, C. D. M.; ABHYANKAR, S.; TOSHIWAL, R.; AGRAWAL, D. P. (2003). A


novel architecture and coexistence method to provide global access to-from bluetooth wpans
by ieee 802.11 wlans. In: IEEE. 22nd IEEE International Performance Computing and
Communications Conference. Phoenix, Arizona, p. 2330.

CORDEIRO, C. D. M.; AGRAWALL, D. P.; SADOK, D. H. (2003). Interference modeling


and performance of bluetooth mac protocol. IEEE Transactions on wireless communications,
v. 2, n. 6, p. 12401246.

DING, G.; SAHINOGLU, Z.; BHARGAVA, B.; ORLIK, P.; ZHANG;, J. (2005). Reliable
broadcast in zigbee networks. In: Second Annual IEEE Communications Society Conference
on Sensor and Ad Hoc Communications and Networks, 2005. Santa Clara, California, USA:
[s.n.], p. 510520.

FERRARI, P.; FLAMMINI, A.; MARIOLI, D.; TARONI, A. (2006). Ieee802.11 sensor
networking. IEEE Transactions on instrumentation and measurement, 2, v. 55, n. 2, p.
615619.

FERRO, E.; POTORT, F. (2005). Bluetooth and wi-fi wireless protocols: a survey and a
comparison. IEEE Wireless Communications, v. 12, n. 1, p. 1226.

FLEXIPANEL. (2006). Site Flexipanel. Disponvel em: < htt p : //www. f lexipanel.com >.
Acesso em: 17 out. 2006.

FRENZEL, L. E. (2004). Wireless control that simply works. A Supplement to Electronic


Design, p. 112.
60 Referncias Bibliogrficas

FRIAS, R. N. (2004). O que ZigBee? Disponvel em:< htt p :


//www.teleco.com.br/tutoriais/tutorialzigbee/pagina1 .asp >. Acesso em: 23 jun.
2006.
GUTIERREZ, J. A.; NAEVE, M.; CALLAWAY, E.; BOURGEOIS, M.; MITTER, V.; HEILE,
B. (2001). Ieee 802.15.4: a developing standard for low-power low-cost wireless personal area
networks. IEEE Network, 5, v. 15, n. 5, p. 1219.
HAARTSEN, J. (1998). Bluetooth - the universal radio interface for ad hoc, wireless
connectivity. Ericsson Review, 3, v. 75, n. 3, p. 110117.
HOME-CONTROL. (2006). Disponvel em:< htt p :
//www.homecontrol.com.br/index_aplicacoes.htm >. Acesso em: 17 jul. 2006.
IEEE-STANDARDS. (2003)., IEEE Standard 802.15.4. [S.l.], Outubro 2003. 1-679 p.
JINDAL, S.; JINDAL, A.; GUPTA, N. (2005). Grouping wi-max, 3g and wi-fi for wireless
broadband. In: The First IEEE and IFIP International Conference in Central Asia on Internet,
2005. Hyatt Regency Hotel, Bishkek, Kyrgyz Republic: [s.n.], p. 5.
LABTOOLS. (2006). Gravador e Depurador de PICs ICD2BR. Disponvel em:< htt p :
//www.labtools.com.br/index.asp?area = 07&idioma = por&script = produtos&prod =
681 >. Acesso em: 7 jun. 2006.
LANSFORD, J.; STEPHENS, A.; NEVO, R. (2001). Wi-fi (802.11b) and bluetooth - enabling
coexistence. IEEE Network, v. 15, n. 5, p. 2027.
LEE, J.-S. (2005). An experiment on performance study of ieee 802.15.4 wireless networks.
In: 10th IEEE Conference on Emerging Technologies and Factory Automation. Catania, Itlia:
[s.n.], v. 2, p. 451458.
MALAFAYA, H.; TOMS, L.; SOUSA, J. P. (2005). Sensoriao sem fios sobre zigbee e ieee
802.15.4. In: INSTITUTO SUPERIOR DE ENGENHARIA DE LISBOA. Terceiras Jornadas
de Engenharia de Electrnica e Telecomunicaes e de Computadores. Lisboa, Portugal.
MARSAN, M.; CHIASSERINI, C.-F.; NUCCI, A. (2006). Forming optimal topologies
for bluetooth-based wireless personal area networks. IEEE Transactions on Wireless
Comunication, v. 5, n. 4, p. 763773.
MCDERMOTT-WELLS, P. (2004-2005). What is bluetooth? IEEE Potentials, 5, v. 23, n. 5, p.
3335.
MICROCHIP. (2006e). PICDEM Z Demonstration Kit Users Guide.
MICROCHIP. (2006a). Site Microchip. Disponvel em: < htt p : //www.microchip.com >.
Acesso em: 20 mai. 2006.
MICROCHIP. (2006b). PICDEM Z Demonstration Kit. Disponvel em:
< htt p : //www.microchip.com/stellent/idcplg?IdcService = SSG ETP AGE&nodeId =
1406&dDocName = en021925 >Acesso em: 20 mai. 2006.
MICROCHIP. (2006c). MPLAB IDE (Integrated Development Environment). Disponvel
em: < htt p : //www.microchip.com/stellent/idcplg?IdcService = SSG ETP AGE&nodeId =
1406&dDocName = en019469&part = SW 007002 >. Acesso em: 20 mai. 2006.
Referncias Bibliogrficas 61

MICROCHIP. (2006d). MPLAB C18. Disponvel em: < htt p :


//www.microchip.com/stellent/idcplg?IdcService = SSG ETP AGE&nodeId =
1406&dDocName = en010014&part = SW 006011 >. Acesso em: 20 mai. 2006.

NORRIS, M. (2005). Single-chip zigbee for indoor mobile telemetry. The IEEE Seminar on
Telemetry and Telematics, p. 10/110/4.

NUGGEHALLI, P.; SRINIVASAN, V.; RAO, R. R. (2006). Energy efficient transmission


scheduling for delay constrained wireless networks. IEEE Transactions on wireless
communications, v. 5, n. 3, p. 531539.

ONDREJ, S.; ZDENEK, B.; PETR, F.; ONDREJ, H. (2006). Zigbee technology and device
design. In: IEEE International Conference on Networking, International Conference on
Systems and International Conference on Mobile Communications and Learning Technologies,
ICN/ICONS/MCL. Mauritius: [s.n.], p. 129 129.

PETERSON, R. L.; ZIEMER, R. E.; BORTH, D. E. (1995). Introduction to Spread Spectrum


Communications. [S.l.]: Prentice Hall.

PROAKIS, J. G. (2001). Digital Communications. 4th. ed. [S.l.]: Mc Graw-Hill.

RONDEAU, T. W.; DSOUZA, M. F.; SWEENEY, D. G. (2004). Residential microwave oven


interference on bluetooth data performance. IEEE Transactions on Consumer Electronics, 3,
v. 50, n. 3, p. 856863.

SAKURAGUI, R. R. M. Sistema de Localizao de Servios para Domnios de Segurana


Locias e Remotos. Dissertao (Mestrado) Universidade de So Paulo, 2006.

SALONIDIS, T.; BHAGWAT, P.; TASSIULAS, L.; LAMAIRE, R. (2001). Distributed


topology construction of bluetooth personal area networks. In: IEEE INFOCOM 2001.
Twentieth Annual Joint Conference of the IEEE Computer and Communications Societies.
Anchorage, Alaska, USA: [s.n.], v. 3, p. 2226.

STREETON, M.; STANFIELD, C. (2005). Zigbee: the telemetry solution? In: The IEE
Seminar on Telemetry and Telematics. Savoy Place, London, UK: [s.n.], p. 8/1 8/4.

WIKIPEDIA. (2006a). Harald I of Denmark. Disponvel em:< htt p :


//en.wikipedia.org/wiki/HaraldB luetooth >. Acesso em: 16 jul. 2006.

ZHAO, Z.; CUI, L. (2005). Easimed: A remote health care solution. In: 27th Annual
International Conference of the Engineering in Medicine and Biology Society. Shanghai,
China: IEEE, p. 21452148.

ZHENG, Y.; FENG, Z. (2002). Simplifications of the bluetooth radio devices. In: IEEE 4th
International Workshop on Networked Appliances, 2002. Gaithersburg, Maryland, USA: [s.n.],
p. 107115.

ZIGBEE-ALLIANCE. (2005)., ZigBee-Specification-v1.0. [S.l.], Junho 2005.

ZIGBEE-ALLIANCE. (2006). Disponvel em: < htt p : //zigbee.org/ >. Acesso em: 16 mar.
2006.
62 Referncias Bibliogrficas
63

APNDICE A -- CDIGOS FONTE

A.1 Coordenador

A.1.1 Inicializao

Poucas alteraes foram feitas para a implementao. O PORTA inteiro continuou


como I/O digital.

// D1 and D2 are on RA0 and RA1 respe tively, and CS of the TC77 is on RA2.
//LDR is on RA3 and Buzzer on RA5.
// Make PORTA digital I/O.
ADCON1 = 0x0F;

O valor dos pinos do PORTA na inicializao dado pelo valor da varivel LATA.

Os valores dos bits equivalentes ao sensor de temperatura (TC77) e do Buzzer foram colocados
em nvel lgico alto, para que o sensor de temperatura no fosse habilitado e o Buzzer no

disparasse na inicializao.

// Desele t the TC77 (RA2) and turn Buzzer off (RA5).


LATA = 0x24;

O TRISA responsvel por definir se um pino do PORTA ser uma entrada ou uma
sada.

// Make RA0, RA1, RA2, RA4 and RA5 outputs, and RA3 input.
TRISA = 0xC8;

A.1.2 Sensor de Temperatura

O software do sensor de temperatura pode ser dividido em duas partes, mostrado


abaixo.
64 A

1.Leitura do valor de temperatura para ser mostrado na tela.

A funo GetTC77String retorna o valor de temperatura j formatado para ser mostrado


na tela.

ConsolePutROMString((ROM har*)"Medido: ");


GetTC77String(ptr);
ConsolePutString((BYTE*)ptr);
ConsolePutROMString((ROM har*)"\r\n");

Gerando no hyperterminal algo como:

Medido: 26,0625 C

2.Leitura do valor de temperatura para ser comparado com os patamares estipulados.

A funo GetTC77HexaValue retorna o valor de temperatura no formato de um nmero


inteiro, de forma a poder ser utilizado para comparar com valores fixos de temperatura.

lui_Temperature_Value = GetTC77HexaValue();

A funo GetTC77String faz parte de um exemplo que veio junto com a pilha da

Microchip, enquanto que a funo GetTC77HexaValue foi implementada. Ambas esto de-
vidamente documentadas no arquivo TC77.c que se encontra no CD entregue junto com a
dissertao.

Como explicado na seo 5.2.1, existem dois patamares de temperatura. Para fa-

cilitar a verificao do funcionamento do sensor de temperatura, criou-se uma lgica para os


dois leds presentes na placa do kit de desenvolvimento. Cada LED equivale a um patamar. O

LED 1 que est no pino RA0 do PIC representa o patamar mais baixo, e o LED 2 que est no
pino RA1 do PIC representa o patamar mais elevado. Quando a temperatura est abaixo do
primeiro patamar, os dois LEDs esto apagados. Quando a temperatura ultrapassa o valor do

primeiro patamar, o LED 1 acende, e quando a temperatura ultrapassa o segundo patamar o


LED 2 acende. Abaixo vemos o cdigo implementado.
A.1 Coordenador 65

// Tratamento do Patamar de Temperatura 1


myStatusFlags.bits.bTemperaturaPatamar1Ant = myStatusFlags.bits.bTemperaturaPatamar1;
if(lui_Temperature_Value > PATAMAR_TEMPERATURA_1)
{
myStatusFlags.bits.bTemperaturaPatamar1 = TEMPERATURA_ACIMA_PATAMAR;
LED_1 = LED_ON;
}
else
{
myStatusFlags.bits.bTemperaturaPatamar1 = TEMPERATURA_ABAIXO_PATAMAR;
LED_1 = LED_OFF;
}
// Tratamento do Patamar de Temperatura 2
myStatusFlags.bits.bTemperaturaPatamar2Ant = myStatusFlags.bits.bTemperaturaPatamar2;
if(lui_Temperature_Value > PATAMAR_TEMPERATURA_2)
{
myStatusFlags.bits.bTemperaturaPatamar2 = TEMPERATURA_ACIMA_PATAMAR;
LED_2 = LED_ON;
}
else
{
myStatusFlags.bits.bTemperaturaPatamar2 = TEMPERATURA_ABAIXO_PATAMAR;
LED_2 = LED_OFF;
}

O prximo passo verificar se o ar condicionado (LED) precisa ser ligado. Essa


verificao s feita se o n do tipo RFD estiver ativo na rede. Cabe lembrar tambm que

existem dois tipos de tratamento, o do regime permanente e o da inicializao do n do tipo


RFD. O cdigo para essa verificao apresentado a seguir.

// Verifi ao da ne essidade de ligar ou desligar o ar ondi ionado.


// Se o n estiver ativo na rede.
if(myRFDsFlags.bits.bRFD1)
{
// Tratamento em regime
if (myStatusFlags.bits.bOpera aoEmRegime)
{
//Se a temperatura a abou de ruzar para ima o limiar 2, deve-se
// LIGAR o ar ondi ionado.
if ((myStatusFlags.bits.bTemperaturaPatamar2 == TEMPERATURA_ACIMA_PATAMAR) &&
(myStatusFlags.bits.bTemperaturaPatamar2Ant == TEMPERATURA_ABAIXO_PATAMAR))
// envia mensagem para LIGAR o ar ondi ionado.
myStatusFlags.bits.bLigarArCondi ionado = TRUE;

//Se a temperatura a abou de ruzar para baixo o limiar 1, deve-se


//DESLIGAR o ar ondi ionado.
if ((myStatusFlags.bits.bTemperaturaPatamar1 == TEMPERATURA_ABAIXO_PATAMAR) &&
(myStatusFlags.bits.bTemperaturaPatamar1Ant == TEMPERATURA_ACIMA_PATAMAR))
// envia mensagem para DESLIGAR o ar ondi ionado.
myStatusFlags.bits.bDesligarArCondi ionado = TRUE;
}
// Tratamento na ini ializao
else
{
myStatusFlags.bits.bOpera aoEmRegime = 1;
if (lui_Temperature_Value > PATAMAR_TEMPERATURA_1)
// envia mensagem para LIGAR o ar ondi ionado.
myStatusFlags.bits.bLigarArCondi ionado = TRUE;
else
// envia mensagem para DESLIGAR o ar ondi ionado.
myStatusFlags.bits.bDesligarArCondi ionado = TRUE;
}
}
66 A

Medido o valor da temperatura e realizadas as verificaes quanto necessidade do

envio de mensagens, a ltima parte referente ao sensor de temperatura o envio da mensagem,


caso seja necessrio. Para tal utilizado o seguinte segmento de software:

//-----------------------------------------------------------------------
// In io da parte que envia mensagem para o End Point ar ondi ionado.
//-----------------------------------------------------------------------
if ((myStatusFlags.bits.bLigarArCondi ionado) || (myStatusFlags.bits.bDesligarArCondi ionado))
{
// Envia a mensagem:
ZigBeeBlo kTx();

TxBuffer[TxData++ = APL_FRAME_TYPE_KVP | 1;
TxBuffer[TxData++ = APLGetTransId();
TxBuffer[TxData++ = APL_FRAME_COMMAND_SET | (APL_FRAME_DATA_TYPE_UINT8 << 4);
TxBuffer[TxData++ = OnOffSRC_OnOff & 0xFF;
TxBuffer[TxData++ = (OnOffSRC_OnOff >> 8) & 0xFF;

if (myStatusFlags.bits.bLigarArCondi ionado)
{
// envia mensagem para LIGAR o ar ondi ionado.
TxBuffer[TxData++ = AR_CONDICIONADO_ON;
myStatusFlags.bits.bLigarArCondi ionado = FALSE;
}
else
{
// envia mensagem para DESLIGAR o ar ondi ionado.
TxBuffer[TxData++ = AR_CONDICIONADO_OFF;
myStatusFlags.bits.bDesligarArCondi ionado = FALSE;
}

#ifdef USE_BINDINGS
// We are sending indire t
params.APSDE_DATA_request.DstAddrMode = APS_ADDRESS_NOT_PRESENT;
#else
// We are sending dire t
params.APSDE_DATA_request.DstAddrMode = APS_ADDRESS_16_BIT;
params.APSDE_DATA_request.DstEndpoint = EP_AR_CONDICIONADO;
params.APSDE_DATA_request.DstAddress.ShortAddr = destinationAddress;
#endif

//params.APSDE_DATA_request.asduLength; TxData
params.APSDE_DATA_request.ProfileId.Val = MY_PROFILE_ID;
params.APSDE_DATA_request.RadiusCounter = DEFAULT_RADIUS;
params.APSDE_DATA_request.Dis overRoute = ROUTE_DISCOVERY_ENABLE;
params.APSDE_DATA_request.TxOptions.Val = 0;
params.APSDE_DATA_request.Sr Endpoint = EP_AR_CONDICIONADO;
params.APSDE_DATA_request.ClusterId = OnOffSRC_CLUSTER;

ConsolePutROMString( (ROM har *)" Tentando enviar mensagem do Ar Condi ionado.\r\n");

urrentPrimitive = APSDE_DATA_request;
// fim do envio da mensagem.
}
//-----------------------------------------------------------------------
// Fim da parte que envia mensagem para o End Point ar ondi ionado.
//-----------------------------------------------------------------------
A.1 Coordenador 67

A.1.3 Sensor de Luminosidade (LDR)

Para realizar a leitura do LDR, deve-se seguir os seguintes passos:

Inicializar o conversor AD;

// onfigurando onversor A/D


OpenADC( ADC_FOSC_8 & // frequen ia de amostragem
ADC_RIGHT_JUST & // formato dos dados nos registradores
ADC_2_TAD, // tempo de aquisi ao
ADC_CH0 & // anal utilizado para leitura
ADC_INT_OFF & // desabilitando interrup oes
ADC_VREFPLUS_VDD & // ajustando a refern ia mais alta
ADC_VREFMINUS_VSS, // ajustando a refern ia mais baixa
11 // ajustando as portas de A0 a A3 para analgi as
);

Determinar a porta do PIC onde ser feita a leitura;

SetChanADC( ADC_CH3 );

Realizar a leitura.

Valor_Lido_AD = LerDadosAD();

Aps a leitura do valor do conversor AD, esse valor enviado via hyperterminal, atravs

das linhas de comando abaixo:

ConsolePutROMString((rom har*)"Valor medido no AD: ");


ConsolePutString(itoa(Valor_Lido_AD,( har*)Buffer));
ConsolePutROMString((rom har*)".!!!\n\r");

O efeito no hyperterminal :

Valor medido no AD: 794.!!!

Fechar o conversor AD

CloseADC();

Habilitar novamente as portas RA0 at RA3 como portas digitais.

ADCON1 = 0x0F;
68 A

Para realizar a leitura do conversor AD, necessria a utilizao da funo int Ler-

DadosAD(void), localizada dentro do arquivo LerDadosAD.c, que se encontra no CD que acom-


panha esta dissertao.

Aps a leitura do valor do LDR, o prximo passo o tratamento do valor obtido.


Dependendo do intervalo em que ele se encontra, a lmpada do n do tipo RFD dever ficar

apagada, acesa a 40%, acesa a 60% ou acesa a 100% da sua carga mxima.

// Tratamento do valor do LDR


myStatusFlags2.bits.bLDRPatamarAnt = myStatusFlags2.bits.bLDRPatamar;
if (Valor_Lido_AD < LIMITE_LDR_1)
myStatusFlags2.bits.bLDRPatamar = LDR_INTERVALO_ON;
if ((Valor_Lido_AD >= LIMITE_LDR_1) && (Valor_Lido_AD < LIMITE_LDR_2))
myStatusFlags2.bits.bLDRPatamar = LDR_INTERVALO_60;
if ((Valor_Lido_AD >= LIMITE_LDR_2) && (Valor_Lido_AD < LIMITE_LDR_3))
myStatusFlags2.bits.bLDRPatamar = LDR_INTERVALO_40;
if (Valor_Lido_AD >= LIMITE_LDR_3)
myStatusFlags2.bits.bLDRPatamar = LDR_INTERVALO_OFF;

Aps o tratamento, necessrio verificar a necessidade de enviar uma mensagem

ao n do tipo RFD alterando o status da lmpada.

// Verifi ao da ne essidade de a ender ou apagar a lmpada.


// Se o n estiver ativo na rede.
if(myRFDsFlags.bits.bRFD1)
{
// OBS.: O tratamento da ini ializao e do regime o mesmo.
if(myStatusFlags2.bits.bLDRPatamarAnt !=
myStatusFlags2.bits.bLDRPatamar)
{
// altera status da lmpada.
myStatusFlags2.bits.bLDRAlterarLampada = TRUE;
// define qual o status atual da lmpada.
myStatusFlags2.bits.bLDRStatusLampada =
myStatusFlags2.bits.bLDRPatamar;
}
}

Caso exista a necessidade de se enviar uma mensagem ao n do tipo RFD, isso ser
realizado atravs do seguinte segmento de software:

//-----------------------------------------------------------------------
// In io da parte que envia mensagem para o End Point lmpada.
//-----------------------------------------------------------------------
if (myStatusFlags2.bits.bLDRAlterarLampada)
{
// Envia a mensagem:
ZigBeeBlo kTx();

TxBuffer[TxData++ = APL_FRAME_TYPE_KVP | 1;
TxBuffer[TxData++ = APLGetTransId();
TxBuffer[TxData++ = APL_FRAME_COMMAND_SET | (APL_FRAME_DATA_TYPE_UINT8 << 4);
A.1 Coordenador 69

TxBuffer[TxData++ = OnOffSRC_OnOff & 0xFF;


TxBuffer[TxData++ = (OnOffSRC_OnOff >> 8) & 0xFF;

swit h (myStatusFlags2.bits.bLDRStatusLampada)
{
ase STATUS_LAMPADA_OFF:
TxBuffer[TxData++ = LDR_LAMPADA_OFF;
break;
ase STATUS_LAMPADA_40:
TxBuffer[TxData++ = LDR_LAMPADA_40;
break;
ase STATUS_LAMPADA_60:
TxBuffer[TxData++ = LDR_LAMPADA_60;
break;
ase STATUS_LAMPADA_ON:
TxBuffer[TxData++ = LDR_LAMPADA_ON;
break;
}
myStatusFlags2.bits.bLDRAlterarLampada = 0;

#ifdef USE_BINDINGS
// We are sending indire t
params.APSDE_DATA_request.DstAddrMode = APS_ADDRESS_NOT_PRESENT;
#else
// We are sending dire t
params.APSDE_DATA_request.DstAddrMode = APS_ADDRESS_16_BIT;
params.APSDE_DATA_request.DstEndpoint = EP_LDR;
params.APSDE_DATA_request.DstAddress.ShortAddr = destinationAddress;
#endif

//params.APSDE_DATA_request.asduLength; TxData
params.APSDE_DATA_request.ProfileId.Val = MY_PROFILE_ID;
params.APSDE_DATA_request.RadiusCounter = DEFAULT_RADIUS;
params.APSDE_DATA_request.Dis overRoute = ROUTE_DISCOVERY_ENABLE;
params.APSDE_DATA_request.TxOptions.Val = 0;
params.APSDE_DATA_request.Sr Endpoint = EP_LDR;
params.APSDE_DATA_request.ClusterId = OnOffSRC_CLUSTER;

ConsolePutROMString( (ROM har *)" Tentando enviar mensagem do LDR.\r\n" );

urrentPrimitive = APSDE_DATA_request;
// fim do envio da mensagem.
}
//-----------------------------------------------------------------------
// Fim da parte que envia mensagem para o End Point lmpada.
//-----------------------------------------------------------------------

A.1.4 Sinalizador Acstico (Buzzer)

O estado do Buzzer depende do valor que recebido via ZigBee. Quando o sensor
de movimento do n do tipo RFD detecta algum movimento, o n do tipo coordinator recebe
uma mensagem indicando que o Buzzer deve ser acionado. Quando o mesmo sensor de movi-

mento no mais detecta movimento, enviada uma mensagem para o n do tipo coordinator
para que o Buzzer deixe de ser acionado. Segue abaixo a parte do cdigo onde alterado o

estado do Buzzer dependendo da mensagem recebida.


70 A

swit h (data)
{
ase SENSOR_MOVIMENTO_OFF:
ConsolePutROMString( (ROM har *)" Desligando Buzzer.\r\n");
BUZZER = BUZZER_OFF;
TxBuffer[TxData++ = SUCCESS;
break;
ase SENSOR_MOVIMENTO_ON:
ConsolePutROMString( (ROM har *)" Ligando Buzzer.\r\n");
BUZZER = BUZZER_ON;
TxBuffer[TxData++ = SUCCESS;
break;
default:
PrintChar( data );
ConsolePutROMString( (ROM har *)" Mensagem LDR Invalida.\r\n");
TxBuffer[TxData++ = KVP_INVALID_ATTRIBUTE_DATA;
break;
}

A.2 End Device (RFD)

A.2.1 Inicializao

Nessa parte do software foram feitas vrias alteraes. As portas de RA0 at RA3
do PORTA so utilizadas como entradas analgicas. As portas RA0 e RA3 so utilizadas no
comparador e as portas RA1 e RA2 no so utilizadas.

ADCON1 = 11; // AN0:AN3 analogi as. AN0 e AN3 sero utilizadas no omparador.
//Os leds em RA0 e RA1 e o TC77 em RA2 no sero utilizados.

O valor dos pinos do PORTA na inicializao dado pelo valor da varivel LATA.
Todos os bits foram inicializados com nvel lgico baixo.

// Colo a todas as portas em nvel lgi o baixo.


LATA = 0x00;

O TRISA responsvel por definir se um pino do PORTA ser uma entrada ou uma

sada.
// Make RA0:RA3 and RA5 inputs and RA4 output.
TRISA = 0xEF;

O pino RD0 do PORTD foi utilizado para acionar o LED, que representa o ar con-
dicionado, enquanto que o pino RE1 do PORTE utilizado para acionar o gate do triac, que

acionar a lmpada.
A.2 End Device (RFD) 71

//Fazendo de PORTD0 e PORTE1 sadas.


TRISD0 = 0; // Led que representa o ar- ondi ionado.
TRISEbits.TRISE1 = 0; // Sada para a ionamento do gate do Tria .

necessrio tambm habilitar os comparadores do PORTA e alterar as interrupes

de modo que o comparador funcione corretamente.

CMCON = 0x1; // habilita os omparadores do PORTA

PIE2bits.CMIE = 1; // habilita interrupao por omparador


IPEN = 0; // desabilita prioridade das interrupoes
INTCONbits.PEIE = 1; // habilita interrupoes periferi as
PIR2bits.CMIF = 0; // limpa flag da interrupao por omparador

A.2.2 Sensor de Movimento

Assim que o n do tipo RFD entra na rede, a primeira coisa que ele faz aguardar

60 segundos, para que o sensor de movimento seja inicializado. Para tal utilizado o timer 1,
com uma base de tempo de aproximadamente 50 ms.

//TIMER 1
if (TMR1IF)
{
CLRWDT();
ConsolePutROMString( (ROM har *)".");
TMR1IF = 0;

//quando der 60 segundos olo a o bit que indi a que o sensor est
//ini ializado em nvel lgi o alto. Entrar aqui apenas uma vez.
if (myStatusFlags.bits.bSensorIni ializado == FALSE)
if (++lui_Contador_Ini ializa_Sensor == 458)
//458 o equivalente a aproximadamente 60s.
{
myStatusFlags.bits.bSensorIni ializado = TRUE;
CloseTimer1();
ConsolePutROMString( (ROM har *)"Fim da ini ializa ao do Sensor
de Movimento.\n\r");
}
return;
}

Aps a inicializao, o sensor de movimento funciona da seguinte forma: quando

acionado envia ao n do tipo coordinator uma mensagem indicando que o Buzzer deve ser
acionado, e quando o sensor de movimento no mais detecta movimento, uma mensagem deve

ser enviada ao n do tipo coordinator para que o Buzzer deixe de ser acionado.

Essa primeira parte de software verifica se o sensor foi acionado.


72 A

// Lgi a para verifi ar o sensor de movimento


if (myStatusFlags.bits.bSensorIni ializado)
{
myStatusFlags.bits.bSensorMovimentoAnt =
myStatusFlags.bits.bSensorMovimento;
if (SENSOR_MOVIMENTO == SENSOR_ACIONADO)
myStatusFlags.bits.bSensorMovimento = TRUE;
else
myStatusFlags.bits.bSensorMovimento = FALSE;
}

A prxima parte do software a que verifica a necessidade do envio de mensagem.

// Lgi a para verifi ar se deve enviar alguma mensagem.


if ((myStatusFlags.bits.bSensorMovimento == TRUE) &&
(myStatusFlags.bits.bSensorMovimentoAnt == FALSE))
// Envia mensagem para to ar o buzzer
myStatusFlags.bits.bBuzzerOn = TRUE;
if ((myStatusFlags.bits.bSensorMovimento == FALSE) &&
(myStatusFlags.bits.bSensorMovimentoAnt == TRUE))
// Envia mensagem para parar de to ar o buzzer
myStatusFlags.bits.bBuzzerOff = TRUE;

Caso deva ser enviada uma mensagem para alterar o status do Buzzer, o seguinte
cdigo utilizado:

if ((myStatusFlags.bits.bBuzzerOn) || (myStatusFlags.bits.bBuzzerOff))
{
// Envia a mensagem:
ZigBeeBlo kTx();

TxBuffer[TxData++ = APL_FRAME_TYPE_KVP | 1;
TxBuffer[TxData++ = APLGetTransId();
TxBuffer[TxData++ = APL_FRAME_COMMAND_SET | (APL_FRAME_DATA_TYPE_UINT8 << 4);
TxBuffer[TxData++ = OnOffSRC_OnOff & 0xFF;
TxBuffer[TxData++ = (OnOffSRC_OnOff >> 8) & 0xFF;

if (myStatusFlags.bits.bBuzzerOn)
{
// envia mensagem para LIGAR o Buzzer.
TxBuffer[TxData++ = SENSOR_MOVIMENTO_ON;
myStatusFlags.bits.bBuzzerOn = FALSE;
}
else
{
// envia mensagem para DESLIGAR o Buzzer.
TxBuffer[TxData++ = SENSOR_MOVIMENTO_OFF;
myStatusFlags.bits.bBuzzerOff = FALSE;
}

#ifdef USE_BINDINGS
// We are sending indire t
params.APSDE_DATA_request.DstAddrMode = APS_ADDRESS_NOT_PRESENT;
#else
// We are sending dire t
params.APSDE_DATA_request.DstAddrMode = APS_ADDRESS_16_BIT;
params.APSDE_DATA_request.DstEndpoint = EP_SENSOR_MOVIMENTO;
params.APSDE_DATA_request.DstAddress.ShortAddr = destinationAddress;
#endif
//params.APSDE_DATA_request.asduLength; TxData
params.APSDE_DATA_request.ProfileId.Val = MY_PROFILE_ID;
A.2 End Device (RFD) 73

params.APSDE_DATA_request.RadiusCounter = DEFAULT_RADIUS;
params.APSDE_DATA_request.Dis overRoute = ROUTE_DISCOVERY_ENABLE;
params.APSDE_DATA_request.TxOptions.Val = 0;
params.APSDE_DATA_request.Sr Endpoint = EP_SENSOR_MOVIMENTO;
params.APSDE_DATA_request.ClusterId = OnOffSRC_CLUSTER;

ConsolePutROMString( (ROM har *)" Tentando enviar mensagem do Sensor de Movimento.\r\n");

urrentPrimitive = APSDE_DATA_request;
// fim do envio da mensagem.
}

A.2.3 Lmpada

A lmpada acionada dependendo da mensagem que recebida do n do tipo RFD

via ZigBee. De acordo com o valor de luminosidade lido pelo LDR, a lmpada poder estar
apagada, acesa a 40%, acesa a 60% ou acesa a 100% de sua carga mxima.

swit h (data)
{
ase LDR_LAMPADA_OFF:
ConsolePutROMString((ROM har *)"Lampada OFF.\r\n");
alfa = 'z';
TxBuffer[TxData++ = SUCCESS;
break;

ase LDR_LAMPADA_40:
ConsolePutROMString((ROM har *)"Lampada a 40%.\r\n");
alfa = 'a';
TxBuffer[TxData++ = SUCCESS;
break;

ase LDR_LAMPADA_60:
ConsolePutROMString((ROM har *)"Lampada a 60%.\r\n");
alfa = 'b';
TxBuffer[TxData++ = SUCCESS;
break;

ase LDR_LAMPADA_ON:
ConsolePutROMString((ROM har *)"Lampada a 100%.\r\n");
alfa = 'd';
TxBuffer[TxData++ = SUCCESS;
break;

default:
PrintChar(data);
ConsolePutROMString((ROM har *)"Mensagem LDR Invalida.\r\n");
TxBuffer[TxData++ = KVP_INVALID_ATTRIBUTE_DATA;
break;
}
74 A

A.2.4 LED

O status do LED (ar condicionado) depende da mensagem recebida do n do tipo


coordinator. Dependendo da temperatura lida pelo sensor de temperatura (TC77) o ar condi-
cionado deve ser ligado ou desligado. Abaixo pode ser visto o cdigo referente mudana do

status do LED.

swit h (data)
{
ase AR_CONDICIONADO_OFF:
ConsolePutROMString((ROM har*)"Desligando o Ar Condi ionado.\r\n");
LED_TEMP_1 = LED_OFF;
TxBuffer[TxData++ = SUCCESS;
break;

ase AR_CONDICIONADO_ON:
ConsolePutROMString((ROM har*)"Ligando o Ar Condi ionado.\r\n");
LED_TEMP_1 = LED_ON;
TxBuffer[TxData++ = SUCCESS;
break;

default:
PrintChar( data );
ConsolePutROMString((ROM har*)"Mensagem Ar Condi ionado Invalida.\r\n");
TxBuffer[TxData++ = KVP_INVALID_ATTRIBUTE_DATA;
break;
}