1
UNIVERSIDADE FEDERAL DO VALE DO SÃO FRANCISCO
CURSO DE GRADUAÇÃO EM ENGENHARIA DA COMPUTAÇÃO
Sérgio Aurélio Ferreira Soares
Rede de Sensores Sem Fio Para Localização e
Monitoramento de Pequenos Ruminantes
Juazeiro – BA
2012
2
UNIVERSIDADE FEDERAL DO VALE DO SÃO FRANCISCO
CURSO DE GRADUAÇÃO EM ENGENHARIA DA COMPUTAÇÃO
Sérgio Aurélio Ferreira Soares
Rede de Sensores Sem Fio Para Localização e Monitoramento de
Pequenos Ruminantes
Trabalho de conclusão de curso apresentado à
Universidade Federal do Vale do São Francisco –
UNIVASF, campus Juazeiro–BA, como requisito
parcial para obtenção do título de Engenheiro de
Computação.
Orientador: Professor Dsc. Brauliro Gonçalves Leal
Co-orientador: Professora Dsc. Silvia Helena Nogueira Turco
Juazeiro – BA
2012
3
S676r
Soares, Sérgio Aurélio Ferreira.
Rede de sensores sem fio para localização e monitoramento de
pequenos ruminantes/ Sérgio Aurélio Ferreira Soares. –- Juazeiro-BA,
2012.
XIII; 79f. : il. ; 29 cm.
Trabalho de Conclusão de Curso (Graduação em Engenharia de
Computação) - Universidade Federal do Vale do São Francisco,
Juazeiro-BA, 2012.
Orientador (a): Prof. Dsc. Brauliro Gonçalves Leal
1. Sistemas de comunicação sem fio 2. Rastreamento de animal.
3. Sensoriamento Remoto. I. Título. II. Leal, Brauliro Gonçalves. III.
Universidade Federal do Vale do São Francisco
CDD 621.3821
Ficha catalográfica elaborada pelo Sistema Integrado de Biblioteca SIBI/UNIVASF
Bibliotecário: Renato Marques Alves
4
UNIVERSIDADE FEDERAL DO VALE DO SÃO FRANCISCO
CURSO DE GRADUAÇÃO EM ENGENHARIA DA COMPUTAÇÃO
FOLHA DE APROVAÇÃO
Sérgio Aurélio Ferreira Soares
Rede de Sensores Sem Fio Para Localização e
Monitoramento de Pequenos Ruminantes
Trabalho de Conclusão de Curso apresentado como requisito parcial
para obtenção do título de Engenheiro de Computação, pela
Universidade Federal do Vale do São Francisco.
__________________________________________________________
Brauliro Gonçalves Leal, Doutor, Universidade Federal do Vale do São Francisco
__________________________________________________________
Silvia Helena Nogueira Turco, Doutora, Universidade Federal do Vale do São Francisco
__________________________________________________________
Fabrício Braga Soares de Carvalho, Mestre, Universidade Federal do Vale do São Francisco
__________________________________________________________
Ricardo Argenton Ramos, Doutor, Universidade Federal do Vale do São Francisco
Aprovado pelo Colegiado de Engenharia da Computação em
/
/
5
Dedico essa conquista a minha mãe.
6
AGRADECIMENTOS
Agradeço a Deus pela vida e por ser meu porto seguro em momentos de dificuldade.
A minha querida mãe e melhor amiga Lucilene, pelo amor, preocupação, apoio
incondicional e sabedoria. Por me ensinar através do seu exemplo, a ser forte e lutar
pelos meus objetivos respeitando e ajudando o próximo.
Ao meu pai Sérgio pelo amor e por despertar em mim o interesse pela computação.
Aos meus familiares, em especial a minha irmã Aryadne e meu primo Anderson, que
indiretamente contribuíram para o sucesso deste projeto.
Ao meu orientador, amigo e principal fonte de inspiração professor Brauliro Leal,
pelos ensinamentos, confiança, lealdade e esforços dedicados.
Ao meu grande amigo Bruno Pinho, pela amizade, incentivo e colaboração técnica
essencial neste trabalho.
Aos amigos de faculdade em especial a Rodrigo Bacurau, Diego Amando, Manoel
Alexandre, Felipe Pinheiro, Ícaro Gonzalez e Daniel Costa.
Ao professor Fabrício Braga pelo apoio, confiança e amizade.
Aos meus amigos de infância.
Aos meus irmãos DeMolays.
Aos professores Ricardo Ramos, Marcus Ramos, Jadsonlee Sá, Anderson Perez,
Rômulo Calado, Marcelo Linder, Silvia Turco e Rodrigo Rimoldi.
A todos aqueles que direta ou indiretamente contribuíram para o êxito deste
trabalho.
7
RESUMO
As Redes de Sensores Sem Fio constituem uma tecnologia emergente, que tem
proporcionado um crescimento significativo das perspectivas industriais e científicas
em todo o mundo. A capacidade de monitorar e controlar o ambiente, aliada a um
baixo consumo de energia, permite a aplicação da tecnologia em diversos setores
da sociedade. No entanto, a utilização de novas tecnologias principalmente no setor
agropecuário ainda é bastante tímida. Dessa forma, neste trabalho é apresentado o
processo de desenvolvimento de um sistema composto por hardware e software
capaz de monitorar animais utilizando uma Rede de Sensores sem Fio baseada no
protocolo ZigBee 802.15.4. Cada animal utiliza um colar com um nó sensor sem fio
responsável por medir a temperatura ambiente, umidade relativa e frequência
cardíaca do animal, bem como estimar a sua localização, através de métodos
baseados na intensidade do sinal recebido (RSSI). O objetivo do trabalho é servir
como ferramenta facilitadora no estudo do efeito de variáveis meteorológicas na
qualidade de vida e produção dos animais, bem como na análise de hábitos de
pastejo e alterações de comportamento dos animais através do rastreamento da sua
localização. Adicionalmente, espera-se que a ferramenta possa auxiliar a análise e
projeto de novos algoritmos para a localização por RSSI e detecção automática de
alterações comportamentais e fisiológicas dos animais.
Palavras-chave: XBee, ZigBee 802.15.4, Frequência Cardíaca, Umidade Relativa,
Temperatura,
Rastreamento
por
Bioclimatologia, Zootecnia de Precisão.
RSSI,
Ambiência,
Conforto
Térmico,
8
ABSTRACT
The Wireless Sensor Networks are an emerging technology that has provided a
significant growth of industrial and scientific perspectives in the world. The ability to
monitor and to control the environment with low power hardware makes it applicable
to a wide variety of society needs. However, the use of new technologies, especially
in the agricultural sector, is not so common. Thus, this work presents a proposal to
develop a system composed of hardware and software for monitoring and tracking
goats using a Wireless Sensor Network based on 802.15.4 ZigBee protocol. Each
animal wears a collar with a wireless sensor node that estimates the animal's
location, using methods based on received signal strength (RSSI), and measures his
temperature, relative humidity and heart rate. The goal of this work is to be a useful
tool for studying the effect of meteorological variables on quality of life and livestock
production as well as the analysis of grazing habits and changes in animal behavior
by tracking their position. Additionally is expected that this tool can help analyze and
design new algorithms for RSSI tracking and automatic detection of behavioral or
physiological changes in the animals.
Keywords: XBee, Zigbee 802.15.4, Heart Rate, Relative Humidity, Temperature,
RSSI Tracking, Environment, Thermal Comfort, Bioclimatology, Animal Science
Precision.
9
Lista de Figuras
Figura 1 - Ilustração de um Animal Equipado com um Nó Sensor ........................................................ 15
Figura 2 - Visão Geral do Sistema de Localização de Monitoramento Baseado em RSSF .................... 16
Figura 3 – Descrição de Alto Nível de um Nó Sensor ............................................................................ 18
Figura 4 – Visão Geral da Organização e Arquitetura de Uma RSSF ..................................................... 19
Figura 5 - Comparação de Tecnologias Sem Fio. (FONTE: GISLASON, 2008) ........................................ 20
Figura 6 – Aplicações do padrão ZigBee (ADAPTADO: GISLASON, 2008).............................................. 21
Figura 7 – Diagrama da Arquitetura e Pilha de Protocolos ZigBee. (FONTE: BARONTI et al., 2007) .... 22
Figura 8 - Topologias de Redes ZigBee .................................................................................................. 24
Figura 9 – Principais Modelos de Módulos XBee PRO da Digi International ........................................ 26
Figura 10 - Estrutura Geral de um Quadro (frame) API. (Fonte: DIGI, 2011). ....................................... 28
Figura 11 - Tela do Software X-CTU. Utilizado para Configuração de Módulos XBee........................... 30
Figura 12 - Sintaxe de Comandos AT no Modo de Operação Transparente ......................................... 31
Figura 13 - Exemplos de Execução de Comandos AT no Modo Transparente ...................................... 32
Figura 14 - Troca de Pacotes API Para a Execução Local de Comandos AT .......................................... 33
Figura 15 - Troca de Pacotes API Para a Execução Remota de Comandos AT ...................................... 35
Figura 16 - Troca de Pacotes Para a Transmissão de Dados ................................................................. 38
Figura 17 – Algoritmo de Lateração Para Localização de Nós Móveis .................................................. 49
Figura 18 - Algoritmo do Mínimo Máximo Para a Localização de Nós Móveis ..................................... 50
Figura 19 – Gráfico de Participação Percentual das Regiões Brasileiras no Rebanho Nacional ........... 52
Figura 20 – Gráfico de Participação Percentual dos Cinco Maiores Produtores de Caprinos no Brasil 53
Figura 21 - Visão Geral do Software em Desenvolvimento................................................................... 57
Figura 24 - Diagrama Entidade Relacionamento................................................................................... 59
Figura 25 - Diagrama de Pinos do Módulo XBee Pro Series 2 ............................................................... 61
Figura 26 - Estação Coordenadora da Rede .......................................................................................... 62
Figura 27 - Esquemático do Circuito de uma Estação de Referência .................................................... 63
Figura 28 - Diagrama de Blocos de Uma Estação Móvel ....................................................................... 63
Figura 29 - Esquemático do Circuito da Estação Móvel ........................................................................ 64
Figura 30 - a) Sensor de umidade Honeywell HIH-5031. b) Curva Tensão (Vdc) X Umidade Relativa
(%UR) a 25°C e Tensão de Alimentação 3,3V Vdc. ................................................................................ 65
Figura 31 – Encapsulamento: a) TO-92 e b) SOIC; Diagrama de pinos: c) TO-92 e d) SOIC. ................. 66
Figura 32 - a) Placa Receptora de Frequência Cardíaca Polar RE07 e b) Faixa Transmissora T34 ........ 66
Figura 33 – Imagem Real e Diagrama de Pinos do PIC18LF4620. ......................................................... 67
Figura 34 - Desenvolvimento da Placa de Circuito Impresso Para a Estação Móvel ............................ 70
Figura 22 - Tela do Software. Aba Banco de Dados. ............................................................................. 71
Figura 23 - Tela do Software. Aba Amostragem. .................................................................................. 71
Figura 35 - Experimentação em Animais. a) Animal equipado com o sistema; b) Circuito alimentado
por uma bateria de 9 volts; c) Hardware encapsulado em uma caixa de plástico; d) Colar para fixar o
equipamento no animal; e) Computador com a estação coordenadora e software em funcionamento;
e f) Animal utilizado no experimento e autor do projeto. .................................................................... 73
10
Lista de Tabelas
Tabela 1 - Especificações da Camada Física .......................................................................................... 23
Tabela 2 - Estrutura de Um Pacote API Para Comando AT Local (0x08) ............................................... 33
Tabela 3 - Estrutura de Um Pacote API de Resposta a um Comando AT Local (0x88) .......................... 34
Tabela 4 - Estrutura de Um Pacote API Para Comando AT Remoto (0x17) .......................................... 36
Tabela 5 - Estrutura de Um Pacote API de Resposta a um Comando AT Remoto (0x97) ..................... 37
Tabela 6 - Estrutura de Um Pacote API de Requisição de Transmissão (0x10) ..................................... 38
Tabela 7 - Estrutura de Um Pacote API de Recebimento de Dados (0x90)........................................... 39
Tabela 8 - Estrutura de Um Pacote API de Status de Transmissão(0x8B) ............................................. 40
Tabela 9 - Pinos Configuráveis (GPIO) no Módulo XBee PRO S2 (Adaptado: DIGI, 2011). ................... 41
Tabela 10 – Parâmetros para Comandos AT de Configuração dos Pinos GPIO (Adaptado: DIGI, 2011).
............................................................................................................................................................... 42
Tabela 11 – Organização de Uma Amostra de Canais Analógicos e Digitais de Um Módulo XBee.
(Adaptado: DIGI, 2011).......................................................................................................................... 43
Tabela 12 - Exemplo de Uma Amostra de Canais Analógicos e Digitais (Adaptado: DIGI, 2011). ........ 44
Tabela 13 - Comparação Entre os Modos de Operação API e Transparente (ADAPTADO: DIGI, 2011).
............................................................................................................................................................... 45
Tabela 14 - Ranking dos Maiores Criadores de Caprinos do Mundo. (Fonte: FAO, dados de 2010). .. 52
Tabela 15 - Características do Módulo XBee PRO Series 2 da Digi ....................................................... 60
Tabela 16 - Principais Características do Microcontrolador PIC18LF4620............................................ 67
11
Lista de Abreviaturas
API - Application Programming Interface
APL - Application Layer
APS - Application SubLayer
BPSK - Binary Phase Shift Keying
CSMA-CA - Carrier Sense Multiple Access Collision Avoidance
DER - Diagrama Entidade Relacionamento
DHCP - Dynamic Host Configuration Protocol
DSSS - Direct Sequence Spread-Spectrum
EC - Estação Coordenadora
EM - Estações Móveis
ER - Estações de Referência
FAWC - Farm Animal Welfare Council
FC - Frequência cardíaca
FFDs - Full Function Devices
GPIO - General Purpose Input/Output
GPS - Global Positioning System
GSM - Global System for Mobile Communications
IEEE - Institute of Electrical and Electronics Engineers
LED - Light-emitting diode
LR-PAN, Low-Rate Wireless Personal Area Networks
MAC - Medium Access Control
NWK - Network Layer
O-QPSK - Offset Quadrature Phase Shift Keying
OSI - Open Systems Interconnection
PWM – Pulse Width Modulation
RFDs - Reduced Function Devices
RSSF - Redes de Sensores Sem Fio
RSSI - Received Strength Signal Indication
SBC - Sociedade Brasileira de Computação
SGBD - Sistema Gerenciador de Banco de Dados
TA - Temperatura do ar
TCP/IP - Transmission Control Protocol/Internet Protocol
UR - Umidade relativa
WSN - Wireless Sensor Networks
ZDO - ZigBee Device Objects
SMD – Surface Mounted Device
12
Sumário
1.
INTRODUÇÃO .............................................................................................................................. 14
1.1.
1.2.
2.
OBJETIVO ................................................................................................................................................ 16
OBJETIVOS ESPECÍFICOS ............................................................................................................................. 17
REVISÃO BIBLIOGRÁFICA ......................................................................................................... 18
2.1.
REDE DE SENSORES SEM FIO ....................................................................................................................... 18
™
2.2.
O PADRÃO ZIGBEE /IEEE 802.15.4 ........................................................................................................... 19
2.2.1.
Surgimento .................................................................................................................................. 19
2.2.2.
Organização e Arquitetura do Padrão ZigBee/IEEE 802.15.4...................................................... 22
2.3.
DISPOSITIVOS XBEE ................................................................................................................................... 24
2.3.1.
Modos de Operação do XBee ...................................................................................................... 27
2.3.1.1.
2.3.1.2.
2.3.2.
Modo de Operação Transparente (AT)....................................................................................................27
Modo de Operação API ...........................................................................................................................28
Configuração dos Módulos XBee ................................................................................................. 29
2.3.2.1.
Comandos AT no Modo de Operação Transparente (AT) .......................................................................30
2.3.2.2.
Comandos AT no Modo de Operação API ...............................................................................................32
2.3.2.2.1. Comandos AT Locais ..........................................................................................................................32
2.3.2.2.2. Comandos AT Remotos ......................................................................................................................35
2.3.3.
2.3.4.
2.3.4.1.
Transmissão de Dados no Modo de Operação API ...................................................................... 38
Entradas/Saídas Digitais e Analógicas nos Módulos XBee .......................................................... 41
Amostragem de Entradas Analógicas e Digitais ......................................................................................42
2.3.5.
Comparação Entre os Modos de Operação API e Transparente (AT) .......................................... 44
2.4.
LOCALIZAÇÃO DE NÓS MÓVEIS EM REDES DE SENSORES SEM FIO ....................................................................... 46
2.4.1.
Cálculo da Distância Relativa Entre Nós (Ranging) ..................................................................... 47
2.4.2.
Estimação da Localização dos Nós .............................................................................................. 48
2.4.2.1.
2.4.2.2.
Lateração .................................................................................................................................................49
Algoritmo do Mínimo Máximo ................................................................................................................50
2.4.3.
Refinamento ................................................................................................................................ 51
2.5.
CAPRINOCULTURA NO BRASIL ...................................................................................................................... 51
2.6.
BEM-ESTAR ANIMAL, BIOCLIMATOLOGIA E ZOOTECNIA DE PRECISÃO .................................................................. 53
2.6.1.
Influência de Variáveis Meteorológicas na Produção de Caprinos.............................................. 54
3.
MATERIAIS E MÉTODOS ............................................................................................................ 57
3.1.
SOFTWARE .............................................................................................................................................. 57
3.1.1.
Interface Gráfica do Software ..................................................................................................... 58
3.1.2.
Camada de Processamento de Dados ......................................................................................... 58
3.1.2.1.
Banco de Dados .......................................................................................................................................58
3.1.3.
Montagem e Gerenciamento de Pacotes de Rede API XBee ....................................................... 59
3.1.4.
Comunicação Serial ..................................................................................................................... 59
3.2.
HARDWARE ............................................................................................................................................. 60
3.2.1.
Características dos Módulos XBee PRO Series 2 .......................................................................... 60
3.2.2.
Estação Coordenadora (EC) ......................................................................................................... 61
3.2.3.
Estações de Referência (ER) ........................................................................................................ 62
3.2.4.
Estações Móveis (EM).................................................................................................................. 63
3.2.4.1.
3.2.4.2.
3.2.4.3.
3.2.4.4.
4.
Sensor de Umidade Relativa Honeywell HIH-5031..................................................................................64
Sensor de Temperatura ...........................................................................................................................65
Sensor de Frequência Cardíaca ...............................................................................................................66
Microcontrolador PIC 18LF4620 ..............................................................................................................67
RESULTADOS .............................................................................................................................. 69
13
4.1.
4.1.
4.2.
HARDWARE ............................................................................................................................................. 69
SOFTWARE .............................................................................................................................................. 70
EXPERIMENTOS EM ANIMAIS ....................................................................................................................... 72
5.
CONCLUSÕES ............................................................................................................................. 75
6.
REFERÊNCIAS ............................................................................................................................. 77
14
1.
Introdução
As Redes de Sensores Sem Fio (RSSF ou WSN em inglês, Wireless Sensor
Networks) constituem uma tecnologia emergente que tem proporcionado um
crescimento significativo das perspectivas industriais e científicas em todo o mundo.
O avanço da eletrônica tem permitido o desenvolvimento de sensores e
transceptores com consumo de energia e dimensões cada vez menores. Assim, o
uso de sensores sem fio organizados em rede com o objetivo de monitorar e
controlar um determinado ambiente, é uma forte tendência para os próximos anos.
No Brasil, a Sociedade Brasileira de Computação (SBC) identificou a
tecnologia como um dos principais desafios da pesquisa em computação no período
de 2006 a 2016 (SBC, 2006). Outros países, como Reino Unido e Estados Unidos
da América, também reconheceram as RSSF como uma das tecnologias mais
importantes para os próximos anos (HOPE e MILNER, 2004; BUTLER, 2006).
O uso de redes de sensores na agropecuária ainda é tímido. No entanto, o
potencial de aplicação da tecnologia neste setor é alto. No trabalho realizado por
WARK et al. 2007, por exemplo, é apresentado um sistema computacional baseado
em RSSF para medir o estado de um sistema complexo, composto por clima, solo,
pasto e animais (gado). Cada animal é equipado com um nó sensor que contém um
sistema de localização por GPS. Dessa forma, é possível, por exemplo, monitorar o
comportamento dos animais de acordo com as variações climáticas do ambiente e
seus hábitos de pastejo.
Além do comportamento diante de variações climáticas e hábitos de pastejo,
é interessante avaliar o bem-estar dos animais, que consiste basicamente em
mensurar a influência do ambiente sobre a saúde dos mesmos. Para NÓBREGA et
al. 2011, o bem-estar animal é fator determinante quando se deseja a maximização
da produção.
Para avaliar a influência do ambiente é necessário analisar as respostas
fisiológicas apresentadas pelos animais às variações do ambiente externo. Para
tanto, alguns indicadores podem ser utilizados, como, por exemplo, frequência
respiratória, frequência cardíaca, temperatura retal, sudorese e outros (SOUZA et
al., 2005). A escolha dos pequenos ruminantes como objeto de estudo é devida a
sua popularidade no Nordeste brasileiro, que atualmente concentra 90,8% do
15
rebanho nacional de caprinos. Mais informações sobre a caprinocultura no Brasil são
apresentadas na seção 2.5.
Neste trabalho é proposto um sistema completo para localização e
monitoramento de pequenos ruminantes baseado em uma rede de sensores sem fio
composta por módulos XBee/ZigBee 802.15.4. Cada animal é equipado com um
colar que possui um nó sensor.
O sistema proposto pode ser dividido em duas partes: subsistema de
monitoramento e subsistema de localização. O primeiro é responsável por medir e
armazenar dados de três variáveis: temperatura ambiente, umidade do ar e
frequência cardíaca do animal. Essas variáveis são medidas individualmente, em
cada animal. Logo, é possível obter dados mais precisos, uma vez que animais que
estejam sob a sombra de uma árvore, por exemplo, podem experimentar uma
sensação térmica diferente daqueles que estão sob o sol. A Figura 1 ilustra um
animal com o equipamento de monitoramento descrito.
Figura 1 - Ilustração de um Animal Equipado com um Nó Sensor
Já o subsistema de localização é responsável por determinar as coordenadas
geográficas de cada animal. Neste trabalho, com o objetivo de reduzir custos, optouse pelo uso de métodos de localização baseados na intensidade do sinal recebido
pelos transceptores (RSSI, Received Signal Strength Indicator). Assim, evita-se a
necessidade de uso de módulos GPS (Global Positioning System).
Os algoritmos de localização utilizados calculam a intensidade do sinal entre
transceptores instalados nos animais e transceptores instalados em quatro torres
fixas de referência (com coordenadas conhecidas) para estimar a localização de
16
cada animal. Dessa forma, é possível estimar as coordenadas do animal utilizando,
por exemplo, o método da lateração, como é discutido na seção 2.4. A Figura 2
apresenta uma visão geral do sistema proposto.
Figura 2 - Visão Geral do Sistema de Localização de Monitoramento Baseado em RSSF
1.1. Objetivo
Desenvolver um sistema composto por uma rede de sensores sem fio capaz
de auxiliar a análise do bem-estar animal por meio da medição de variáveis
meteorológicas (temperatura ambiente e umidade do ar) e da resposta fisiológica
fornecida pelo animal sob a forma de variações da frequência cardíaca. Além do
monitoramento dessas variáveis, o sistema deve ser capaz de estimar a localização
de cada animal, de forma a facilitar a identificação de hábitos de pastejo e alterações
comportamentais.
Os dados medidos pelos sensores e as coordenadas dos animais calculadas
pelo sistema devem ser armazenados em um banco de dados para que possam ser
consultados e analisados posteriormente.
17
1.2. Objetivos Específicos

