Rede de Sensores Sem Fio Para Localização e Monitoramento de Pequenos Ruminantes

Transcrição

1 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 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 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, 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, 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 Ficha catalográfica elaborada pelo Sistema Integrado de Biblioteca SIBI/UNIVASF Bibliotecário: Renato Marques Alves

4 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. 5

6 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 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 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 , Frequência Cardíaca, Umidade Relativa, Temperatura, Rastreamento por RSSI, Ambiência, Conforto Térmico, Bioclimatologia, Zootecnia de Precisão.

8 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 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 , Heart Rate, Relative Humidity, Temperature, RSSI Tracking, Environment, Thermal Comfort, Bioclimatology, Animal Science Precision.

9 9 Lista de Figuras Figura 1 - Ilustração de um Animal Equipado com um Nó Sensor Figura 2 - Visão Geral do Sistema de Localização de Monitoramento Baseado em RSSF Figura 3 Descrição de Alto Nível de um Nó Sensor Figura 4 Visão Geral da Organização e Arquitetura de Uma RSSF Figura 5 - Comparação de Tecnologias Sem Fio. (FONTE: GISLASON, 2008) Figura 6 Aplicações do padrão ZigBee (ADAPTADO: GISLASON, 2008) Figura 7 Diagrama da Arquitetura e Pilha de Protocolos ZigBee. (FONTE: BARONTI et al., 2007) Figura 8 - Topologias de Redes ZigBee Figura 9 Principais Modelos de Módulos XBee PRO da Digi International Figura 10 - Estrutura Geral de um Quadro (frame) API. (Fonte: DIGI, 2011) Figura 11 - Tela do Software X-CTU. Utilizado para Configuração de Módulos XBee Figura 12 - Sintaxe de Comandos AT no Modo de Operação Transparente Figura 13 - Exemplos de Execução de Comandos AT no Modo Transparente Figura 14 - Troca de Pacotes API Para a Execução Local de Comandos AT Figura 15 - Troca de Pacotes API Para a Execução Remota de Comandos AT Figura 16 - Troca de Pacotes Para a Transmissão de Dados Figura 17 Algoritmo de Lateração Para Localização de Nós Móveis Figura 18 - Algoritmo do Mínimo Máximo Para a Localização de Nós Móveis Figura 19 Gráfico de Participação Percentual das Regiões Brasileiras no Rebanho Nacional 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 Figura 24 - Diagrama Entidade Relacionamento Figura 25 - Diagrama de Pinos do Módulo XBee Pro Series Figura 26 - Estação Coordenadora da Rede Figura 27 - Esquemático do Circuito de uma Estação de Referência Figura 28 - Diagrama de Blocos de Uma Estação Móvel Figura 29 - Esquemático do Circuito da Estação Móvel Figura 30 - a) Sensor de umidade Honeywell HIH b) Curva Tensão (Vdc) X Umidade Relativa (%UR) a 25 C e Tensão de Alimentação 3,3V Vdc Figura 31 Encapsulamento: a) TO-92 e b) SOIC; Diagrama de pinos: c) TO-92 e d) SOIC Figura 32 - a) Placa Receptora de Frequência Cardíaca Polar RE07 e b) Faixa Transmissora T Figura 33 Imagem Real e Diagrama de Pinos do PIC18LF Figura 34 - Desenvolvimento da Placa de Circuito Impresso Para a Estação Móvel Figura 22 - Tela do Software. Aba Banco de Dados Figura 23 - Tela do Software. Aba Amostragem 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