Montagem e configuração de uma rede de sensores sem fio, baseada em
módulos XBee/ZigBee 802.15.4, para a aquisição de dados dos sensores
instalados nos animais;

Estudo e desenvolvimento de uma metodologia para a localização de nós
sensores utilizando a intensidade do sinal (RSSI) fornecida pelos módulos
XBee;

Projeto dos circuitos de condicionamento de sinal e métodos para a leitura
dos sensores de temperatura, umidade e frequência cardíaca;

Desenvolvimento do firmware a ser embarcado no microcontrolador
acoplado no animal para estimar a localização do nó sensor móvel e
realizar a leitura dos sensores;

Desenvolvimento de um software de aplicação composto por um banco de
dados e uma interface gráfica, que permita a visualização das medições
dos sensores em tempo real e consulta dos dados armazenados;

Desenvolvimento de placas de circuito impresso para os circuitos
projetados.
18
2.
Revisão Bibliográfica
2.1. Rede de Sensores Sem Fio
Uma RSSF pode ser definida como uma rede composta por nós sensores
que, cooperativamente, monitoram e podem controlar o ambiente. Dessa forma,
constituem uma tecnologia emergente que habilita uma funcionalidade sem
precedentes de interação entre pessoas, computadores e o ambiente à sua volta.
(BURATTI et al., 2009; LOUREIRO, 2006).
Os nós sensores, em uma RSSF típica, são capazes de medir variáveis em
um determinado ambiente, por meio de sensores ou transdutores, e transmitir esses
dados por meio de ondas eletromagnéticas para outras estações da rede. Para
tanto, esses nós possuem componentes comuns, tais como transceptor de rádio,
sensores, fonte de energia e microcontrolador. Opcionalmente, nós sensores,
podem incluir módulos de localização, geração de energia e atuadores. Na Figura 3
é apresentada uma descrição de alto nível de um nó sensor genérico.
Figura 3 – Descrição de Alto Nível de um Nó Sensor
Uma RSSF possui um nó sorvedouro (sink node) responsável por receber os
dados das leituras realizadas pelos nós sensores e repassá-las a um computador.
Esse computador possui soluções de software capazes de realizar o gerenciamento
e configuração da RSSF, armazenar os dados recebidos e tomar decisões de
acordo com a interpretação feita sobre esses dados, como, por exemplo, o
acionamento de um atuador. O nó coordenador não necessita estar conectado
diretamente ao computador, essa conexão pode ser feita através de um gateway de
internet, ou algo semelhante.
19
Em geral, os dados recebidos pelo sistema são armazenados em bancos de
dados com o auxílio de um Sistema Gerenciador de Banco de Dados (SGBD).
Adicionalmente, o software pode oferecer ao usuário final a funcionalidade de
acesso ao sistema por meio da Internet, o que demanda o uso de um servidor de
internet. Na Figura 4 é apresentada uma visão geral da arquitetura e organização de
uma RSSF típica.
Figura 4 – Visão Geral da Organização e Arquitetura de Uma RSSF
2.2. O Padrão ZigBee™/IEEE 802.15.4
2.2.1. Surgimento
As redes sem fio estão presentes em todos os lugares. No nosso dia a dia é
comum manusearmos aparelhos eletrônicos que utilizam diversos padrões de rede
sem fio para se comunicar, como WiFi e Bluetooth. Apesar da grande quantidade de
padrões existentes, no ano de 1999 foi identificado um nicho de mercado ainda não
explorado e que motivou a criação do padrão ZigBee™(Figura 5).
20
Figura 5 - Comparação de Tecnologias Sem Fio. (FONTE: GISLASON, 2008)
A maioria das tecnologias existentes até então oferecia altas taxas de
transmissão para um número relativamente pequeno de dispositivos e com um alto
consumo de energia. Nenhuma delas proporcionava uma infraestrutura de rede que
apresentasse as seguintes características:

Formação autônoma de redes com grandes quantidades de dispositivos em
uma grande área de cobertura, em que os dispositivos pudessem se
comunicar de forma confiável e segura por anos, sem a intervenção de um
operador;

Baixo consumo de energia associado a um reduzido custo de infraestrutura,
complexidade e tamanho;

Taxa de transmissão de dados relativamente baixa;

Um protocolo padronizado e aberto que permitisse a interoperabilidade entre
produtos de diferentes fabricantes para um mercado global.
Assim, em 2002 surgiu a ZigBee Alliance com o Slogan: “Wireless Control
That Simply Works” (Controles sem fios que simplesmente funcionam), e atualmente
engloba mais de 225 empresas (GISLASON, 2008). O padrão ZigBee pode ser
encontrado em uma variedade de aplicações em diversos setores da sociedade. A
Figura 6 ilustra as principais áreas de aplicação da tecnologia ZigBee.
21
Figura 6 – Aplicações do padrão ZigBee (ADAPTADO: GISLASON, 2008).
A pesquisa envolvendo RSSF tem avançado de forma significativa nos
últimos anos. No trabalho proposto por YICK et. al (2008) é apresentado um estado
da arte onde é possível observar o rápido crescimento desta área de pesquisa em
relação a um estudo semelhante realizado por AKYLDIZ et al. (2002) seis anos
antes. Isso se deve, principalmente, à popularização do padrão ZigBee.
Na área industrial, SUNG e HSU (2011) demonstraram a viabilidade de uso
do padrão ZigBee num ambiente industrial, visando o monitoramento de grandezas
em tempo real e controle remoto de equipamentos que oferecem risco à saúde do
operador.
Na área médica, apesar de existirem diversas aplicações, como o sistema de
monitoramento médico pessoal proposto por CERNY e PENHAKER (2010), os
avanços ainda encontram alguns desafios como a privacidade, largura de banda,
consumo de energia e outros elencados por ALEMDAR e HERSO (2010).
As RSSF também se destacam na agricultura de precisão uma vez que
permitem um acompanhamento em tempo real de variáveis (como umidade do solo
e temperatura) que podem proporcionar uma melhor qualidade da produção. (WARK
et al., 2007; Kalaivani et al., 2011). No estudo realizado por CARDENASLAILHACAR e DUKES (2010) foi verificado que o manejo da irrigação feito via
sensoriamento da umidade do solo pode resultar em uma economia de até 80% de
água.
22
2.2.2. Organização e Arquitetura do Padrão ZigBee/IEEE 802.15.4
É importante ressaltar a diferença entre os padrões IEEE 802.15.4 e ZigBee.
O padrão IEEE 802.15.4 define as duas camadas de mais baixo nível: a camada
física (PHY, Physical) e de controle de acesso ao meio (MAC, Medium Access
Control) para redes sem fio caracterizadas por possuírem custo e taxa de
transmissão reduzidos (LR-PAN, Low-Rate Wireless Personal Area Networks).
Já o padrão ZigBee, define as cinco camadas de mais alto nível: a camada de
rede (NWK, Network Layer) e a camada de aplicação (APL, Application Layer), que
por sua vez engloba as camadas de Quadros da Aplicação (Application Framework),
de Objetos de Dispositivos ZigBee (ZDO, ZigBee Device Objects) e a subcamada de
suporte a aplicação (APS, Application SubLayer). (BARONTI, 2007). De maneira
geral, neste trabalho iremos utilizar a terminologia ZigBee para tratar de todas as
camadas, incluindo as definidas pelo IEEE 802.15.4. Na Figura 7 é apresentado um
diagrama que ilustra a arquitetura e organização do padrão ZigBee.
Figura 7 – Diagrama da Arquitetura e Pilha de Protocolos ZigBee. (FONTE: BARONTI et al., 2007)
O ZigBee não se encaixa exatamente no modelo OSI de sete camadas, no
entanto possui alguns elementos semelhantes como as camadas PHY, MAC e
NWK. As demais camadas do modelo OSI (transporte, sessão, apresentação e
23
aplicação) estão englobadas nas camadas APS e ZDO do modelo ZigBee.
(GISLASON, 2008).
A camada física (PHY) é responsável, principalmente, por transformar
pacotes de dados digitais em ondas eletromagnéticas que serão transmitidas
através do ar e vice-versa. Paralelamente, também oferece as funcionalidades de
seleção de canais, estimativa da qualidade da transmissão e detecção de canais
disponíveis. Para tanto, suporta três bandas de frequência: 2450 MHz (16 canais,
250 kbps), 915 MHz (10 canais, 40 kbps) e 868 MHz (1 canal, 20 kbps), todas com
espalhamento espectral por sequência direta (DSSS, Direct Sequence SpreadSpectrum).
A modulação do sinal pode ser de dois tipos, O-QPSK (Offset Quadrature
Phase Shift Keying) para a frequência de 2450 MHz ou BPSK (Binary Phase Shift
Keying) para as frequências de 868 e 915 MHz. Para aumentar a confiabilidade, o
ZigBee adota a técnica CSMA-CA (Carrier Sense Multiple Access Collision
Avoidance), responsável por realizar a verificação da disponibilidade do canal antes
de iniciar uma transmissão. (BARONTI, 2007). A Tabela 1 resume as características
especificadas na camada fisica.
Tabela 1 - Especificações da Camada Física
2450 MHz
915 MHz
868 MHz
Máxima taxa de transmissão
250 kbps
40 kbps
20 kbps
Número de canais
16
10
1
Modulação
O-QPSK
BPSK
BPSK
Bits por símbolo
4
1
1
A camada define os Dispositivos de Função Completa (FFDs, Full Function
Devices), operando como roteadores ou coordenadores de rede e Dispositivos de
Função Reduzida (RFDs, Reduced Function Devices) que operam apenas como
dispositivo final. Esta camada também define outras características, incluindo a
identificação da rede (PAN ID), descoberta de rede através de envios de
sinalizações
(beacons)
e
recebimento
de
respostas.
Também
oferece
a
funcionalidade de confirmação de comunicação entre nós e alguns comandos para a
formação de redes. No entanto, a camada MAC não dá suporte a transmissões de
múltiplos saltos.
24
A camada de rede (NWK) é responsável por garantir transmissões de
múltiplos saltos, ou seja, habilita a funcionalidade de formação de redes em malha
(Mesh
Networking).
Esta
característica
inclui
transmissões
em
broadcast,
determinação de rotas de pacotes unicast, bem como a verificação da entrega
confiável destes pacotes. Dessa forma, uma rede ZigBee pode se organizar em
diversas topologias de rede, como ilustra a Figura 8. A camada de rede também
oferece serviços de segurança, incluindo a entrada e saída segura de nós em redes
e a criptografia de dados.
Figura 8 - Topologias de Redes ZigBee
Já a camada de aplicação (APL) e suas subcamadas, são responsáveis por
filtrar pacotes destinados a nós não registrados na rede, fornecer confirmação de
recebimento confiável fim-a-fim, manter tabelas de endereçamento, conexão e
grupos locais, bem como realizar tentativas automáticas de retransmissão quando
não há confirmação de entrega bem sucedida de um pacote. Também são
armazenados nesta camada o estado corrente do nó e suas características de
segurança e agrupamento.
2.3. Dispositivos XBee
Dentre os vários dispositivos de hardware baseados no protocolo ZigBee, um
modelo bastante conhecido é o XBee, atualmente fabricado pela líder de mercado
25
Digi International1, que adquiriu a MaxStream, antiga fabricante deste dispositivo. Os
módulos XBee são compostos, basicamente, por um microcontrolador e um
transceptor. O microcontrolador contém o firmware com a implementação do
protocolo ZigBee e a especificação do comportamento do dispositivo (Coordenador,
Roteador ou Dispositivo Final).
Cada dispositivo possui dois endereços, o MY (16 bits) e o Número Serial (64
bits). O MY é o endereço de rede, variável, e é distribuído automaticamente pelo
coordenador assim que o nó entra na rede. Uma analogia interessante é associar o
endereço MY com o endereço IP nas redes TCP/IP com DHCP, em que cada
máquina recebe um endereço automaticamente. Já o Número Serial é único e
invariável para cada dispositivo fabricado (semelhante ao endereço MAC das placas
de rede Ethernet).
Uma rede formada por dispositivos XBee possui apenas um coordenador,
com endereço de rede (MY) igual a zero. Roteadores e Dispositivos Finais podem
ser utilizados em várias quantidades, de acordo com a necessidade. No entanto,
Dispositivos Finais só se comunicam com Roteadores ou com o Coordenador da
rede. Transmissões broadcast e unicast estão disponíveis. No caso da transmissão
broadcast utiliza-se o endereço de 64 bits de destino igual a 0x000000000000FFFF.
Os módulos XBee são fabricados em diversas versões, que variam de acordo
com o modelo da antena, encapsulamento, frequência de operação e protocolo
utilizado. Na Figura 9 são apresentados os principais modelos.
1
www.digi.com
26
Figura 9 – Principais Modelos de Módulos XBee PRO da Digi International
Nota-se que há uma grande variedade de opções de módulos XBee
disponíveis no mercado, portanto, é interessante considerar alguns aspectos antes
da escolha de um modelo:
a) Frequência de operação e Taxa de Transmissão: os modelos que
operam na frequência de 2,4 GHz oferecem uma taxa de transmissão
maior em relação aos modelos de 900 e 868 MHz, por outro lado possuem
alcance menor. Outro detalhe importante é que em alguns países, como o
Brasil, a banda de frequência de 900 MHz, por exemplo, não é
homologada pela ANATEL para este tipo de aplicação.
b) Alcance X Antena: é importante considerar a relação entre o alcance que
os módulos podem atingir e a antena utilizada. Módulos com antenas on
chip (Figura 9c) proporcionam um menor alcance, no entanto, ocupam um
espaço físico também menor. Já módulos com antenas externas (Figuras
Figura 9b e Figura 9d) proporcionam um alcance maior, todavia ocupam
um grande espaço físico. De forma análoga, os modelos com antenas
Whip (Figura 9a) tentam equalizar essa relação oferecendo alcance e
tamanho intermediários.
27
c) Potência de transmissão X Consumo Energético: os módulos são
fabricados em duas versões, a versão XBee PRO e a XBee. A principal
diferença entre eles é que a potência de transmissão do modelo PRO é
maior. Logo, proporcionam um alcance mais elevado. Por outro lado, o
consumo de potência dos XBee em relação aos XBee PRO é
significativamente menor.
d) Custo: os modelos que possuem antena externa geralmente apresentam
um custo maior, uma vez que é necessário adquirir as antenas ou
conectores separadamente.
e) Complexidade do projeto: dependendo da complexidade do projeto,
projetistas experientes podem utilizar o modelo S2B que possui um
microcontrolador adicional incorporado ao módulo. Isso permite ao
projetista embarcar um firmware próprio que vai interagir com o firmware
do fabricante. Como vantagem, pode-se citar a ampliação da autonomia
do nó sensor, uma vez que decisões pré-programadas podem ser
tomadas automaticamente e localmente, sem a necessidade de um
comando externo. Por outro lado, é necessário, por parte do projetista, um
conhecimento mais aprofundado da tecnologia.
2.3.1. Modos de Operação do XBee
Os módulos XBee podem operar de duas maneiras: no modo Transparente
(AT) e no modo API (Application Programming Interface).
2.3.1.1.
Modo de Operação Transparente (AT)
No modo de operação transparente, o dispositivo atua simplesmente como
um substituto da linha de comunicação serial. Assim, todos os dados que são
recebidos via RS232 no pino de entrada (DIN) são transmitidos via Rádio
Frequência (RF) para o módulo de destino. Da mesma maneira, os dados que
chegam por meio da antena RF são direcionados ao pino de saída (DOUT) (DIGI,
2011).
Nesse modo de operação, os comandos de configuração só podem ser
recebidos localmente, por intermédio da interface serial (RS232), o que impossibilita
28
a configuração e a utilização à distância dos periféricos contidos no XBee (entradas
e saídas digitais, conversores AD, etc). Também não é possível identificar o
endereço de origem de dados recebidos ou receber mensagens de status indicando
o sucesso ou a natureza de uma falha na transmissão.
2.3.1.2.
Modo de Operação API
O modo de operação API (Application Programming Interface) é uma
alternativa ao modo de operação transparente. A API, baseada em quadros
(frames), estende o nível no qual a aplicação pode interagir com os recursos de rede
do módulo. Nesse modo de operação, todos os dados enviados e recebidos pelo
módulo XBee são organizados em pacotes (com formato especificado pelo
fabricante) que definem as operações ou eventos dentro do módulo.
A estrutura geral de um pacote API é apresentada na Figura 10. O primeiro
byte é o delimitador de início, que possui o valor 7E em hexadecimal. Qualquer dado
recebido antes do delimitador de início é descartado. Os bytes 2 e 3 informam o
tamanho do quadro que está sendo recebido. Os bytes 4 a n compõem o quadro de
dados e definem a operação a ser realizada. O último byte contém a soma de
verificação (checksum) do quadro de dados, calculado pela Equação 1 (0xFF –
Somatório dos bytes 4 a n do pacote). Caso o recebimento dos dados ou o valor do
checksum esteja incorreto, um pacote de status indicando a natureza do erro é
retornado.
Figura 10 - Estrutura Geral de um Quadro (frame) API. (Fonte: DIGI, 2011).
∑
Equação 1
29
Os dados mais importantes do pacote API estão contidos nos bytes 4 a n. O
byte 4 (cmdID) informa o tipo de mensagem API que está contida nos bytes 5 a n
(cmdData). Essas mensagens ou operações podem ser de vários tipos:

Transmissão de uma sequência de bytes (cmdID = 0x10 ou 0x11);

Recebimento de uma sequência de bytes (cmdID = 0x90 ou 0x91);

Execução de comandos (AT) de configuração remotos ou locais que incluem,
dentre outras operações (cmdID = 0x08, 0x09 ou 0x17):
o Configuração
do
comportamento
dos
pinos
de
entrada/saída,
possibilitando o acionamento de saídas digitais;
o Configuração de parâmetros de rede (Chave secreta, nome do nó,
PAN ID, número máximo de saltos, etc);
o Configuração de intervalos de tempo em modo sleep para dispositivos
finais;
o Aquisição de amostras de entradas digitais e analógicas;

Criação de rotas de rede (cmdID = 0x21);