10 10 Lista de Tabelas Tabela 1 - Especificações da Camada Física Tabela 2 - Estrutura de Um Pacote API Para Comando AT Local (0x08) Tabela 3 - Estrutura de Um Pacote API de Resposta a um Comando AT Local (0x88) Tabela 4 - Estrutura de Um Pacote API Para Comando AT Remoto (0x17) Tabela 5 - Estrutura de Um Pacote API de Resposta a um Comando AT Remoto (0x97) Tabela 6 - Estrutura de Um Pacote API de Requisição de Transmissão (0x10) Tabela 7 - Estrutura de Um Pacote API de Recebimento de Dados (0x90) Tabela 8 - Estrutura de Um Pacote API de Status de Transmissão(0x8B) Tabela 9 - Pinos Configuráveis (GPIO) no Módulo XBee PRO S2 (Adaptado: DIGI, 2011) Tabela 10 Parâmetros para Comandos AT de Configuração dos Pinos GPIO (Adaptado: DIGI, 2011) Tabela 11 Organização de Uma Amostra de Canais Analógicos e Digitais de Um Módulo XBee. (Adaptado: DIGI, 2011) Tabela 12 - Exemplo de Uma Amostra de Canais Analógicos e Digitais (Adaptado: DIGI, 2011) Tabela 13 - Comparação Entre os Modos de Operação API e Transparente (ADAPTADO: DIGI, 2011) Tabela 14 - Ranking dos Maiores Criadores de Caprinos do Mundo. (Fonte: FAO, dados de 2010) Tabela 15 - Características do Módulo XBee PRO Series 2 da Digi Tabela 16 - Principais Características do Microcontrolador PIC18LF

11 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 12 Sumário 1. INTRODUÇÃO OBJETIVO OBJETIVOS ESPECÍFICOS REVISÃO BIBLIOGRÁFICA REDE DE SENSORES SEM FIO O PADRÃO ZIGBEE /IEEE Surgimento Organização e Arquitetura do Padrão ZigBee/IEEE DISPOSITIVOS XBEE Modos de Operação do XBee Modo de Operação Transparente (AT) Modo de Operação API Configuração dos Módulos XBee Comandos AT no Modo de Operação Transparente (AT) Comandos AT no Modo de Operação API Comandos AT Locais Comandos AT Remotos Transmissão de Dados no Modo de Operação API Entradas/Saídas Digitais e Analógicas nos Módulos XBee Amostragem de Entradas Analógicas e Digitais Comparação Entre os Modos de Operação API e Transparente (AT) LOCALIZAÇÃO DE NÓS MÓVEIS EM REDES DE SENSORES SEM FIO Cálculo da Distância Relativa Entre Nós (Ranging) Estimação da Localização dos Nós Lateração Algoritmo do Mínimo Máximo Refinamento CAPRINOCULTURA NO BRASIL BEM-ESTAR ANIMAL, BIOCLIMATOLOGIA E ZOOTECNIA DE PRECISÃO Influência de Variáveis Meteorológicas na Produção de Caprinos MATERIAIS E MÉTODOS SOFTWARE Interface Gráfica do Software Camada de Processamento de Dados Banco de Dados Montagem e Gerenciamento de Pacotes de Rede API XBee Comunicação Serial HARDWARE Características dos Módulos XBee PRO Series Estação Coordenadora (EC) Estações de Referência (ER) Estações Móveis (EM) Sensor de Umidade Relativa Honeywell HIH Sensor de Temperatura Sensor de Frequência Cardíaca Microcontrolador PIC 18LF RESULTADOS... 69

13 HARDWARE SOFTWARE EXPERIMENTOS EM ANIMAIS CONCLUSÕES REFERÊNCIAS... 77

14 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 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 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 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 Objetivos Específicos Montagem e configuração de uma rede de sensores sem fio, baseada em módulos XBee/ZigBee , 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 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 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 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 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 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 CARDENAS- LAILHACAR 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 Organização e Arquitetura do Padrão ZigBee/IEEE É importante ressaltar a diferença entre os padrões IEEE e ZigBee. O padrão IEEE 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 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 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 Spread- Spectrum). 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 Modulação O-QPSK BPSK BPSK Bits por símbolo 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 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 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 25 Digi International 1, 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 0x FFFF. 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

26 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 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 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) 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 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 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 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) 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ítio 2, 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

30 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 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 31 comando. Essa operação é realizada pelo recebimento da sequência de três caracteres 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-CTU 4. 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 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 Comandos AT no Modo de Operação API Conforme já mencionado na seção , 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 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 PACOTE API 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 Exemplo Descrição Delimitador de Início 0 0x7E Obrigatório em todo pacote API Tamanho do Pacote MSB 1 0x00 LSB 2 0x04 Quantidade de bytes entre o tamanho do pacote e o checksum. Neste exemplo 4 bytes = 0x04 Tipo do pacote API 3 0x08 Pacote do tipo 0x08 (comando AT local) O usuário pode Identificar o pacote com um ID do quadro (ACK) 4 0x01 número arbitrário para conferir a mensagem de status. Se for configurado como 0, nenhuma resposta de status é enviada. 5 0x4E (Letra N ) Nome do Comando AT Dois caracteres ASCII. Comando AT Neste exemplo executa-se o comando NI Node 6 0x49 (Letra I ) Identifier Valor do Parâmetro Quando presente indica que se deseja alterar o

34 PACOTE API 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 Índice Exemplo Descrição Delimitador de Início 0 0x7E Obrigatório em todo pacote API Tamanho do Pacote MSB 1 LSB 2 0x00 0x13 Quantidade de bytes entre o tamanho do pacote e o checksum. Neste exemplo 19 bytes = 0x13 Tipo do pacote API 3 0x88 Pacote do tipo 0x88 (Status de comando AT local) O usuário pode Identificar o pacote com um ID do quadro (ACK) 4 0x01 número arbitrário para conferir a mensagem de status. Se for configurado como 0, nenhuma resposta de status é enviada. 5 0x4E ( N ) Nome do Comando AT Dois caracteres ASCII Comando AT Este exemplo é a resposta do comando NI Node 6 0x49 ( I ) Identifier 0 = OK 1 = ERRO Status do Comando 7 0x00 2 = Comando Inválido 3 = Parâmetro Inválido 4 = Falha na Transmissão 8 0x53 ( S ) 9 0x45 ( E ) 10 0x4E ( N ) Valor do Parâmetro (Opcional) x53 ( 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 35 Soma de verificação (Checksum) x44 ( D ) 0x41 ( A ) 0x44 ( D ) 0x45 ( E ) 22 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 PACOTE API 36 Tabela 4 - Estrutura de Um Pacote API Para Comando AT Remoto (0x17) Campos do Pacote Índice Exemplo Descrição Delimitador de Início 0 0x7E Obrigatório em todo pacote API Tamanho do Pacote 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 Endereço de 64 bits de destino (SH,SL) Endereço de 16 bits de destino (MY) Opções de Comando Remoto Comando AT 5 0x00 6 0x13 7 0xA2 8 0x00 9 0x x6C 11 0x x9B 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 do destinatário. Os seguintes endereços também são suportados: 0x : Reservado para o coordenador da rede 0x FFFF: Endereço de Broadcast 13 0xA1 Endereço de 16 bits do destinatário. Deve ser igual a 14 0x83 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 15 0x02 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. 16 0x44 ( D ) Nome do Comando AT Dois caracteres ASCII. Neste 17 0x32 ( 2 ) 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. Valor do Parâmetro (Opcional) Soma de verificação (Checksum) Neste exemplo, configura-se o pino D2 como entrada analógica. O comando D2, utilizado como exemplo, 0x02 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 18 0xFA 0xFF Soma dos bytes a partir do índice 3 até o byte anterior ao checksum.

37 PACOTE API 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 Delimitador de Início 0 0x7E Obrigatório em todo pacote API Tamanho do Pacote MSB 1 0x00 LSB 2 0x0F Quantidade de bytes entre o tamanho do pacote e o checksum. Neste exemplo 15 bytes = 0x0F Tipo do pacote API 3 0x97 Pacote do tipo 0x97 (resposta a um comando AT remoto) O usuário pode Identificar o pacote com um número ID do quadro (ACK) 4 0x02 arbitrário para checar a mensagem de status. Se for configurado como 0, nenhuma resposta de status é enviada. 5 0x00 Endereço de 64 bits de destino (SH,SL) 6 0x13 7 0xA2 8 0x00 9 0x x6C 11 0x x9B Endereço de 64 bits da fonte. Os seguintes endereços também são suportados: 0x : Reservado para o coordenador da rede 0x FFFF: Endereço de Broadcast 13 0xA1 Endereço de 16 bits da fonte. Deve ser igual a 0xFFFE se Endereço de 16 bits o endereço do destinatário é desconhecido ou a de destino (MY) 14 0x83 transmissão broadcast. 0x00 = OK 0x01 = ERRO Status do comando 15 0x00 0x02 = Comando Inválido 0x03 = Parâmetro Inválido 0x04 = Falha na Transmissão Comando AT 16 0x44 ( D ) Nome do Comando AT Dois caracteres ASCII. Neste 17 0x32 ( 2 ) exemplo executa-se o comando NI Node Identifier Valor do Parâmetro (Opcional) Soma de verificação (Checksum) Quando presente indica o valor do parâmetro consultado. 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. 18 0x7E 0xFF Soma dos bytes a partir do índice 3 até o byte anterior ao checksum.

38 PACOTE API 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 Exemplo Descrição Delimitador de Início 0 0x7E Obrigatório em todo pacote API Tamanho do Pacote 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 3 0x10 Pacote do tipo 0x10 (Transmissão de dados RF) ID do quadro (ACK) 4 0x01 Endereço de 64 bits de destino (SH e SL do destinatário) MSB 5 0x00 6 0x13 7 0xA2 8 0x00 9 0x40 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 do destinatário. Os seguintes endereços também são suportados: 0x : Reservado para o coordenador da rede

39 PACOTE API 39 LSB x6C 11 0x52 0x9B 0x FFFF: Endereço de Broadcast Endereço de 16 bits 13 0xFF Endereço de 16 bits do destinatário. Deve ser igual a de destino. (MY do 0xFFFE se o endereço do destinatário é desconhecido ou 14 0xFE destinatário) a transmissão broadcast. Raio do Broadcast 15 0x00 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: Opções 16 0x00 0x01 Desabilita resposta ACK 0x20 Habilita Encriptação (Se EE=1) 0x40 - Usa o tempo limite de transmissão estendida para este destino. 17 0x4F ( O ) Mensagem (Dados) 18 0x4C ( L ) 19 0x41( A ) Mensagem (dados) que serão transmitidos via RF. Soma de verificação (Checksum) 20 0xC7 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 Exemplo Descrição Delimitador de Início 0 0x7E Obrigatório em todo pacote API Tamanho do Pacote Tipo do pacote API (Frame Type) Endereço de 64 bits do XBee fonte (SH,SL) MSB 1 0x00 LSB 2 0x16 MSB 4 LSB 11 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) 0x00 5 0x13 6 0xA2 7 0x00 8 0x40 9 0x6C 10 0x52 0x9B Endereço de 64 bits do remetente. É atribuído 0x FFFF se o endereço é desconhecido. Endereço de 16 bits 12 0x7D Endereço de 16 bits do remetente.