Mensagens de status que informam se um determinado quadro foi entregue
corretamente e, em caso negativo, indicam a natureza do erro (cmdID = 0x88,
0x8B ou 0x97);
O formato do quadro de dados, bytes 5 a n (cmdData), varia de acordo com o
tipo de operação a ser realizada. Mais informações e exemplos sobre todos os tipos
de pacotes API podem ser encontradas em DIGI (2011).
2.3.2. Configuração dos Módulos XBee
Nos dispositivos XBee series 2 o usuário deve carregar previamente um
firmware que contém as informações sobre o comportamento do dispositivo na rede,
ou seja, determinar se ele é um Roteador, Dispositivo final ou o Coordenador. Para
tanto, o fabricante disponibiliza em seu sítio2, gratuitamente, a ferramenta X-CTU
(Figura 11), que permite o carregamento deste firmware e a configuração de todos
os parâmetros do dispositivo, a partir de uma interface intuitiva.
2
www.digi.com
30
As setas em vermelho da Figura 11 destacam alguns parâmetros importantes
do módulo XBee. À medida que o usuário solicita a leitura ou alteração de
parâmetros, o software envia automaticamente os respectivos comandos AT para
XBee pela interface RS232 e exibe os resultados na tela. Dentre os parâmetros
configuráveis, destacam-se: nome do nó, endereço de destino, velocidade de
comunicação RS232 (baud rate), comportamento dos pinos de entrada e saída,
chave secreta de criptografia, ID da rede, entre outros.
Figura 11 - Tela do Software X-CTU. Utilizado para Configuração de Módulos XBee.
2.3.2.1.
Comandos AT no Modo de Operação Transparente (AT)
A configuração dos parâmetros de um módulo XBee, operando no modo
Transparente (AT), é realizada por meio de comandos AT. Estes comandos são
recebidos a pela interface serial do módulo XBee.
Para que os comandos não sejam interpretados como uma sequência de
dados a ser transmitida para um módulo de destino, o XBee deve entrar no “modo
31
comando”. Essa operação é realizada pelo recebimento da sequência de três
caracteres “+++”3. Essa sequência faz com que o módulo XBee pare de transmitir os
dados que chegam à sua interface RS232 e passe a interpretá-los como comandos
de configuração (Comandos AT). Um comando AT é estruturado como apresentado
na Figura 12.
Figura 12 - Sintaxe de Comandos AT no Modo de Operação Transparente
Cada comando deve possuir o prefixo “AT” concatenado com o nome do
comando a ser executado (2 caracteres ASCII). Em seguida, se necessário, é
colocado o parâmetro do comando. Por fim, é confirmada a execução do comando
pelo envio de um byte de retorno de carro.
Quando um comando é executado sem a passagem de parâmetro, o módulo
XBee interpreta que o usuário deseja consultar o valor daquele comando e retorna
uma mensagem com o respectivo resultado. Caso algum parâmetro seja fornecido o
dispositivo altera o valor do referido parâmetro e retorna uma confirmação (“OK”). Se
o parâmetro ou o comando possuir um valor inválido, uma mensagem de erro
(“ERROR”) é retornada.
Como exemplo, considere a Figura 13, que apresenta uma sequência de
comandos AT enviados para um módulo XBee utilizando o terminal serial da
ferramenta X-CTU4. Os caracteres em cor azul foram digitados no computador e
enviados para o XBee. Os caracteres em cor vermelha são respostas enviadas do
módulo XBee para o computador. Os comentários em verde explicam o significado
de cada linha enviada ou recebida pelo terminal.
As definições e exemplos de todos os comandos AT disponíveis são
apresentados em DIGI (2011).
3
O caractere ‘+’ é utilizado por padrão. No entanto, o usuário pode utilizar qualquer outro caractere ASCII,
bastando apenas configurar o parâmetro CC (Command Sequence Character).
4
Neste exemplo foi utilizado o terminal serial da ferramenta X-CTU, no entanto, o projetista pode usar qualquer
outra ferramenta ou construir o seu próprio software de comunicação com a interface RS232 para enviar
comandos AT.
32
Figura 13 - Exemplos de Execução de Comandos AT no Modo Transparente
É importante ressaltar que os comandos AT, no modo de operação
Transparente (AT), só podem ser executados localmente, ou seja, diretamente por
meio da interface RS232 do dispositivo. Não podem, portanto, ser transmitidos
através do ar e executados em módulos remotos. Esta característica limita a
capacidade de gerenciamento da rede, uma vez que o usuário não poderá
configurar as funcionalidades ou utilizar os periféricos do dispositivo à distância.
2.3.2.2.
Comandos AT no Modo de Operação API
Conforme já mencionado na seção 2.3.1.2, o modo de operação API exige
que todas as informações trocadas com um módulo XBee sejam empacotadas em
um formato específico (Figura 10). Em contrapartida, este modo de operação
permite que comandos AT sejam executados tanto localmente quanto remotamente,
o que amplia o nível de gerenciamento e a funcionalidade da rede.
2.3.2.2.1.
Comandos AT Locais
A execução local de comandos AT considera que o XBee está conectado
diretamente, através de sua interface serial, ao dispositivo que deseja configurá-lo,
semelhante ao exemplo apresentado na Figura 13. Esse dispositivo pode ser um
33
computador, microcontrolador ou qualquer outro que possua interface de
comunicação serial.
A Figura 14 ilustra a troca de pacotes API para execução local de comandos
AT. O dispositivo que envia os comandos deve montar pacotes do tipo 0x08 ou 0x09
e enviá-los por meio da interface serial. Como resposta, um pacote de status do tipo
0x88 é recebido informando se o comando foi executado com sucesso e, caso
negativo, informa a natureza da falha.
Figura 14 - Troca de Pacotes API Para a Execução Local de Comandos AT
A estrutura completa de um pacote API para comando AT local é apresentada
na Tabela 2. Como exemplo, foi utilizado o comando “NI” (Node Identifier) que pode
alterar ou consultar o nome do dispositivo. Observe que não foi atribuído parâmetro;
logo, este comando consultará o nome do módulo XBee e retornará um pacote do
tipo 0x88 com o resultado.
A diferença entre os pacotes 0x08 e 0x09 é que no primeiro o comando AT é
executado imediatamente após o recebimento. Já no segundo, o comando é
enfileirado na memória do módulo XBee e só é executado quando um comando AT
de confirmação (AC – Apply Changes) ou algum pacote do tipo 0x08 é recebido.
Tabela 2 - Estrutura de Um Pacote API Para Comando AT Local (0x08)
Campos do Pacote
Índice
PACOTE API
Tipo do pacote API
ID do quadro (ACK)
Comando AT
Valor do Parâmetro
Descrição
0
0x7E
MSB 1
0x00
LSB
2
0x04
Quantidade de bytes entre o tamanho do pacote e
o checksum. Neste exemplo 4 bytes = 0x04
3
0x08
Pacote do tipo 0x08 (comando AT local)
Delimitador de Início
Tamanho do Pacote
Exemplo
4
0x01
5
0x4E (Letra ‘N’)
6
0x49 (Letra ‘I’)
Obrigatório em todo pacote API
O usuário pode Identificar o pacote com um
número arbitrário para conferir a mensagem de
status. Se for configurado como 0, nenhuma
resposta de status é enviada.
Nome do Comando AT – Dois caracteres ASCII.
Neste exemplo executa-se o comando NI – Node
Identifier
Quando presente indica que se deseja alterar o
34
(Opcional)
Soma de verificação
(Checksum)
7
0x5F
parâmetro do módulo para o valor fornecido.
Neste exemplo, sem parâmetro, realiza-se uma
consulta do nome do dispositivo (Comando NI).
0xFF – Soma dos bytes a partir do índice 3 até o
byte anterior ao checksum:
0xFF – (0x08+0x01+0x4E+0x49) = 0x5F
O pacote de resposta a um comando AT local é muito semelhante ao pacote
descrito na Tabela 2. A única diferença é a adição de um byte de status que informa
se foi possível realizar a operação. A Tabela 3 apresenta a estrutura de um pacote
de resposta (0x88). Observe, neste exemplo, a presença do nome do dispositivo
(“SENSOR_UMIDADE”), retornado como parâmetro do comando NI (Node Identifier)
e o byte de status que informa o sucesso na operação.
Tabela 3 - Estrutura de Um Pacote API de Resposta a um Comando AT Local (0x88)
Campos do Pacote
Delimitador de Início
Tamanho do Pacote
Tipo do pacote API
ID do quadro (ACK)
Comando AT
PACOTE API
Status do Comando
Índice
Descrição
0
0x7E
MSB 1
0x00
LSB 2
0x13
Quantidade de bytes entre o tamanho do pacote e
o checksum. Neste exemplo 19 bytes = 0x13
3
0x88
Pacote do tipo 0x88 (Status de comando AT local)
4
0x01
5
0x4E (‘N’)
6
0x49 (‘I’)
7
0x00
8
9
10
11
Valor do Parâmetro
(Opcional)
Exemplo
12
13
14
15
16
17
Obrigatório em todo pacote API
O usuário pode Identificar o pacote com um
número arbitrário para conferir a mensagem de
status. Se for configurado como 0, nenhuma
resposta de status é enviada.
Nome do Comando AT – Dois caracteres ASCII
Este exemplo é a resposta do comando NI – Node
Identifier
0 = OK
1 = ERRO
2 = Comando Inválido
3 = Parâmetro Inválido
4 = Falha na Transmissão
0x53 (‘S’)
0x45 (‘E’)
0x4E (‘N’)
0x53 (‘S’)
0x4F (‘O’)
0x52 (‘R’)
0x5F (‘_’)
0x55 (‘U’)
0x4D (‘M’)
0x49 (‘I’)
Se um parâmetro for configurado, este campo não
retorna nada. Se for realizada uma consulta, o
valor do parâmetro é retornado.
Neste exemplo é retornado o valor do parâmetro
NI (Node Identifier) que é “SENSOR_UMIDADE”.
35
18
19
20
21
Soma de verificação
(Checksum)
2.3.2.2.2.
22
0x44 (‘D’)
0x41 (‘A’)
0x44 (‘D’)
0x45 (‘E’)
0xAD
0xFF – Soma dos bytes a partir do índice 3 até o
byte anterior ao checksum
Comandos AT Remotos
A principal vantagem proporcionada pelo uso do modo de operação API, em
relação ao modo Transparente (AT) é a capacidade de execução remota (à
distância) de comandos AT. Isto inclui, dentre outras funcionalidades, a configuração
de parâmetros de rede, acionamento de saídas digitais, leitura de entradas
analógicas (sensores) e recebimento de mensagens de status da execução destes
comandos.
Quando nos referimos à execução remota de comandos AT podemos nos
basear na Figura 15, na qual um dispositivo que possui interface serial (computador,
microcontrolador, etc) é responsável por montar o pacote de requisição de Comando
AT Remoto (0x17) e enviá-lo através da interface serial para um módulo XBee. Este
módulo verifica o endereço de destino e encaminha a mensagem via RF para o
destinatário que, por sua vez, responde com um pacote do tipo 0x97 informando o
resultado da operação.
Figura 15 - Troca de Pacotes API Para a Execução Remota de Comandos AT
A estrutura de um pacote de requisição de comando AT remoto é
apresentada na Tabela 4 e, como exemplo, configura-se o pino “D2” como entrada
analógica. Observe que na requisição de comando AT remoto aparecem novos
campos, como os endereços do destinatário e as opções de comando remoto que
permitem, dentre outras funcionalidades, o enfileiramento da requisição.
36
Tabela 4 - Estrutura de Um Pacote API Para Comando AT Remoto (0x17)
Campos do Pacote
Índice
Exemplo
Descrição
0
0x7E
MSB 1
0x00
LSB
2
0x10
Quantidade de bytes entre o tamanho do pacote e o
checksum. Neste exemplo 16 bytes = 0x10
Tipo do pacote API
3
0x17
Pacote do tipo 0x17 (comando AT remoto)
ID do quadro (ACK)
4
0x02
O usuário pode Identificar o pacote com um número
arbitrário para checar a mensagem de status. Se for
configurado como 0, nenhuma resposta de status é
enviada.
5
0x00
6
0x13
7
0xA2
8
0x00
9
0x40
10
0x6C
0x0000000000000000: Reservado para o coordenador
da rede
11
0x52
0x000000000000FFFF: Endereço de Broadcast
12
0x9B
13
0xA1
14
0x83
15
0x02
16
0x44 (‘D’)
17
0x32 (‘2’)
Delimitador de Início
Tamanho do Pacote
Endereço de 64 bits
de destino (SH,SL)
PACOTE API
Endereço de 16 bits
de destino (MY)
Opções de Comando
Remoto
Comando AT
Valor do Parâmetro
(Opcional)
Soma de verificação
(Checksum)
0x02
18
0xFA
Obrigatório em todo pacote API
Endereço de 64 bits do destinatário. Os seguintes
endereços também são suportados:
Endereço de 16 bits do destinatário. Deve ser igual a
0xFFFE se o endereço do destinatário é desconhecido ou
a transmissão broadcast.
Configurado bit a bit, este campo pode habilitar
algumas funcionalidades:
0x01 – Desabilita resposta ACK
0x02 – Executa o comando imediatamente (Apply
Changes). Se este bit não for setado, a requisição fica
enfileirada e comando AC deve ser enviado para
confirmar a execução.
0x40 - Usa o tempo limite de transmissão estendida
para este destino.
Nome do Comando AT – Dois caracteres ASCII. Neste
exemplo executa-se o comando D2, que permite
configurar o comportamento do pino D2.
Quando presente indica que se deseja alterar o
parâmetro do módulo para o valor fornecido.
Neste exemplo, configura-se o pino D2 como entrada
analógica. O comando D2, utilizado como exemplo,
admite os seguintes argumentos:
0x00 – Desabilitado
0x01 – Não utilizado
0x02 – Conversor Analógico-Digital
0x03 – Entrada Digital
0x04 – Saída Digital em Nível Baixo
0x05 – Saída Digital em Nível Alto
0xFF – Soma dos bytes a partir do índice 3 até o byte
anterior ao checksum.
37
O pacote de resposta a um comando AT remoto é semelhante ao pacote de
requisição apresentado anteriormente. A única diferença é a substituição do campo
de opções do comando remoto pelo campo de status do comando. A Tabela 5
apresenta a estrutura de um pacote API de resposta ao comando AT remoto
exemplificado na Tabela 4.
Tabela 5 - Estrutura de Um Pacote API de Resposta a um Comando AT Remoto (0x97)
Campos do Pacote
Índice
Exemplo
Descrição
0
0x7E
MSB 1
0x00
LSB
2
0x0F
Tipo do pacote API
3
0x97
ID do quadro (ACK)
4
0x02
5
0x00
6
0x13
7
0xA2
8
0x00
9
0x40
10
0x6C
0x0000000000000000: Reservado para o coordenador
da rede
11
0x52
0x000000000000FFFF: Endereço de Broadcast
12
0x9B
13
0xA1
14
0x83
15
0x00
16
0x44 (‘D’)
17
0x32 (‘2’)
Delimitador de Início
Tamanho do Pacote
Endereço de 64 bits
de destino (SH,SL)
PACOTE API
Endereço de 16 bits
de destino (MY)
Status do comando
Comando AT
Obrigatório em todo pacote API
Quantidade de bytes entre o tamanho do pacote e o
checksum. Neste exemplo 15 bytes = 0x0F
Pacote do tipo 0x97 (resposta a um comando AT
remoto)
O usuário pode Identificar o pacote com um número
arbitrário para checar a mensagem de status. Se for
configurado como 0, nenhuma resposta de status é
enviada.
Endereço de 64 bits da fonte. Os seguintes endereços
também são suportados:
Endereço de 16 bits da fonte. Deve ser igual a 0xFFFE se
o endereço do destinatário é desconhecido ou a
transmissão broadcast.
0x00 = OK
0x01 = ERRO
0x02 = Comando Inválido
0x03 = Parâmetro Inválido
0x04 = Falha na Transmissão
Nome do Comando AT – Dois caracteres ASCII. Neste
exemplo executa-se o comando NI – Node Identifier
Quando presente indica o valor do parâmetro
consultado.
Valor do Parâmetro
(Opcional)
Soma de verificação
(Checksum)
18
0x7E
Neste exemplo, o comando D2 foi utilizado para
configurar o pino D2 como entrada analógica. Logo,
nada é retornado, já que não foi realizada uma consulta.
0xFF – Soma dos bytes a partir do índice 3 até o byte
anterior ao checksum.
38
2.3.3. Transmissão de Dados no Modo de Operação API
Para realizar uma transmissão de dados, isto é, enviar uma sequência
arbitrária de bytes entre dispositivos XBee é necessário conhecer, pelo menos, três
tipos de pacotes:
Pacote de requisição de transmissão (Tipo do quadro 0x10);
Pacote de status da transmissão (Tipo do quadro 0x88);
Pacote com os dados recebidos (Tipo do quadro 0x90).
A Figura 16 ilustra a dinâmica da troca de pacotes durante a transmissão de
dados.
Figura 16 - Troca de Pacotes Para a Transmissão de Dados
Para iniciar a transmissão de uma mensagem deve-se enviar uma sequência
de bytes formatada como apresentado na Tabela 6. Neste exemplo, é realizada a
transmissão da mensagem “OLA” para um dispositivo XBee de destino com
endereço físico 0x0013A200406C529B.
Tabela 6 - Estrutura de Um Pacote API de Requisição de Transmissão (0x10)
Campos do Pacote
Índice
Tipo do pacote API
PACOTE API
ID do quadro (ACK)
Endereço de 64 bits
de destino (SH e SL
do destinatário)
Descrição
0
0x7E
MSB 1
0x00
LSB
2
0x16
Quantidade de bytes entre o tamanho do pacote e o
checksum. Neste exemplo 22 bytes (0x16)
3
0x10
Pacote do tipo 0x10 (Transmissão de dados RF)
4
0x01
O usuário pode Identificar o pacote com um número
arbitrário para checar a mensagem de status. Se for
configurado como 0, nenhuma resposta de status é
enviada.
MSB 5
0x00
6
0x13
7
0xA2
8
0x00
9
0x40
Delimitador de Início
Tamanho do Pacote
Exemplo
Obrigatório em todo pacote API
Endereço de 64 bits do destinatário. Os seguintes
endereços também são suportados:
0x0000000000000000: Reservado para o coordenador
da rede
39
10
0x6C
11
0x52
LSB 12
0x9B
Endereço de 16 bits
de destino. (MY do
destinatário)
13
0xFF
14
0xFE
Raio do Broadcast
15
0x00
Opções
16
0x00
17
0x4F (‘O’)
18
0x4C (‘L’)
19
0x41(‘A’)
20
0xC7
Mensagem (Dados)
Soma de verificação
(Checksum)
0x000000000000FFFF: Endereço de Broadcast
Endereço de 16 bits do destinatário. Deve ser igual a
0xFFFE se o endereço do destinatário é desconhecido ou
a transmissão broadcast.
Número máximo de saltos de uma transmissão
broadcast. (0x00 é o máximo possível).
Configurado bit a bit, este campo pode habilitar
algumas funcionalidades:
0x01 – Desabilita resposta ACK
0x20 – Habilita Encriptação (Se EE=1)
0x40 - Usa o tempo limite de transmissão estendida
para este destino.
Mensagem (dados) que serão transmitidos via RF.
0xFF – Soma dos bytes a partir do índice 3 até o byte
anterior ao checksum.
Após o pacote de requisição de transmissão ser enviado, o dispositivo XBee
de destino irá fornecer no pino de saída da serial (DOUT) um pacote do tipo 0x90,
contendo a mensagem recebida (“OLA”), endereço do XBee de origem e outras
informações como apresentado na Tabela 7.
Tabela 7 - Estrutura de Um Pacote API de Recebimento de Dados (0x90)
Campos do Pacote
Índice
Tipo do pacote API
(Frame Type)
PACOTE API
Endereço de 64 bits
do XBee fonte
(SH,SL)
Endereço de 16 bits
Descrição
0
0x7E
MSB 1
0x00
LSB
2
0x16
Quantidade de bytes entre o tamanho do pacote e o
checksum. Neste exemplo 22 bytes (0x16)
3
0x90
Pacote do tipo 0x90 (Recebimento de Dados RF)
MSB 4
0x00
5
0x13
6
0xA2
7
0x00
8
0x40
9
0x6C
10
0x52
LSB 11
0x9B
12
0x7D
Delimitador de Início
Tamanho do Pacote
Exemplo
Obrigatório em todo pacote API
Endereço de 64 bits do remetente. É atribuído
0x000000000000FFFF se o endereço é desconhecido.
Endereço de 16 bits do remetente.
40
do XBee fonte (MY)
13
Opções de recepção
Dados recebidos
Soma de verificação
(Checksum)
0x85
14
0x00
15
0x4F (‘O’)
16
0x4C (‘L’)
17
0x41(‘A’)
18
0x43
0x01 – Pacote reconhecido
0x02 – Pacote broadcast
0x20 – Pacote encriptado com APS
0x40 – Pacote enviado de um end device
Nota: Opções podem ser combinadas. Por exemplo,
0x40 e 0x01 vão aparecer como 0x41. Outros valores
possíveis são 0x21, 0x22, 0x41, 0x42, 0x60, 0x61, 0x62.
Mensagem (dados) recebidos via RF.
0xFF – Soma dos bytes a partir do índice 3 até o byte
anterior ao checksum.
Após a transmissão dos dados o dispositivo XBee que originou a transmissão
recebe um pacote de status que informa se a mensagem foi entregue com sucesso
e, caso contrário, informa a natureza da falha. A Tabela 8 apresenta a estrutura de
um pacote de status da transmissão.
Tabela 8 - Estrutura de Um Pacote API de Status de Transmissão(0x8B)
Campos do Pacote
Índice
Exemplo
Descrição
0
0x7E
MSB 1
0x00
LSB
2
0x16
Quantidade de bytes entre o tamanho do pacote e o
checksum. Neste exemplo 22 bytes (0x16)
Tipo do pacote API
(Frame Type)
3
0x8B
Pacote do tipo 0x8B (Pacote de status da transmissão)
ID do quadro (ACK)
4
0x01
5
0x7D
6
0x84
Identifica o pacote de status com o mesmo ID do pacote
de requisição de transmissão enviado.
Endereço de 16 bits do XBee de destino (se a
mensagem foi entregue corretamente). Caso contrário
esse endereço é igual ao enviado no pacote de
requisição de transmissão.
7
0x00
Delimitador de Início
Tamanho do Pacote
Endereço de 16 bits
do destino (MY)
PACOTE API
Quantidade de
tentativas de
retransmissão
Status de entrega
(Delivery status)
8
0x00
Obrigatório em todo pacote API
Número de tentativas de retransmissão
0x00 = Success
0x01 = MAC ACK Failure
0x02 = CCA Failure
0x15 = Invalid destination endpoint
0x21 = Network ACK Failure
0x22 = Not Joined to Network
0x23 = Self-addressed
0x24 = Address Not Found
0x25 = Route Not Found
0x26 = Broadcast source failed to hear a neighbor relay
the message
0x2B = Invalid binding table index
0x2C = Resource error lack of free buffers, timers, etc.
41
Status de descoberta
(Discovery status)
9
0x01
Soma de verificação
(Checksum)
10
0x71
0x2D = Attempted broadcast with APS transmission
0x2E = Attempted unicast with APS transmission, but
EE=0
0x32 = Resource error lack of free buffers, timers, etc.
0x74 = Data payload too large
0x75 = Indirect message unrequested
0x00 = No Discovery Overhead
0x01 = Address Discovery
0x02 = Route Discovery
0x03 = Address and Route
0x40 = Extended Timeout Discovery
0xFF – Soma dos bytes a partir do índice 3 até o byte
anterior ao checksum.
2.3.4. Entradas/Saídas Digitais e Analógicas nos Módulos XBee
Os módulos XBee possuem pinos cujo comportamento pode ser configurado
através de software. Este tipo de interface é denominada GPIO (General Purpose
Input/Output). No módulo XBee PRO Series 2, existem 11 pinos configuráveis
através de comandos AT, conforme descrito na Tabela 9. Quatro destes pinos
podem ser configurados como entradas analógicas (pinos 17 a 20) e todos podem
ser configurados como entrada/saída digital.
Tabela 9 - Pinos Configuráveis (GPIO) no Módulo XBee PRO S2 (Adaptado: DIGI, 2011).
Nome do Pino
CD/DIO12
PWM0/RSSIM/DIO10
PWM/DIO11
DIO4
CTS/DIO7
ASSOC/DIO5
RTS/DIO6
AD3/DIO3
AD2/DIO2
AD1/DIO1
AD0/DIO0
Número do Pino
4
6
7
11
12
15
16
17
18
19
20
Comando AT de Configuração
P2
P0
P1
D4
D7
D5
D6
D3
D2
D1
D0
Para configurar um pino, um dos comandos AT apresentados na Tabela 10
deve ser enviado ao módulo XBee com o respectivo parâmetro que determina o seu
comportamento. De forma geral, os parâmetros mais comuns disponíveis para estes
comandos são apresentados na Tabela 10. Alguns pinos possuem funções
alternativas, como o Led associativo que indica se o módulo entrou numa rede ou
indicação da intensidade do sinal (RSSI) por meio de uma saída PWM ou ainda
pinos que permitem o controle de fluxo na serial (CTS e RTS).
42
Tabela 10 – Parâmetros para Comandos AT de Configuração dos Pinos GPIO (Adaptado: DIGI, 2011).
Valor do Parâmetro
Descrição
0
Desabilitado
Reservado para funções específicas de alguns pinos. (Led associativo,
RSSI PWM, etc.)
Conversor analógico digital Single Ended de 10 bits. Disponível somente
para os pinos 17 a 20.
Entrada digital
Saída digital em nível baixo
Saída digital em nível alto
Funções alternativas disponíveis em alguns pinos. (CTS, RTS, etc.)
1
2
3
4
5
6-9
2.3.4.1.
Amostragem de Entradas Analógicas e Digitais
Módulos XBee podem monitorar e adquirir amostras das suas entradas
digitais e analógicas. Se um módulo XBee estiver operando no modo Transparente
(AT), as amostras só podem ser obtidas localmente. Já se o módulo operar no Modo
API as leituras de amostras podem ser realizadas tanto localmente quanto
remotamente. Existem três maneiras de se obter amostras: a) Amostragem por
Requisição; b) Amostragem por Detecção de Mudança; e c) Amostragem Periódica.
Na
amostragem
periódica
o
módulo
XBee
adquire
e
transmite
automaticamente, para o endereço de destino (parâmetros DH e DL), amostras de
todas as suas linhas digitais e analógicas habilitadas. O período entre cada
amostragem é configurado através do comando AT “IR”, que admite valores entre
0x32 e 0xFFFF (50 a 65535) milissegundos. Caso seja configurado como zero, a
amostragem periódica é desabilitada.
Na amostragem por detecção de mudança, os módulos XBee são
configurados para monitorar o estado de suas entradas e saídas digitais. Assim que
detectam alguma mudança de estado enviam uma amostra de todas as entradas e
saídas habilitadas para o endereço de destino (parâmetros DH e DL). A seleção de
cada canal digital a ser monitorado é realizada a partir do comando AT “IC”, que
recebe como parâmetro uma máscara de bits.
Já na amostragem por requisição, técnica utilizada neste trabalho, o módulo
XBee adquire e transmite uma amostra somente quando recebe uma solicitação,
realizada a partir do comando AT “IS”. Este comando pode ser utilizado localmente
ou remotamente. Ao receber uma requisição de comando “IS”, o XBee realiza uma
43
leitura de todos seus canais digitais e analógicos e retorna para o dispositivo
solicitante a amostra com os resultados.
Em qualquer um dos modos de operação ou de amostragem, uma amostra é
um conjunto de bytes organizados, como apresentado na Tabela 11. O primeiro byte
define a quantidade de amostras existentes e é sempre igual a um. Os dois bytes
seguintes representam uma máscara de bit dos canais digitais que informa quais
linhas digitais estão habilitadas. O quarto byte representa a máscara de bit dos
canais analógicos, indicando quais entradas analógicas estão habilitadas. Em
seguida, tem-se uma quantidade de bytes variável, de acordo com a quantidade de
entradas analógicas e digitais habilitadas.
Caso haja algum canal de E/S digital habilitado, os bytes 5 e 6 indicam, bit a
bit, o estados de todos os canais digitais. Caso nenhum canal digital esteja
habilitado estes dois bytes são omitidos. Em seguida, cada entrada analógica
habilitada retornará 2 bytes representando o valor de 10 bits do seu conversor AD.
As amostras são ordenadas começando em AN0 até AN3, seguido da tensão de
alimentação (Supply Voltage), caso habilitada.
Tabela 11 – Organização de Uma Amostra de Canais Analógicos e Digitais de Um Módulo XBee.
(Adaptado: DIGI, 2011).
Quantidade
de Bytes
1
Nome
Descrição
Conjuntos de amostras
2
Máscara de canais digitais
1
Máscara de canais
analógicos
Quantidade de conjuntos de amostras no pacote. Sempre igual a 1.
Indica quais linhas digitais estão habilitadas. Cada bit corresponde
a um pino:
 bit 0 = AD0/DIO0
 bit 1 = AD1/DIO1
 bit 3 = AD3/DIO3
 bit 4 = DIO4
 bit 5 = ASSOC/DIO5
 bit 6 = RTS/DIO6
 bit 7 = CTS/GPIO7
 bit 8 = Não utilizado
 bit 9 = Não utilizado
 bit 10 = RSSI/DIO10
 bit 11 = PWM/DIO11
 bit 12 = CD/DIO12