40 PACOTE API 40 do XBee fonte (MY) 13 0x85 Opções de recepção 14 0x x4F ( O ) Dados recebidos 16 0x4C ( L ) 17 0x41( A ) 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. Soma de verificação (Checksum) 18 0x43 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 Delimitador de Início 0 0x7E Obrigatório em todo pacote API Tamanho do Pacote Tipo do pacote API (Frame Type) MSB 1 0x00 LSB 2 0x16 Quantidade de bytes entre o tamanho do pacote e o checksum. Neste exemplo 22 bytes (0x16) 3 0x8B Pacote do tipo 0x8B (Pacote de status da transmissão) ID do quadro (ACK) 4 0x01 Identifica o pacote de status com o mesmo ID do pacote de requisição de transmissão enviado. 5 0x7D Endereço de 16 bits do XBee de destino (se a Endereço de 16 bits do destino (MY) 6 0x84 mensagem foi entregue corretamente). Caso contrário esse endereço é igual ao enviado no pacote de requisição de transmissão. Quantidade de tentativas de retransmissão 7 0x00 Número de tentativas de retransmissão Status de entrega (Delivery status) 8 0x00 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 41 Status de descoberta (Discovery status) Soma de verificação (Checksum) 9 0x01 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 10 0x71 0xFF Soma dos bytes a partir do índice 3 até o byte anterior ao checksum 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 Número do Pino Comando AT de Configuração CD/DIO12 4 P2 PWM0/RSSIM/DIO10 6 P0 PWM/DIO11 7 P1 DIO4 11 D4 CTS/DIO7 12 D7 ASSOC/DIO5 15 D5 RTS/DIO6 16 D6 AD3/DIO3 17 D3 AD2/DIO2 18 D2 AD1/DIO1 19 D1 AD0/DIO0 20 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 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 1 2 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 Entrada digital 4 Saída digital em nível baixo 5 Saída digital em nível alto 6-9 Funções alternativas disponíveis em alguns pinos. (CTS, RTS, etc.) 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 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 Nome Descrição 1 Conjuntos de amostras Quantidade de conjuntos de amostras no pacote. Sempre igual a 1. 2 Máscara de canais digitais 1 Máscara de canais analógicos 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 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 = b 1 conjunto de amostras 0x0C0C = b Canais digitais DIO 2,3,10 e 11 habilitados 0x03 = b 0x0408 = b 0x03D0 = 976 d 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 Entrada analógica AD0 = 0x03D0 = 976 d 0x0124 = 292 d Entrada analógica AD1 = 0x124 = 292 d 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 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). Interface simples Facilmente gerenciável por uma aplicação Facilidade no envio de dados para múltiplos destinatários Pacotes recebidos contém o endereço do remetente Características do Modo de Operação Transparente (AT) Todos os dados recebidos pela serial são transmitidos diretamente via RF, exceto quando o módulo está no modo comando 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 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 Configuração remota Diagnóstico de rede avançado 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 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 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 47 Refinamento: refina os resultados obtidos nas duas fases anteriores 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 P T e P r 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 G T e G r 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 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 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, 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 49 referência absoluta, como apresentado em MOORE, 2004 (MASIERO, 2007). Outras técnicas de localização podem ser consultadas em PATWARI, 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 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 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 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 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 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 52 Tabela 14 - Ranking dos Maiores Criadores de Caprinos do Mundo. (Fonte: FAO 5, dados de 2010). Posição País Rebanho (Cabeças) Percentagem do rebanho mundial 1º Índia ,00 16,71% 2º China ,00 16,36% 3º Bangladesh ,00 7,05% 4º Paquistão ,00 6,50% 5º Nigéria ,00 6,13% 6º Sudão ,00 4,71% 7º Irã ,00 2,79% 8º Etiópia ,00 2,38% 9º Indonésia ,00 1,83% 10º Mali ,00 1,79% 11º Mongólia ,00 1,51% 12º Níger ,00 1,48% 13º Quênia ,00 1,44% 14º Tanzânia ,00 1,40% 15º Somália ,00 1,38% 16º Burkina Faso ,00 1,34% 17º Brasil ,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