Exemplo: uma máscara com valor 0x0021 indica que as linhas
digitais DIO 0 e 5 (Pinos 20 e 15, respectivamente) estão
habilitadas
Indica quais pinos estão configurados como entradas analógicas.
Cada bit representa um canal analógico:
44
Variável
Amostras dos canais
digitais e analógicos
habilitados
 bit 0 = AD0/DIO0
 bit 1 = AD1/DIO1
 bit 2 = AD2/DIO2
 bit 3 = AD3/DIO3
 bit 7 = Tensão de Alimentação (Supply Voltage)
Os primeiros 2 bytes indicam o estado de todas os canais digitais
habilitados. Se nenhum canal digital está habilitado, esses bytes
são omitidos.
Em seguida, cada entrada analógica habilitada retornará 2 bytes
representando o valor de 10 bits do seu conversor AD. As amostras
são ordenadas começando em AN0 até AN3, seguido da tensão de
alimentação (Supply Voltage), caso habilitada.
A resposta ao comando “IS” pode ser recebida de duas maneiras: a) Se o
módulo XBee estiver operando no Modo Transparente (AT), cada campo da Tabela
11 é retornado separado por um byte de retorno de carro; e b) Quando operando em
Modo API, ao receber uma requisição de comando “IS” o módulo XBee responde ao
solicitante com um pacote do tipo 0x88 ou 0x97 (Tabela 3 ou Tabela 5) incluindo no
campo “parâmetro do comando” a amostra de todos os seus canais digitais e
analógicos habilitados, conforme detalhado na Tabela 11. Um exemplo de amostra é
apresentado na Tabela 12.
Tabela 12 - Exemplo de Uma Amostra de Canais Analógicos e Digitais (Adaptado: DIGI, 2011).
Exemplo
Descrição
0x01 = 0000 0001b
0x0C0C = 0000 1100 0000 1100b
1 conjunto de amostras
0x03
= 0000 0011b
0x0408 = 0000 0100 0000 1000b
Canais digitais DIO 2,3,10 e 11 habilitados
Canais analógicos A/D 0 e 1 habilitados
Estado das entradas digitais: DIO 3 e 10 em nível alto. DIO 2 e
11 em nível baixo
0x03D0 = 976d
Entrada analógica AD0 = 0x03D0 = 976d
0x0124 = 292d
Entrada analógica AD1 = 0x124 = 292 d
2.3.5. Comparação Entre os Modos de Operação API e Transparente (AT)
As seções anteriores apresentaram, indiretamente, algumas vantagens e
desvantagens entre os modos de operação do XBee. De forma geral, é possível
identificar a relação inversamente proporcional entre o grau de gerenciamento da
rede e a complexidade de uso. Ou seja, o modo de operação API oferece um alto
grau de controle e gerenciamento da rede. No entanto, exige uma manipulação mais
complexa através da formatação de mensagens em pacotes. Já o modo de
45
operação Transparente restringe o uso de algumas funcionalidades, todavia,
apresenta uma interface muito simples.
Dessa forma, é interessante considerar alguns aspectos antes de escolher o
modo de operação a ser utilizado. De forma geral, o uso do modo de operação API é
recomendado quando (DIGI, 2011):

O dispositivo transmite informações para múltiplos destinatários;

Há necessidade de configuração remota dos dispositivos da rede;

Deseja-se realizar aquisição de amostras dos canais analógicos e digitais dos
dispositivos remotos;

São recebidos pacotes de múltiplos destinatários e a aplicação necessita
saber qual dispositivo enviou cada pacote;

A rede utiliza serviços específicos de perfis pré-programados ou necessita dar
suporte a outros recursos (profiles, clusters, endpoints, etc.).
Em qualquer outro caso, o modo de operação Transparente deve ser capaz
de suprir as necessidades do projeto. Na Tabela 13 é apresentada uma comparação
dos dois modos de operação do XBee.
Tabela 13 - Comparação Entre os Modos de Operação API e Transparente (ADAPTADO: DIGI, 2011).
Características do Modo de Operação Transparente (AT)
Interface simples
Todos os dados recebidos pela serial são transmitidos diretamente via RF, exceto
quando o módulo está no modo comando
Facilmente gerenciável
por uma aplicação
A simplicidade na execução de comandos AT e transmissão de dados torna fácil a
construção de uma aplicação de gerenciamento
Características do Modo de Operação API
Facilidade no envio de
dados para múltiplos
destinatários
Pacotes recebidos contém
o endereço do remetente
Configuração remota
Diagnóstico de rede
avançado
A transmissão RF de dados para diferentes destinatários requer apenas que o
endereço de destino seja alterado no pacote API. Este processo é muito mais rápido
do que no modo de operação transparente, já que no último, é necessário enviar um
comando AT para alterar o destinatário e só assim continuar a transmissão de dados
Todos os pacotes API recebidos via RF possuem o endereço do remetente
Comandos AT podem ser executados em dispositivos remotos, o que permite a
leitura e configuração de todos os parâmetros dos XBee, proporcionando um maior
nível de gerenciamento e potencial de aplicação da rede
Permite a descoberta de nós, resolução de endereços e o recebimento de
mensagens de status que indicam o sucesso ou falha na entrega de um pacote API
46
A complexidade da aplicação que dará suporte a uma rede composta por
dispositivos
XBee
operando
no
modo
API
muitas
vezes
desencoraja
o
desenvolvedor que, em alguns casos, prefere utilizar o modo de operação
Transparente o qual oferece uma manipulação mais fácil e imediata. No entanto,
essa opção, em alguns projetos, pode resultar no aumento do custo do projeto e
consumo de energia.
Para ilustrar essa constatação, tome-se como exemplo o trabalho proposto
por YUSSOFF et. al (2012). O autor apresenta uma proposta de um nó sensor sem
fio composto por três componentes: um módulo XBee, um microcontrolador PIC e
um sensor analógico de temperatura. No trabalho o autor utilizou o microcontrolador
apenas para realizar a leitura analógica do sensor, tarefa que poderia ser feita
diretamente pelo módulo XBee, caso o autor utilizasse o modo de operação API.
Dessa forma, o microcontrolador poderia ser eliminado do projeto, o que reduziria
significativamente o custo e o consumo de energia.
2.4. Localização de Nós Móveis em Redes de Sensores Sem Fio
O contínuo aperfeiçoamento das tecnologias de redes de sensores sem fio
tem tornado possível o desenvolvimento de aplicações eficientes destinadas à
estimação da localização ou rastreamento de um nó móvel. Uma ferramenta de
localização muito comum é o GPS (Global Positioning System), que fornece a
localização de um dispositivo através de satélite com uma boa precisão em
ambientes externos. Nas RSSF, a alternativa comumente utilizada é a localização
através da intensidade do sinal recebido na antena (RSSI, Received Strength Signal
Indication). Esta última possui a vantagem de não necessitar de um módulo
adicional de hardware (como é o caso do GPS) e, por isso, foi adotada neste
trabalho.
O processo de localização, de forma geral, pode ser divido em três etapas
(MASIERO, 2007):

Distanciamento (ranging): determinação da distância relativa entre os nós
da rede;

Posicionamento: a partir das distâncias entre os nós, fornece uma estimativa
inicial sobre a localização do nó. Existem vários métodos para fazer esta
tarefa e dependem da aplicação, orçamento disponível e topologia da rede;
47