53 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% 14,9% 6,4% 30,6% Bahia Pernambuco Piauí 18,6% 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 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 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 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 56

57 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 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 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 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 Banco de Dados Para armazenar os dados foi utilizado o Sistema Gerenciador de Banco de Dados (SGBD) SQLite 6, 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 JDBC 7. 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

59 59 Figura 22 - Diagrama Entidade Relacionamento 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 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 RXTX 8 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

60 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 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 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) Alcance (Ambientes internos) Potência de transmissão Sensibilidade do receptor Frequência de operação Taxa de transmissão Tipo de modulação 3,2 Km 90 m +17 dbm (50mW) -102 dbm ISM 2.4 GHz 250 Kbps O-QPSK com DSSS

61 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 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 Rogercom 9 (Figura 24). 9

62 62 Figura 24 - Estação Coordenadora da Rede 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 63 Figura 25 - Esquemático do Circuito de uma Estação de Referência 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 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 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 65 Figura 28 - a) Sensor de umidade Honeywell HIH 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 (V out, em Volts) fornecida pelo sensor, a umidade relativa (UR Sensor, em %UR) e a tensão de alimentação do sensor (V s, 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. ( )( ( ) ) Equação 6 ( ( ) ) ( ) Equação 7 ( ) Equação 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 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 V out é a tensão de saída (em Volts), V s é 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. ( ) ( ( ) ) Equação 9 ( ) Equação 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 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 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 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 I 2 C 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 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 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 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 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 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.