Refinamento: refina os resultados obtidos nas duas fases anteriores.
2.4.1. Cálculo da Distância Relativa Entre Nós (Ranging)
Os módulos XBee possuem a capacidade de fornecer o valor da potência (em
dBm) do sinal recebido (RSSI) na última transmissão entre dois nós. Portanto, se
adotarmos um modelo de propagação eletromagnética podemos estimar a distância
entre esses nós a partir do valor da potência recebida.
Para este trabalho, considerando que o sistema é destinado à utilização em
campo aberto, foi adotado o modelo de propagação em espaço livre, que fornece a
estimativa da potência do sinal no receptor quando não há obstáculos entre o
emissor e o receptor. Este modelo é descrito matematicamente pela Equação 2,
também conhecida como equação de Friis (RAPPAPORT, 1996):
( )
(
)
Equação 2
Onde PT e Pr representam, respectivamente, as potências no transmissor e
receptor (em Watts); λ é o comprimento de onda (em metros) da frequência de
operação do dispositivo e é igual a 0,125 metros para os módulos de 2.4 GHz
utilizados; d é a distância (em metros) entre o emissor e receptor; L é um número
que representa o fator de perdas do sistema e GT e Gr são os fatores de ganho nas
antenas do transmissor e receptor, respectivamente. Pode-se reescrever a Equação
2 de forma a obter a razão entre a potência do receptor e a do emissor (Equação 3).
(
)
Equação 3
Uma vez que os módulos XBee retornam a razão entre a potência do
transmissor e do receptor em dBm, pode-se reescrever a Equação 3 da seguinte
forma:
48
( )
(
)
((
((
(
)
) )
)
(
)
(
)
)
Equação 4
De forma análoga, para obter a distância entre dois módulos XBee, em função
da potência do sinal (RSSI), basta reorganizar e inverter a
Equação 4:
( )
((
)
)
(
(√
))
(
(
(
)
)
(√
))
(
)
(
)
(√
(√
(
)
(
)
)
)
Equação 5
2.4.2. Estimação da Localização dos Nós
Existem vários métodos para a localização de nós móveis a partir do valor da
intensidade do sinal recebido (RSSI). Neste trabalho, com o intuito de identificar a
melhor técnica, foram utilizados dois algoritmos diferentes: Algoritmo de Lateração e
Algoritmo do Mínimo Máximo, nas versões propostas por MASIERO, 2007. Estes
algoritmos são cientificamente atraentes por apresentarem uma baixa complexidade
e custo de implementação. Estes métodos funcionam baseados na suposição de
que existem nós com coordenadas conhecidas (nós de referência). No entanto,
existem algoritmos para a localização de nós sensores sem a necessidade de uma
49
referência absoluta, como apresentado em MOORE, 2004 (MASIERO, 2007). Outras
técnicas de localização podem ser consultadas em PATWARI, 2005.
2.4.2.1.
Lateração
Considerando que os dados de distâncias relativas entre os nós de referência
(pelo menos três) e o nó móvel foram obtidos na etapa anterior (Equação 5), a
técnica de lateração consiste, basicamente, nos seguintes passos (MASIERO,
2007):
a. Desenham-se círculos centrados nos nós de referência com raio igual à
distância obtida entre o nó de referência e o nó móvel;
b. Calculam-se as intersecções entre todos os círculos (dois pontos para
cada par de círculos);
c. Define-se qual das duas coordenadas obtidas no passo “b” é verdadeira;
d. O nó móvel está localizado, idealmente, na intersecção entre todos os
círculos.
A Figura 17 ilustra a técnica descrita acima.
Figura 17 – Algoritmo de Lateração Para Localização de Nós Móveis
Uma das desvantagens deste algoritmo é a sensibilidade a incertezas, uma
vez que um erro no valor das intensidades dos sinais pode incorrer na ausência de
intersecção entre os círculos e, consequentemente, o algoritmo não fornecerá a
50
saída desejada. Outro detalhe importante neste algoritmo é a necessidade de decidir
qual ponto de intersecção é verdadeiro, uma vez que a intersecção entre um par de
círculos fornece dois pontos, no entanto, só um dos dois é a coordenada verdadeira.
Esta decisão é realizada no passo “c” através da técnica denominada
“descoberta do caminho mínimo”. Esta técnica consiste na construção de dois
conjuntos um para cada um dos dois pontos de intersecção. Cada conjunto possuirá
as distâncias entre uma das duas coordenadas de intersecção e todas as outras
coordenadas estimadas. Observe que a coordenada verdadeira gerará um conjunto
que possui um somatório dos seus elementos menor do que o outro conjunto. Assim
é possível decidir qual ponto de intersecção é verdadeiro.
2.4.2.2.
Algoritmo do Mínimo Máximo
Assim como na técnica anterior, são estimadas as distâncias entre os nós de
referência e o nó móvel através da potência do sinal recebido (RSSI). No entanto, ao
invés de círculos são desenhados quadrados centrados nos nós de referência, com
lado igual a duas vezes a distância estimada entre o nó móvel e os nós de
referência. O nó móvel é então localizado na região retangular, que representa a
intersecção de todos os quadrados. O algoritmo retorna o centroide do retângulo. A
Figura 18 ilustra o funcionamento do algoritmo.
Figura 18 - Algoritmo do Mínimo Máximo Para a Localização de Nós Móveis
51
As principais vantagens deste algoritmo em relação ao anterior são a sua
simplicidade e robustez na presença de ruído. No entanto, mesmo para canais com
pouco ruído, o algoritmo introduz uma incerteza inerente ao seu método de
estimação.
2.4.3. Refinamento
Existem vários métodos de refinamento utilizados para aumentar a precisão
dos algoritmos apresentados na seção anterior. Alguns exemplos incluem a
utilização de Filtros de Kalman, suavização e outras técnicas (que podem ser
consultadas em PATWARI, 2005, MASIERO, 2007 e LOU et. al, 2008). Neste
trabalho não foi utilizada nenhuma técnica de refinamento, já que a precisão na
localização não é o principal objetivo do projeto.
2.5. Caprinocultura no Brasil
Dentre os animais que compõem os a classe dos pequenos ruminantes, na
região Nordeste, destacam-se os caprinos e ovinos. Os caprinos são animais
conhecidos por apresentarem um fácil manejo, boa adaptabilidade climática e pouca
exigência, qualitativamente e quantitativamente, em termos alimentares (CANIELLO,
2012). Os principais produtos derivados dos caprinos são o leite de cabra, a carne e
a pele do animal. A carne caprina, além de saborosa, é caracterizada por apresentar
menor proporção de gordura saturada e calorias, mas, com a mesma quantidade de
ferro e proteínas, quando comparada à carne bovina (MALAN, 2000).
O Brasil possui atualmente o 17º maior rebanho de caprinos, com pouco mais
de nove milhões de cabeças, o que equivale a cerca de 1% da produção mundial.
Em primeiro lugar está a Índia com 16,71% da produção (Tabela 14). Para
CANIELLO, 2012, há uma margem grande de crescimento da caprinocultura no
Brasil, considerando as dimensões territoriais do país e as condições favoráveis
para a criação.
52
5
Tabela 14 - Ranking dos Maiores Criadores de Caprinos do Mundo. (Fonte: FAO , dados de 2010).
Posição
País
Rebanho (Cabeças)
Percentagem do
rebanho mundial
1º
Índia
154.000.000,00
16,71%
2º
China
150.706.554,00
16,36%
3º
Bangladesh
65.000.000,00
7,05%
4º
Paquistão
59.900.000,00
6,50%
5º
Nigéria
56.524.100,00
6,13%
6º
Sudão
43.441.000,00
4,71%
7º
Irã
25.700.000,00
2,79%
8º
Etiópia
21.960.700,00
2,38%
9º
Indonésia
16.821.000,00
1,83%
10º
Mali
16.522.500,00
1,79%
11º
Mongólia
13.883.200,00
1,51%
12º
Níger
13.673.100,00
1,48%
13º
Quênia
13.291.700,00
1,44%
14º
Tanzânia
12.900.000,00
1,40%
15º
Somália
12.700.000,00
1,38%
16º
Burkina Faso
12.377.500,00
1,34%
17º
Brasil
9.312.780,00
1,01%
Segundo dados do IBGE, na última pesquisa de Produção Pecuária Municipal
(PPM) em 2010 o nordeste brasileiro continuou líder absoluto na criação de
caprinos, com 90,8% do rebanho nacional equivalente a cerca de 8,5 milhões de
cabeças. Em segundo lugar, com apenas 3,7% da produção nacional, encontra-se a
região sul. O gráfico da Figura 19 ilustra a participação percentual de cada região do
brasil.
2,5%
3,7%
1,8% 1,2%
90,8%
Nordeste
Sudeste
Sul
Norte
Centro-Oeste
Figura 19 – Gráfico de Participação Percentual das Regiões Brasileiras no Rebanho Nacional
5
http://faostat.fao.org/
53
Além de ser uma atividade que promete avançar significativamente nos
próximos anos, a escolha da caprinocultura no desenvolvimento deste trabalho se
deve, principalmente, à localização da Universidade Federal do Vale do São
Francisco (UNIVASF). Mais especificamente, a UNIVASF possui campus em três
estados do Nordeste: Bahia, Pernambuco e Piauí. Juntos, esses estados
representam 64,1% da produção nacional de caprinos (Figura 20). Logo, a demanda
por pesquisa e desenvolvimento voltados para a otimização da produção e bemestar animal é alta.
11,0%
6,4%
30,6%
14,9%
18,6%
Bahia
Pernambuco
Piauí
Ceará
Paraíba
Figura 20 – Gráfico de Participação Percentual dos Cinco Maiores Produtores de Caprinos no Brasil
2.6. Bem-estar Animal, Bioclimatologia e Zootecnia de Precisão
O bem-estar animal é um assunto que vem ganhando cada vez mais
destaque nas discussões sobre produção animal atualmente. No entanto, o conceito
de bem-estar ainda não possui um consenso entre os pesquisadores, uma vez que
existem várias linhas de pensamento. Fraser et al, 1997, por exemplo, realiza uma
ampla análise de várias definições sobre bem-estar e apresenta uma visão sobre a
identificação de questões éticas na qualidade de vida dos animais.
Com o objetivo de tentar generalizar o conceito de bem-estar animal o Farm
Animal Welfare Council (FAWC) propôs as “cinco liberdades” dos animais que
definem estados ideais de bem-estar, ao invés de padrões aceitáveis, formando um
conjunto de ferramentas lógico e compreensível para análise do bem-estar animal
em qualquer sistema (FAWC, 2012):
1) Liberdade contra a fome e sede;
2) Liberdade contra o desconforto;
54
3) Liberdade contra dor, doença e lesões;
4) Liberdade para expressar seus comportamentos normais;
5) Liberdade contra o medo e estresse.
Alguns autores classificam a temperatura do ambiente, umidade do ar e
radiação solar como as principais variáveis que influenciam o conforto térmico e a
produção animal. (Lee et al., 1974; SOUZA et al., 2008; COELHO, 2011; SILVA et.
al, 2012;). Neste contexto insere-se a bioclimatologia animal que pode ser definida,
resumidamente, como a ciência que estuda as interações entre o clima e os animais
com o objetivo de proporcionar o bem-estar animal e, consequentemente, a
maximização da produção.
No entanto, para que a bioclimatologia possa analisar o bem-estar dos
animais é necessário dispor de dados precisos sobre as variáveis meteorológicas
presentes
no
ambiente,
bem
como
sobre
as
respostas
fisiológicas
e
comportamentais fornecidas pelos animais (COELHO, 2011; SILVA et. al, 2012).
Neste âmbito insere-se a zootecnia de precisão, que busca através de diversas
tecnologias
medir
variáveis
meteorológicas,
indicadores
fisiológicos,
comportamentais e de produção dos animais, de maneira individualizada
(POLYCARPO, 2012).
Dessa forma podemos classificar o trabalho ora proposto como uma
ferramenta em potencial da zootecnia de precisão podendo auxiliar futuras iniciativas
de pesquisa e desenvolvimento nesta área. Isso se deve à possibilidade de adquirir
dados sobre variáveis meteorológicas (temperatura e umidade), bem como dados
sobre respostas fisiológicas fornecidas pela frequência cardíaca e comportamento
dos animais (rastreamento da trajetória) através da rede de sensores sem fio.
2.6.1. Influência de Variáveis Meteorológicas na Produção de Caprinos
No Nordeste brasileiro a temperatura ambiente atinge valores elevados
durante quase todo o ano. Essa característica pode influenciar o desempenho
produtivo e reprodutivo dos animais. Segundo NÓBREGA et al. 2011, para atingir a
maximização da produção animal é necessário conhecer a capacidade de
adaptação das raças de animais exploradas, bem como suas interações com o
ambiente, sob a forma de respostas fisiológicas diárias ou sazonais. Dessa forma, é
55
possível tomar decisões quanto aos sistemas de criações, estratégias de manejo e
ajustes que proporcionem um maior conforto aos animais.
Os animais, de modo geral, possuem a capacidade de manter a temperatura
corporal constante, apesar das variações da temperatura ambiente. Esta
característica é denominada homeotermia (JHONSON, 1987). No entanto, quanto
maior a diferença entre a temperatura corporal do animal e a temperatura ambiente,
mais energia será gasta pelo animal na tentativa de manter a sua temperatura
constante. Segundo Baêta e Souza, 1997, existe uma faixa de temperatura na qual
gasto de energia do animal para manter o equilíbrio térmico é mínimo. Essa faixa de
temperatura é denominada zona de conforto térmico.
NÓBREGA et al. 2011, elenca algumas variáveis como parâmetros
importantes para a análise do bem-estar animal: temperatura ambiente, temperatura
superficial do animal, frequência respiratória, frequência cardíaca, radiação solar,
temperatura retal, etc.
SOUZA et al. 2005, avaliaram as respostas fisiológicas de caprinos de
diferentes raças na região do semiárido nordestino em relação às variações de
temperatura ambiente. Seus resultados demonstram, principalmente, alterações na
frequência respiratória dos animais como mecanismo de regulação da temperatura
corporal. Já Kaushish et al. (1987) verificou alterações na frequência cardíaca de
caprinos.
Assim,
percebe-se
que
os
animais
utilizaram
mecanismos
de
termorregulação para manter a temperatura constante, o que pode culminar num
estresse calórico e, consequentemente, na diminuição da produção (NÓBREGA et
al. 2011).
Alguns trabalhos, como o proposto por SOUZA et al. 2005, utilizaram como
metodologia para a medição da frequência cardíaca e respiratória dos animais, a
auscultação. Embora seja um método comumente utilizado, essa técnica oferece
pouca eficiência e certa imprecisão, uma vez que é necessária a medição e
contagem da frequência de forma manual. Dessa forma, acredita-se que novas
tecnologias, como o uso de sensores eletrônicos associado a uma rede de sensores
sem fio semelhante ao proposto neste trabalho, poderão no futuro proporcionar um
aumento na eficiência e confiabilidade dos resultados deste tipo de análise.
56
57
3.
Materiais e Métodos
O sistema proposto neste trabalho reúne várias de áreas de estudo e
ferramentas, como banco de dados, eletrônica, sistemas embarcados, engenharia
de software e redes. Assim, para facilitar o desenvolvimento, dividiu-se o projeto em
duas partes: hardware e software.
3.1. Software
O software da aplicação pode ser entendido como um conjunto de
ferramentas e subprogramas que interagem com o objetivo de gerenciar a RSSF e
armazenar os dados recebidos dos nós sensores. Para tanto, inclui um banco de
dados e subprogramas responsáveis pelo gerenciamento dos pacotes da rede,
interface gráfica, comunicação serial (RS232) e processamento de dados. A Figura
21 apresenta uma visão geral do software desenvolvido.
Figura 21 - Visão Geral do Software em Desenvolvimento
58
3.1.1. Interface Gráfica do Software
Devida a sua portabilidade, grande utilização e suporte a orientação a objetos,
a linguagem de programação escolhida para o desenvolvimento do software foi o
JAVA. A interface gráfica é baseada na biblioteca Swing e construída com o auxílio
da ferramenta de desenvolvimento NetBeans IDE 7.1. O principal objetivo da
interface gráfica é auxiliar o usuário na análise e visualização dos dados fornecidos
pelos sensores, bem como na visualização da localização dos animais.
3.1.2. Camada de Processamento de Dados
Esta camada de software é responsável por intermediar a troca de dados
entre a camada de gerenciamento de pacotes de rede, a interface gráfica e o banco
de dados. Na medida em que os pacotes de rede com os dados dos sensores
chegam ao computador, esta camada os interpreta e os armazena no banco de
dados, além de exibi-los na aba de monitoramento.
3.1.2.1.
Banco de Dados
Para armazenar os dados foi utilizado o Sistema Gerenciador de Banco de
Dados (SGBD) SQLite6, por ser uma ferramenta de código aberto, fácil manipulação,
autocontida e dispensar a utilização de um servidor de banco de dados. A interface
entre a aplicação e o banco de dados na linguagem JAVA foi realizada utilizando o
driver SQLite JDBC7.
O banco de dados foi modelado utilizando um Diagrama Entidade
Relacionamento (DER). As informações relevantes a serem armazenadas em disco
podem ser resumidas em apenas duas entidades: Estação e Amostra. As estações
representam cada nó móvel (animal) da rede e possuem um endereço único e um
nome. Já as amostras, possuem a data e hora em que foram recebidas, localização
do nó que as enviou e os valores instantâneos dos sensores de frequência cardíaca
(FC), temperatura do ar (TA) e umidade relativa (UR). A Figura 22 apresenta o DER
que representa o banco de dados do sistema.
6
7
www.sqlite.org
www.zentus.com/sqlitejdbc/
59
Figura 22 - Diagrama Entidade Relacionamento
3.1.3. Montagem e Gerenciamento de Pacotes de Rede API XBee
O modo de operação escolhido para os módulos XBee utilizados na rede foi o
modo API, uma vez que é necessário o envio de mensagens para destinos
diferentes e a execução de comandos AT remotos (seção 2.3.5). Dessa forma, foi
desenvolvida uma camada de software responsável pela montagem e desmontagem
dos pacotes API da rede que entram e saem do nó coordenador.
O principal objetivo dessa camada do software é facilitar o gerenciamento da
rede através de mecanismos automatizados de construção de pacotes API. Essa
camada também é responsável por enfileirar pacotes recebidos e verificar erros de
comunicação.
3.1.4. Comunicação Serial
A troca de pacotes API entre o nó coordenador da rede e o computador é
realizada através da interface serial RS232. Para tanto, foi desenvolvida uma classe
JAVA baseada na API RXTX8 para obter acesso ao hardware e realizar o envio e
recebimento de bytes.
Basicamente, a classe implementa duas threads, uma para envio de dados e
outra para recepção. Um evento aciona a thread de recepção de dados sempre que
um byte chega ao computador. Essa thread identifica o tamanho do pacote sendo
recebido e realiza a leitura dos demais bytes até o fim do pacote. Ao final, o pacote é
encaminhado para a camada de gerenciamento de pacotes que interpretará as
informações contidas no mesmo. Já a thread de envio é responsável por controlar e
8
http://rxtx.qbang.org/
60
enfileirar as informações a serem transmitidas. Assim que o buffer de transmissão
está liberado para envio de dados, um evento aciona a thread para que os dados
pendentes sejam transmitidos.
3.2. Hardware
O hardware do sistema consistiu no projeto e desenvolvimento de circuitos
eletrônicos para os diferentes tipos de estações da rede, bem como na codificação
do firmware utilizado nas estações móveis para a leitura de sensores e localização
do nó. Os nós (ou estações) da rede no sistema proposto podem ser classificados
em três tipos: Estação Coordenadora (EC), Estações de Referência (ER) e Estações
Móveis (EM).
Em todas as estações da rede são utilizados módulos transceptores XBee
PRO Series 2. Nas estações de referência e na estação coordenadora é utilizado o
modelo com antena externa (Figura 9b). Já nas estações móveis, acopladas aos
animais, optou-se por utilizar o modelo com antena Whip (Figura 9a) por não ocupar
um grande espaço físico, reduzindo assim o desconforto aos animais.
3.2.1. Características dos Módulos XBee PRO Series 2
A potência de transmissão deste módulo XBee é de até +17 dBm e a
sensibilidade do receptor é -102 dBm. Segundo o fabricante, o alcance deste
dispositivo pode chegar a 3,2Km. No entanto, esse número pode variar de acordo
com o modelo de antena utilizado e condições ambientais. A Tabela 15 apresenta as
principais características do dispositivo.
Tabela 15 - Características do Módulo XBee PRO Series 2 da Digi
Alcance (Campo aberto)
3,2 Km
Alcance (Ambientes internos)
90 m
Potência de transmissão
+17 dBm (50mW)
Sensibilidade do receptor
-102 dBm
Frequência de operação
ISM 2.4 GHz
Taxa de transmissão
250 Kbps
Tipo de modulação
O-QPSK com DSSS
61
Tensão de Alimentação
3,3 V
GPIO:
11
Conversores AD (10 bits)
Até 4 (VREF máximo 1,2 V)
Entradas e Saídas Digitais
Até 11
Basicamente, para o funcionamento deste módulo XBee, é necessária a
conexão de quatro pinos: VCC, GND, DOUT e DIN. Os dois últimos são
responsáveis pela saída e entrada de dados através da UART, respectivamente. Os
demais pinos, em geral, possuem mais de uma função e o seu comportamento pode
ser determinado através de software. A Figura 23 apresenta o diagrama de pinos do
módulo XBee.
Figura 23 - Diagrama de Pinos do Módulo XBee Pro Series 2
3.2.2. Estação Coordenadora (EC)
A estação coordenadora é responsável por receber os dados da localização e
leitura dos sensores da rede e repassá-los à aplicação (software), que armazenará e
processará os dados. Para tanto, a estação coordenadora é conectada ao
computador por meio de um adaptador USB/RS232 para módulos XBee, fabricado
pela Rogercom9 (Figura 24).
9
http://rogercom.com.br/
62
Figura 24 - Estação Coordenadora da Rede
3.2.3. Estações de Referência (ER)
Com coordenadas geográficas conhecidas, as estações de referência são
responsáveis por trocar mensagens com as estações móveis para auxiliar a
determinação da intensidade do sinal (RSSI) e, consequentemente, a distância entre
as estações móveis e as estações de referência. Neste trabalho, são utilizadas
quatro estações de referência, posicionadas ao redor da área de pastagem dos
animais.
Como as estações de referência são utilizadas apenas para trocar
mensagens com as estações móveis, o circuito eletrônico necessário para o
funcionamento é composto essencialmente por um circuito integrado regulador de
tensão 3.3V (LM1117) e o módulo XBee PRO Series 2. Capacitores são utilizados
para reduzir a interferência de variações de tensão no circuito. Um diodo emissor de
luz (LED) é utilizado para indicar o status de associação do módulo à rede.
Na Figura 25 é apresentado o esquemático do circuito eletrônico de uma
estação de referência. O circuito regulador de tensão utilizado nas estações de
referência é o mesmo utilizado nas estações móveis.
63
Figura 25 - Esquemático do Circuito de uma Estação de Referência
3.2.4. Estações Móveis (EM)
As estações móveis, acopladas aos animais, constituem o hardware mais
importante do projeto e são compostas, basicamente, pelos seguintes componentes:
Módulo transceptor XBee, Sensor de Umidade Relativa, Sensor de Temperatura do
Ar, Sensor de Frequência Cardíaca, Microcontrolador, Bateria Recarregável e
Circuito Regulador de Tensão. A maneira como esses componentes interagem é
apresentada no diagrama de blocos da Figura 26. O esquema elétrico do circuito de
uma estações móvel é apresentado na Figura 27.
Figura 26 - Diagrama de Blocos de Uma Estação Móvel
64
Figura 27 - Esquemático do Circuito da Estação Móvel
Com o objetivo de minimizar o consumo de energia, foram utilizados
componentes eletrônicos de baixa potência. Mais especificamente, procurou-se
manter o mesmo padrão de tensão de alimentação utilizado nos módulos XBee (3,3
Volts), de forma a obter compatibilidade direta entre os níveis de tensão dos
sensores, microcontrolador e XBee utilizados. As seções a seguir descrevem as
principais características dos materiais utilizados.
3.2.4.1.
Sensor de Umidade Relativa Honeywell HIH-5031
A umidade relativa do ar é medida localmente, no ambiente em torno do
animal. Para tanto, cada estação móvel utiliza um sensor Honeywell HIH-5031
(Figura 28a), que pode ser alimentado por uma tensão de 3,3V, possui uma precisão
de ±3 %RH e um tempo de resposta típico de 5 segundos.
O sensor Honeywell HIH-5031 fornece uma saída praticamente linear,
conforme pode ser observado na Figura 28b. O sensor também possui um filtro
hidrofóbico de fábrica e é construído em multicamadas, o que o torna resistente à
condensação, sujeira, óleos e substâncias químicas presentes no ambiente.
65
Figura 28 - a) Sensor de umidade Honeywell HIH-5031. b) Curva Tensão (Vdc) X Umidade Relativa (%UR) a
25°C e Tensão de Alimentação 3,3V Vdc.
A Equação 6 e a Equação 7 apresentam a relação entre a tensão de saída
(Vout, em Volts) fornecida pelo sensor, a umidade relativa (UR Sensor, em %UR) e a
tensão de alimentação do sensor (Vs, em Volts). Já a Equação 8 pode ser utilizada
para compensar o efeito da temperatura do ambiente (T, em °C) na leitura da
umidade relativa.
( )(
(
(
(
)
)
(
3.2.4.2.
)
)(
)
)
Equação 6
Equação 7
Equação 8
Sensor de Temperatura
Para medir a temperatura ambiente em torno do animal utiliza-se um sensor
de temperatura AD22103, fabricado pela Analog Devices. Este sensor é um circuito
integrado monolítico que engloba um circuito de condicionamento de sinal. É capaz
de medir temperaturas na faixa de 0°C a +100°C, fornece uma saída praticamente
linear com uma resolução de 28mV/°C (quando alimentado com 3,3V) e possui um
erro máximo de 2,5°C (tipicamente 0,5°C). Este sensor está disponível em duas
versões de encapsulamento TO-92 e SOIC. A Figura 29 apresenta imagens dos
encapsulamentos e os diagramas de pinos do sensor.
66
Figura 29 – Encapsulamento: a) TO-92 e b) SOIC; Diagrama de pinos: c) TO-92 e d) SOIC.
A função de transferência deste sensor é apresentada na Equação 9, em que
Vout é a tensão de saída (em Volts), Vs é a tensão de alimentação do sensor (em
Volts) e T é a temperatura ambiente (em °C). Para obter o valor da temperatura a
partir da tensão, basta isolar o termo T na Equação 9, como apresentado na
Equação 10.
(
)(
(
3.2.4.3.
(
) )
)
Equação 9
Equação 10
Sensor de Frequência Cardíaca
Para medir a frequência cardíaca dos animais, foi utilizado um conjunto
sensor da fabricante Polar composto por uma faixa transmissora modelo T34 não
codificada (Figura 30b) e uma placa receptora RE07S (Figura 30a).
Figura 30 - a) Placa Receptora de Frequência Cardíaca Polar RE07 e b) Faixa Transmissora T34
67
A faixa (ou cinta) transmissora envia dados sobre a frequência cardíaca, para
a placa receptora que, por sua vez, fornece na saída pulsos com duração de 15ms a
cada batimento cardíaco. Dessa forma, para determinar a frequência cardíaca, basta
calcular o tempo médio entre os pulsos e converter esse valor para batimentos por
minuto (bpm). A placa receptora pode ser alimentada por uma tensão de 3V a 5,5V.
3.2.4.4.
Microcontrolador PIC 18LF4620
O microcontrolador utilizado nas estações móveis é o modelo PIC 18LF4620,
da Microchip. Os microcontroladores PIC com o código “LF” na sua descrição
possuem como principal característica uma faixa mais ampla de tensão elétrica de
alimentação. Por exemplo, o modelo PIC 18F4620 pode ser alimentado com uma
tensão de 4,2V e 5,5V, já o 18LF4620 estende a faixa para 2,0V a 5,5V. Este
modelo também oferece interface de comunicação RS232, entradas analógicas e
interrupções externas. Assim, consegue suprir as necessidades do projeto. A Figura
31 apresenta uma imagem real do dispositivo e seu diagrama de pinos. A Tabela 16
apresenta as principais características do dispositivo.
Figura 31 – Imagem Real e Diagrama de Pinos do PIC18LF4620.
Tabela 16 - Principais Características do Microcontrolador PIC18LF4620
Tensão de alimentação
2,0V a 5,5V
Memória de programa
64K (32K words)
Memória de dados SRAM
3968 bytes
Memória não volátil EEPROM
1024 bytes
Entradas/Saídas
36
68
Entradas analógicas (Canais A/D 10 bits)
13
CCP - Capture/Compare/PWM
1
ECCP - Enhanced Capture/Compare/PWM
1
MSSP
SPI e Master I2C
EUSART (RS232, RS485 e LIN/J2602)
1
Timers 8 bits
1
Timers 16 bits
3
O microcontrolador pode ser considerado o “cérebro” da estação móvel. Ele é
responsável por realizar duas tarefas: 1) cálculo da localização do nó móvel; 2)
leitura dos sensores de temperatura do ar, umidade relativa e frequência cardíaca.
Para calcular a localização do nó móvel, o firmware embarcado no
microcontrolador transmite pacotes para as estações de referência por intermédio do
módulo XBee. Essa troca de pacotes permite a determinação das intensidades do
sinal (RSSI) entre o nó móvel e as estações de referência. Uma vez que as
distâncias entre a estação móvel e as quatro estações de referência são
determinadas, a localização é calculada utilizando as técnicas apresentadas na
seção 2.4.2.
A leitura dos sensores de umidade e temperatura é realizada diretamente
pelas entradas analógicas do microcontrolador, pois os sensores fornecem uma
saída sob a forma de tensão elétrica numa faixa de 0 a 3,3 Volts.
Já o cálculo da frequência cardíaca do animal é realizado por intermédio da
rotina de interrupção externa no pino RB0. Na medida em que um pulso é detectado
na entrada do pino RB0 do microcontrolador, a rotina de interrupção externa dispara
o Timer0 do microcontrolador que inicia a contagem do tempo. Quando um segundo
pulso é detectado, a rotina de interrupção externa interrompe a contagem no Timer0
e calcula o tempo em milissegundos entre os dois pulsos, de acordo com o valor
atual armazenado no registrador do Timer.
Após o cálculo da localização e o processamento da leitura dos sensores, um
pacote com os dados obtidos é transmitido para o nó coordenador da rede e,
finalmente, armazenado no banco de dados do software.
69
4.
Resultados
O processo de desenvolvimento do Software e Hardware de projeto foi
realizado no Laboratório de Hardware da Universidade Federal do Vale do São
Francisco. Como resultados, podemos destacar a placa de circuito impresso
desenvolvida para as estações móveis e o software desenvolvido em linguagem
JAVA para armazenamento e consulta de dados.
4.1. Hardware
O hardware do sistema foi desenvolvido em três etapas. Na primeira, o
firmware do microcontrolador das estações móveis foi simulado utilizando a
ferramenta Proteus ISIS 7.8 SP2.
Na segunda etapa, os componentes de hardware foram montados em uma
placa de protótipos (protoboard), com o objetivo de identificar possíveis falhas e
realizar testes com os sensores em um ambiente real.
Na terceira etapa foi construída uma placa de circuito impresso para a
estação móvel contendo todos os sensores e demais componentes de hardware
necessários. A placa foi desenhada utilizando o software Proteus Ares 7.8 SP2.
Após o projeto do circuito no computador, o desenho foi impresso em papel tipo
couché e transferido para uma placa de fenolite por meio do método de transferência
térmica, utilizando um ferro de passar roupas comum.
As falhas provenientes da transferência térmica foram corrigidas com o auxílio
de um caneta para retroprojetor. Em seguida a placa de fenolite foi levada à
corrosão em uma solução de percloreto de ferro. Imagens do processo de
desenvolvimento e a placa finalizada são apresentadas na Figura 32.
Foi possível obter uma placa com dimensões relativamente pequenas (7cm X
8cm). No entanto, essas dimensões podem ser ainda menores, caso sejam
utilizados componentes do tipo SMD e o processo de desenvolvimento seja
realizado com o auxílio de máquinas que proporcionem a fabricação de placas de
várias faces.
O conjunto sensor polar (cinta transmissora + placa receptora) permitiu a
medição adequada da frequência cardíaca, no entanto, a cinta transmissora utilizada
(T34) possui uma bateria que não pode ser substituída pelo usuário, apenas em
70
filiais autorizadas da Polar. Dessa forma, em versões futuras pretende-se utilizar um
modelo de cinta que proporcione uma substituição fácil das baterias.
O hardware apresentou um consumo máximo de 0,165W. Ou seja, o
consumo de corrente é de máximo de 50mA, quando o circuito está transmitindo. Se
considerarmos um conjunto de baterias de 2000mAh, o hardware possuiria uma
autonomia de, no mínimo, 40 horas. Nesta versão não foi implementada nenhum
mecanismo de economia de energia, dessa forma, em futuras versões, a autonomia
do sistema pode se tornar muito superior.
Figura 32 - Desenvolvimento da Placa de Circuito Impresso Para a Estação Móvel
4.1. Software
A interface do software, basicamente, é composta por duas abas: 1) banco de
dados e 2) amostragem. Na aba “banco de dados” (Figura 33), o usuário pode
selecionar os dados dos sensores de acordo com a data e hora de amostragem. O
usuário também pode exportar os dados selecionados para um arquivo do tipo “.csv”
(útil para ser importado em softwares de planilha eletrônica, como o Microsoft Excel).
A aba “amostragem” (Figura 34) permite que o usuário configure o tempo de
amostragem e inicie ou interrompa a leitura dos sensores instalados nos animais.
71
Também é possível visualizar, em tempo real, os valores dos sensores lidos e a
localização dos animais. O painel lateral esquerdo é responsável por exibir
informações sobre os nós sensores que estão conectados à rede (endereço, nome,
etc). No menu superior o usuário pode acessar as opções de configuração da
comunicação serial RS232, como baud rate e porta de comunicação utilizada. O
quadro branco no canto inferior direito ilustra a localização do animal.
Figura 33 - Tela do Software. Aba Banco de Dados.
Figura 34 - Tela do Software. Aba Amostragem.
72
4.2. Experimentos em Animais
Para verificar o funcionamento do projeto desenvolvido, o sistema foi levado a
campo e instalado em um carneiro da raça Dorper (Figura 35). Com o objetivo de
proteger o hardware contra possíveis danos físicos, a placa de circuito impresso foi
encapsulada em uma caixa de plástico (Figura 35c) e fixada no pescoço do animal
com o auxílio de um colar de diâmetro ajustável (Figura 35d).
Infelizmente não foi possível testar os algoritmos de localização dos animais,
uma vez que seriam necessárias várias unidades de módulos transceptores XBee
(pelo menos 5). No entanto, até o momento da conclusão deste texto só
dispúnhamos de duas unidades. Este problema, no entanto, não impossibilitou o
teste do subsistema de monitoramento dos animais, ou seja, da leitura dos sensores
de umidade, temperatura e frequência cardíaca.
Inicialmente o sistema apresentou dificuldades na medição da frequência
cardíaca do animal. Isso é atribuído a grande quantidade de pelos que o animal
escolhido possuía, o que impossibilitava que os eletrodos da cinta transmissora
ficassem encostados na pele do animal. Dessa forma, decidiu-se substituir o animal
por outro com uma menor quantidade de pelos. Após a substituição o sistema
conseguiu medir a frequência cardíaca de forma adequada. Assim, para um
funcionamento correto do sistema é necessário que a área em que a cinta
transmissora for instalada possua pouca pelagem ou esteja raspada.
Também foi constatado que uma coleira do tipo peitoral é mais adequada
para suportar o peso do circuito instalado no animal. Durante os testes, o colar com
a placa de circuito impresso oscilava em torno do pescoço do carneiro, o que pode
causar um incômodo desnecessário ao animal e oferecer mais risco de danos físicos
ao hardware. Outro fator importante é a massa do equipamento. Nos testes
realizados, a bateria de 9V recarregável utilizada foi responsável por cerca 40% da
massa do equipamento (aproximadamente 150 gramas). Dessa forma, é
interessante buscar baterias alternativas que permitam reduzir a massa total do
equipamento.
73
Figura 35 - Experimentação em Animais. a) Animal equipado com o sistema; b) Circuito alimentado por
uma bateria de 9 volts; c) Hardware encapsulado em uma caixa de plástico; d) Colar para fixar o
equipamento no animal; e) Computador com a estação coordenadora e software em funcionamento; e f)
Animal utilizado no experimento e autor do projeto.
Levando-se em conta que variáveis meteorológicas, como a temperatura do
ar e umidade relativa, afetam o conforto térmico e, consequentemente, a produção e
reprodução animal, acredita-se que os dados medidos pelos sensores, juntamente
74
com os dados de localização dos animais, poderão auxiliar de forma significativa as
seguintes atividades:

Estudo do efeito da umidade relativa e temperatura ambiente na qualidade de
vida e produção dos animais;

Análise de hábitos de pastejo e alterações de comportamento dos animais
através do rastreamento da sua localização;

Análise e projeto de novos algoritmos para a localização por RSSI;

Desenvolvimento de algoritmos para detecção automática de alterações
comportamentais e fisiológicas dos animais.
É interessante ressaltar que o uso deste tipo de tecnologia para o
monitoramento de animais ainda é relativamente nova, o que proporciona um grande
potencial de inovação, crescimento e avanço nesta área de estudo.
75
5.
Conclusões
As Redes de Sensores Sem Fio constituem uma tecnologia que tem ampliado
significativamente as perspectivas científicas e industriais para os próximos anos. A
capacidade de monitorar e controlar o ambiente, aliada a um baixo consumo de
energia, permite a aplicação da tecnologia em diversos setores da sociedade. No
entanto, a utilização das RSSFs ainda é tímida, principalmente no setor
agropecuário.
Neste trabalho foi proposto e desenvolvido um sistema composto por
hardware e software capaz de monitorar e localizar caprinos utilizando uma Rede de
Sensores sem Fio baseada no protocolo ZigBee 802.15.4. Cada animal é equipado
com um nó sensor responsável por estimar a sua localização, através de métodos
baseados na intensidade do sinal recebido (RSSI), e medir a temperatura ambiente,
umidade relativa e frequência cardíaca do animal.
De forma geral, acredita-se que o projeto desenvolvido atingiu os objetivos
pretendidos. A rede de sensores sem fio baseada no protocolo ZigBee/802.15.4 foi
montada e permitiu a aquisição à distância de dados dos sensores instalados nos
animais. Algoritmos de localização foram estudados e codificados no firmware do
microcontrolador utilizado nas estações móveis, no entanto não foi possível testar
em campo a precisão e eficácia dos algoritmos uma vez que não dispúnhamos, até
o momento da conclusão deste texto, de materiais em quantidade suficiente.
Também foi construída uma placa de circuito impresso para a estação móvel
composta, basicamente, por sensores, transceptor de rádio e microcontrador. Para
processar e armazenar os dados obtidos pela RSSF foi desenvolvido um software
que permite, através de uma interface gráfica, a visualização em tempo real dos
dados recebidos, bem como a consulta dos dados armazenados no banco de dados.
5.1. Trabalhos Futuros
Em trabalhos futuros pretende-se realizar testes de campo mais robustos
com o objetivo de validar o sistema de monitoramento, avaliando a precisão dos
sensores utilizados em relação a métodos cientificamente aceitos e comumente
encontrados na literatura.
76
Também serão testados, em campo, os algoritmos de localização baseados
em RSSI, de forma a identificar o que apresenta o melhor desempenho, bem como
identificar as vantagens e desvantagens em relação à utilização de um sistema de
GPS.
Pretende-se avaliar novas alternativas de fontes de energia como, por
exemplo, energia solar, de forma que as baterias sejam recarregadas durante o
funcionamento do sistema em campo.
A partir dos dados de localização e dos sensores instalados nos animais,
pretende-se
também
desenvolver
algoritmos
que
possam
identificar
automaticamente alterações comportamentais, problemas de saúde, cio, hábitos
alimentares e hábitos de pastejo do rebanho.
Em relação ao hardware desenvolvido, nas versões posteriores, pretende-se
reduzir as dimensões da placa de circuito impresso a partir da utilização de
componentes SMD de forma que seja possível desenvolver uma placa de duas
faces. Também deverá ser desenvolvido um mecanismo de economia de energia, de
forma a gerenciar os modos Sleep do microcontrolador e do módulo XBee, quando
não estiverem em uso.
A medição de outras variáveis importantes, como frequência respiratória,
temperatura da pele do animal e temperatura retal, também deverá ser adicionada
ao sistema. No entanto, isso dependerá da existência e viabilidade de sensores.
77
6.
Referências
AKYLDIZ, Ian. F. et al. (2002). A Survey on Sensor Networks. IEEE Communications
Magazine, Vol.40 (8), p. 102-114.
ALEMDAR, Hande; ERSO, Cem. (2010). Wireless sensor networks for healthcare: A
survey. Computer Networks 54. p. 2688–2710.
BARONTI, PAOLO; PRASHANT, Pillai; CHOOK, Vince W.C.; CHESSA, Stefano;
GOTTA, Alberto; HU, Y. Fun. (2007). Wireless sensor networks: A survey on
the state of the art and the 802.15.4 and ZigBee standards. Computer
Communications (30). p. 1655-1695. doi:10.1016/j.comcom.2006.12.020.
BURATTI, Chiara; CONTI, Andrea; DARDARI, Davide; VERDONE, Roberto. (2009)
An Overview on Wireless Sensor Networks Technology and Evolution.
Sensors 2009, 9, 6869-6896; doi:10.3390/s90906869.
BUTLER, Declan. (2006). 2020 computing: Everything, everywhere. Nature 440,
402–405. doi:10.1038/440402a
CANIELLO, Márcio. A caprinocultura e o desenvolvimento do Semiárido: uma
proposta
para
a
UFCG.
Disponível
em
<
http://www.cdsa.ufcg.edu.br/portal/index.php?option=com_content&view=articl
e&id=889:a-caprinocultura-e-o-desenvolvimento-do-semiarido-uma-propostapara-a-ufcg&catid=92:artigos&Itemid=460#>. Acesso em Junho de 2012.
CARDENAS-LAILHACAR, B.; DUKES, M.D. (2010). Precision of soil moisture sensor
irrigation controllers under field conditions. Agricultural Water Management, n.
97, p. 666-672.
CERNY M., PENHAKER M. (2010). Personal System of Remote Health Care. 2nd
International Conference on Mechanical and Electronics Engineering (ICMEE),
Volume 1 p. 413-415.
COELHO, Lídio Afrânio Ramos. (2011). Efeitos do estresse térmico sobre
parâmetros reprodutivos de ruminantes: novas perspectivas. Trabalho de
Conclusão de Curso (Graduação em Medicina Veterinária) - Universidade
Federal do Vale do São Francisco, Campus de Ciências Agrárias, PE, 2011.
DIGI International. (2011). XBee®/XBee-PRO® ZB RF Modules - 90000976_H.
78
FAWC,
Farm
Animal
Welfare
Council.
Five
Freedoms.
Disponível
em
<http://www.fawc.org.uk/freedoms.htm>. Acesso em Junho de 2012.
FRASER, D; WEARY, D M; PAJOR, E A; MILLIGAN, B N. (1997). Scientific
Conception Of Animal Welfare That Reflects Ethical Concerns. Animal Welfare
1997, 6: 187-205.
GISLASON, Drew. (2008). ZigBee Wireless Networking. Newnes; 1st edition. 448 p.
ISBN-13: 978-0750685979.
HOARE, T.; MILNER, R. (eds) 2004. Grand challenges in computing–research. The
British Computing Society. ISBN 1-902505-62-X.
KAUSHISH, S. K.; GEORGE, G. C.; SENGUPTA, B. P. Effect of heat and water
restriction on physiological responses of Beetal and Black Bengal goats.
Indian Journal Animal Science, New Delhi, v. 57, n. 5, p. 461-465, 1987.
LAU, Erin-Ee-Lin; LEE, Boon-Giin; LEE, Seung-Chul; CHUNG, Wan-Young. (2008).
Enhanced Rssi-Based High Accuracy Real-Time User Location Tracking
System For Indoor And Outdoor Environments. International Journal On Smart
Sensing And Intelligent Systems, Vol. 1, No. 2, June 2008.
LEE, J. A.; ROUSSEL, J.D.; BEATTY, J.F. Effect of temperature season on bovine
adrenal cortical function, blood cell profile, and milk production. Journal of
Dairy Science, Champaign, v.59, n.1, p.104-108, 1974.
MALAN, S. W. (2000). The improved Boer goat. Small Ruminant Research, v. 36, p.
165 - 170, 2000.
MASIERO, Riccardo. (2007). Rssi Based Tracking Algorithms For Wireless Sensor
Networks: Theoretical Aspects And Performance Evaluation. Corso di Laurea
Specialistica in Ingegneria delle Telecomunicazioni A.A.
MOORE D., LEONARD J., RUS D., TELLER S., Robust Distributed Network
Localization with Noisy Range Measurements, SenSys’04,
Baltimore,
Maryland, USA, November 2004.
NÓBREGA, Giovanna Henriques da; SILVA, Elisângela Maria Nunes da; SOUZA,
Bonifácio Benício de; MANGUEIRA, Júlia Marry. A Produção Animal Sob A
Influência Do Ambiente Nas Condições Do Semiárido Nordestino. Revista
Verde (Mossoró – RN – Brasil) v.6, n.1, p. 67 - 73 janeiro/março de 2011.
79
PATWARI, N., Location Estimation in Sensor Networks. Electrical Engineering PhD
thesis, The Univerisity of Michigan, USA, 2005.
POLYCARPO, Rafaela Carareto. Zootecnia de Precisão na Pecuária Leiteira: Ficção
científica
ou
necessidade
para
o
futuro?.
Disponível
em
<http://www.milkpoint.com.br/radar-tecnico/sistemas-de-producao/zootecniade-precisao-na-pecuaria-leiteira-ficcao-cientifica-ou-necessidade-para-ofuturo-75979n.aspx>. Acesso em Junho de 2012.
RAPAPPORT, Theodore S. (1996). Wireless Communications:
Principles and
Practice, Prentice Hall, 1996. ISBN 0-13-375536-3.
SBC, Sociedade Brasileira de Computação. (2006). Grandes desafios - Computação
no Brasil 2006-2016.
SILVA, E.M.N. da; SILVA, G.A.; SOUZA, B.B. de Influência de fatores ambientais
sobre a resposta fisiológica e a produção de leite. 2010. Artigo em Hypertexto.
Disponível em: <http://www.infobibos.com/Artigos/2010_4/FatoresAmbientais
/index.htm>. Acesso em: 5/6/2012
SOUZA, B.B.; SOUZA, E.D.; SILVA, R.M.N.; CEZAR, M.F.; SANTOS, J.R.S.; SILVA,
G.A. Respostas fisiológicas de caprinos de diferentes grupos genéticos no
semi-árido paraibano. Ciência e Agrotecnologia, Lavras, v.32, n.1, p.314-320,
2008.
SOUZA, E. D.; SOUZA, B. B.; SOUZA, W. H. Determinação dos parâmetros
fisiológicos e gradiente térmico de diferentes grupos genéticos de caprinos no
Semi-Árido. Ciência e Agrotecnologia, v.29, n.1, p.177-184. 2005.
SUNG, Wen-Tsai; HSU, Yao-Chi. Designing an industrial real-time measurement and
monitoring system based on embedded system and ZigBee. Expert Systems
with Applications 38 (2011) 4522–4529.
WARK, T. ; CORKE, P. ; SIKKA, P. ; KLINGBEIL, L. ; YING GUO ; CROSSMAN,
C. ;
VALENCIA, P. ;
SWAIN, D. ;
BISHOP-HURLEY, G. (2007).
Transforming Agriculture through Pervasive Wireless Sensor Networks.
Pervasive Computing, IEEE v. 6, p. 50-57, 2007.
YICK, Jennifer; MUKHERJEE, Biswanath; GHOSAL, Dipak. Wireless sensor network
survey. Computer Networks. 2008. p. 2293-2330.
80
YUSSOFF, Y.; ABIDIN, H.Z.; RAHMAN, R.A.; YAHAYA, F.H. Development of a PICBased Wireless Sensor Node Utilizing XBee Technology. (ICIME) IEEE
International Conference on Information Management and Engineering, 2010,
p. 116-120. Digital Object Identifier: 10.1109/ICIME.2010.5477666.