Análise Nodal Do Consumo De Energia Para Rede De Sensores Sem Fio

Transcript

Universidade de Pernambuco Escola Politécnica de Pernambuco Departamento de Sistemas e Computação Programa de Pós-Graduação em Engenharia da Computação Frederico Cox Cavalcanti Lins Junior Análise Nodal de Consumo de Energia para Redes de Sensores sem Fio Dissertação de Mestrado Recife, fevereiro de 2010 UNIVERSIDADE DE PERNAMBUCO DEPARTAMENTO DE SISTEMAS E COMPUTAÇÃO PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA DA COMPUTAÇÃO FREDERICO COX CAVALCANTI LINS JUNIOR Análise Nodal de Consumo de Energia para Redes de Sensores sem Fio Dissertação apresentada como requisito parcial para a obtenção do grau de Mestre em Engenharia da Computação Prof. Dr. Abel Guilhermino da Silva Filho Orientador Prof. Dr. Renato Mariz de Moraes Co-orientador Recife, fevereiro de 2010 CIP – CATALOGAÇÃO NA PUBLICAÇÃO Frederico Cox Cavalcanti Lins Junior, Análise Nodal de Consumo de Energia para Redes de Sensores sem Fio / Frederico Cox Cavalcanti Lins Junior. – Recife: PPGEC da UPE, 2010. 134 f.: il. Dissertação (mestrado) – Universidade de Pernambuco. Programa de Pós-Graduação em Engenharia da Computação, Recife, BR–PE, 2010. Orientador: Abel Guilhermino da Silva Filho; Coorientador: Renato Mariz de Moraes. 1. Redes de sensores sem fio. 2. TinyOS. 3. Zygbee. 4. Microcontroladores. I. da Silva Filho, Abel Guilhermino. II. de Moraes, Renato Mariz. III. Título. “Se A é o sucesso, então A é igual a X mais Y mais Z. O trabalho é X; Y é o lazer; e Z é manter a boca fechada.” — A LBERT E INSTEIN Agradecimentos Aos meus pais, Frederico Cox e Maria José Diniz. Por todo apoio, suporte e compreensão nesse projeto. À minha irmã, Simone Cox, que sempre me motivou com os seus conselhos. À minha sobrinha, Ana Helena Cox, que despertou uma criança que havia dentro de mim. Ao Prof. Dr. Abel Guilhermino da Silva Filho, meu orientador. Pela colaboração, paciência e, principalmente, os seus conhecimentos que foram indispensáveis e passados cuidadosamente durante todo o desenvolvimento desse trabalho. Ao Prof. Dr. Renato Mariz de Moraes, meu co-orientador. Pelo modo como apoiou esse trabalho. Sua disponibilidade e empatia foram estímulos que permitiram-me ultrapassar os desafios. A Aldo Oliveira, um orientador da vida. Pela ajuda nos bons e difíceis momentos. Agradeço também a todos os colaboradores da Universidade de Pernambuco que, direta ou indiretamente, contribuíram para a realização e reflexão desse processo. Sumário GLOSSÁRIO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii ACRÔNIMOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix SíMBOLOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi LISTA DE FIGURAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii LISTA DE TABELAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv RESUMO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi ABSTRACT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii 1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . 1.1 Características de Redes de Sensores sem Fio . . 1.2 Motivação . . . . . . . . . . . . . . . . . . . . . 1.2.1 Volcano Monitoring . . . . . . . . . . . . . . . . 1.2.2 Monitoramento Estrutural da Golden Gate Bridge 1.3 Objetivo . . . . . . . . . . . . . . . . . . . . . . 1.4 Organização dessa Dissertação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 3 4 4 4 5 6 2 CONCEITOS BÁSICOS . . . . . . . . . . . . . . . . . . . . . . 2.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 MICAz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 Visão geral da Arquitetura . . . . . . . . . . . . . . . . . . . . . 2.2.2 Características . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.3 Microcontrolador - ATMEGA128L . . . . . . . . . . . . . . . . 2.2.4 Alimentação DC . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.5 2.4 GHz IEEE 802.15.4 / ZigBee-ready RF Transceiver - CC2420 2.2.6 Memória Flash (Data Logger) - AT45DB041 . . . . . . . . . . . 2.2.7 Conversor DC-DC - MAX1678 . . . . . . . . . . . . . . . . . . 2.2.8 Mote Interface Board - MIB520 . . . . . . . . . . . . . . . . . . 2.2.9 Placa de Aquisição de dados - MDA100CB . . . . . . . . . . . . 2.3 TinyOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.2 Estrutura de Programação - nesC . . . . . . . . . . . . . . . . . 2.3.3 Assinatura de Componentes . . . . . . . . . . . . . . . . . . . . 2.3.4 Componente Essenciais para Uso na Plataforma de Medição . . . 2.3.5 Protocolos de Roteamento . . . . . . . . . . . . . . . . . . . . . 2.4 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7 7 7 9 10 10 11 12 13 13 14 15 15 16 18 19 22 28 3 ESTADO DA ARTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Micro Power Meter for Energy Monitoring of Wireless Sensor Networks at Scale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 Visão Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.2 Formulação do Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.3 Arquitetura Utilizada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.4 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.5 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 A Runtime Energy Monitoring System for Wireless Sensor Networks . . . . 3.3.1 Visão Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.2 Arquitetura Utilizada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.3 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.4 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4 Energy Measurements for MicaZ Node . . . . . . . . . . . . . . . . . . . . 3.4.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.2 Medições de uma bateria de polímero de lítio (LiPo) . . . . . . . . . . . . . 3.4.3 Medições em um MICAz . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.4 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 30 4 ARQUITETURA PROPOSTA . . . . . . . . . . 4.1 Introdução . . . . . . . . . . . . . . . . . . . . 4.2 Fluxograma de Projeto . . . . . . . . . . . . . . 4.3 Visão Geral da Arquitetura . . . . . . . . . . . 4.4 Módulo de Amplificação de Corrente . . . . . . 4.4.1 Alternativas para medição de corrente . . . . . . 4.4.2 Amplificador de Corrente Escolhido . . . . . . 4.5 Conversor de Voltagem para Frequência . . . . 4.6 Microcontrolador . . . . . . . . . . . . . . . . 4.7 Fonte de Alimentação DC e Circuitos Utilizados 4.8 Circuito de Corrente . . . . . . . . . . . . . . . 4.9 Interface MICAz x Placa de Medição . . . . . . 4.10 Captura de Frequência . . . . . . . . . . . . . . 4.11 Máquinas de Estados . . . . . . . . . . . . . . 4.12 Validação da Arquitetura . . . . . . . . . . . . 4.12.1 Validação da Tensão . . . . . . . . . . . . . . . 4.12.2 Validação da Corrente . . . . . . . . . . . . . . 4.13 Esquemático da Placa de Medição . . . . . . . 4.14 Placa de Circuito Impresso . . . . . . . . . . . 4.15 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 46 46 48 49 49 50 52 55 56 58 59 60 61 64 64 66 68 69 70 5 RESULTADOS . . . . . . . . . . . 5.1 Introdução . . . . . . . . . . . . . 5.2 Cenário Experimental . . . . . . . 5.3 TinyOS Terminal . . . . . . . . . 5.4 Experimento - Nó Individual . . . 5.5 Experimento - Protocolo Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 71 72 74 74 75 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 30 32 33 35 36 36 36 37 39 40 40 40 40 41 44 44 5.6 5.7 Experimento - Protocolo Tymo . . . . . . . . . . . . . . . . . . . . . . . . Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 78 6 CONSIDERAÇÕES FINAIS . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 79 80 REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 7 I. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 8 II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 9 III . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 10 IV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 11 V . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 12 VI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 Glossário base-station nó responsável por concentrar os dados provenientes da Rede de Sensores sem Fio (RSSF) - uma rota final. vii, 2, 6, 8, 23, 32, 71, 72, 79 buffer Região de memória temporária utilizada para escrita e leitura de dados.. 12 CCD Charge-Coupled Device ou Dispositivo de Carga Acoplada.. 28 Collection Protocolo de Roteamento multi-hop. 23, 24 data logger Dispositivo utilizado para armazenar em massa de dados de um sistema.. 8 duty cycle ciclo de trabalho. 30, 31, 40, 52 firmware software embarcado. 11–14, 32, 58 flash memória de computador do tipo Electrically-Erasable Programmable Read-Only Memory (EEPROM). 10, 53 gateway O mesmo que base-station - uma rota final. 2, 23, 25, 72 I2C (Inter-Intergrated Circuit) é um barramento serial barramento multi-mestre desenvolvido pela Philips que é usado para conectar periféricos de baixa velocidade. 8, 14, 20, 21, 29, 32, 33, 37, 38, 40, 46, 56, 61–63 in situ expressão latina que significa no lugar. 30, 31, 46 MICAz É um nó de RSSF.. 56, 58, 59 mote Nodo individual de uma RSSF.. 33 multi-hop Arquitetura flexível para mover dados eficientemente entre dispositivos.. vii, 23–27 node-sink O mesmo que base-station - uma rota final. 23, 72 Open Source Código aberto, ou open source em inglês, foi criado pela OSI (Open Source Initiative) e refere-se a software também conhecido por software livre.. 15 PP3 É uma bateria em formato de prisma retangular com uma tensão nominal de 9V.. 56 RS232 Padrão para troca de dados binários comumente usado nas portas seriais dos PCs.. 14 sampling rate Número de amostras do sinal por segundo.. 53 tensão de offset Tensão presente na saída de um amplificador mesmo que as entradas sejam 0 Volts. 55 TinyOS 2.x Sistema operacional open-source projetado para redes de sensores sem fio.. viii, 26 TYMO Implementação do DYnamic Manet On-demand routing protocol (DYMO) em TinyOS 2.x. 26 Acrônimos ADC Analog to Digital Converter. 8, 10, 14, 19, 34, 54–56 AES Advanced Encryption Standard. 11 AODV Ad hoc On-Demand Distance Vector Routing. 26 API Application Programming Interfaces. 15, 28 CCP Capture/Compare/PWM. 56, 60–62, 79 CMOS Complementary metal-oxide-semiconductor. 8, 10 CRC Cyclic redundancy check. 74 DIP Dual In Line Package. 56 DSP Digital Signal Processor. 34 DSSS Direct Sequence Spread Spectrum. 8, 11 DYMO DYnamic Manet On-demand routing protocol. viii, 26 EEPROM Electrically-Erasable Programmable Read-Only Memory. vii, 10, 53, 56 IA Instrumentation Amplifier. 50 IC Integrated Circuit. 56 ICSP In-Circuit Serial Programming. 58 IEEE Institute for Electrical and Electronics Engineers. 8, 10, 11 IETF The Internet Engineering Task Force. 26 IO Input/Output. 10, 14 ISM Industrial Scientific and Medical bands. 11 ISP In System Programming. 14 JTAG Joint Test Action Group. 10 LDO Low-Dropout Output. 57 LED Light Emitting Diode. 8, 14, 41, 44 LiPo Lithium Polymer Battery. 40, 41, 44, 45 LQI Link Quality Indicator. 11 MAC Media Access Control. 11 MANET Mobile Ad-hoc Networks. 26 MEMS Micro-Electro-Mechanical Systems. 1 MIB Mote Interface Board. 23, 73 MSSP Master Synchronous Serial Port. 55 PCB Printed Circuit Board. 20, 48, 56 PDA Personal Digital Assistants. 36, 79 PWM Pulse Width Modulation. 10, 60 RAM Random Access Memory. 9, 10, 12, 15, 52 RERR Route Error. 27 RISC Reduced Instruction Set Computer. 8 RREP Reply Route. 27 RREQ Route Request. 26, 27 RSSF Rede de Sensores sem Fio. vii, 1–7, 15, 16, 22, 23, 25, 26, 28–33, 36, 37, 39, 40, 44, 46, 52, 70–72, 74, 78, 79 RSSI Received Signal Strength Indication. 11 RTOS Real Time Operating System. 55 SMD Surface Mounted Devices. 48, 56 SO Sistema Operacional. 15 SOIC Small-Outline Integrated Circuit. 56 SPI Serial Programming Interface. 9–12, 28 SPOT Scalable Power Observation Tool. 32–37, 40, 44 TEP TinyOS Enhancement Proposals. 16, 78 USART Universal Synchronous Asynchronous Receiver Transmitter. 8, 10, 14 USB Universal Serial Bus. 13, 14 V/F Voltage-to-Frequency. 33–35, 53–55, 65, 70, 79 WSN Wireless Sensor Network. 1, 2, 4–7, 11, 15, 23, 29, 30, 32, 36, 40, 44, 53, 79, 80 Símbolos Bit Menor unidade de informação que pode ser armazenada ou transmitida.. xi Byte 8 (oito) Bits.. 12 dBm A relação da potência de um dado dispositivo em relação a 1 mW é expressa em decibeis. 73, 78 Ghz Unidade de frequência (Hz) multiplicada pelo fator 1.000.000.000. 8, 11 Hz Unidade derivada do SI para frequência. xi kb 1024 bytes. 9, 10 Kbps 1000 bits por segundo.. 11, 20, 21 Khz Unidade de frequência (Hz) multiplicada pelo fator 1000. 4, 31, 32, 79 mA unidade de corrente elétrica por fator 1000. 9, 11, 12, 25, 33, 34, 37, 41, 43, 44, 52, 54, 73 Mhz Unidade de frequência (Hz) multiplicada pelo fator 1.000.000.000. 9, 12, 31 mV unidade de Tensão elétrica por fator 1000. 33, 52, 54, 55 V unidade de Tensão elétrica. 10–13, 39, 41, 42, 52 Lista de Figuras 1.1 1.2 1.3 Exemplo típico de uma RSSF. . . . . . . . . . . . . . . . . . . . . . Arquitetura do Projeto “Volcano Monitoring”. . . . . . . . . . . . . . Gold Gate Bridge. . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4 5 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 2.11 2.12 2.13 2.14 2.15 2.16 2.17 2.18 Arquitetura e foto do MICAz. . . . . . . . . . . . . . . . . . . . . . Arquitetura detalhada do MICAz. . . . . . . . . . . . . . . . . . . . Circuito de Alimentação DC do MICAz. . . . . . . . . . . . . . . . Valores típicos para RSSI x potência de entrada. . . . . . . . . . . . Pinagem da memória AT45DB041. . . . . . . . . . . . . . . . . . . Circuito típico de utilização do MAX1678. . . . . . . . . . . . . . . Vista superior da MIB520. . . . . . . . . . . . . . . . . . . . . . . . Foto da placa de aquisição de dados - MDA100CB. . . . . . . . . . . Matriz MDA100CB. . . . . . . . . . . . . . . . . . . . . . . . . . . Grafo da Aplicação BlinkLed. . . . . . . . . . . . . . . . . . . . . . Fluxograma da aplicação BlinkLedAppC. . . . . . . . . . . . . . . . Conexões do módulo Atm128I2CMasterC. Fonte: [4] . . . . . . . . . Cenário Típico com 7 sensores . . . . . . . . . . . . . . . . . . . . . Aplicação Prática: Proposta de Cenário . . . . . . . . . . . . . . . . Exemplo: A envia um pacote para H. . . . . . . . . . . . . . . . . . Requisição de rota entre A e H. . . . . . . . . . . . . . . . . . . . . RREP é enviada pela rota mais curta entre A e H. . . . . . . . . . . O nó G deslocou-se para outra posição e o nó F não tem mais rota para alcançar G e H. B e C não encaminha RERR porquê C conhece o caminho para D. . . . . . . . . . . . . . . . . . . . . . . . . . . . Aplicação Prática: Proposta de Cenário . . . . . . . . . . . . . . . . 8 9 11 12 12 13 14 14 15 17 18 21 23 25 26 27 27 Comportamento do consumo em função do tempo durante 4 segundos. Comportamento do consumo em função do tempo durante curto período. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . O “Scalable Power Observation Tool -SPOT”, consiste de um resistor shunt, amplificador, conversor de voltagem para frequência e dois contadores. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPOT - Arquitetura. . . . . . . . . . . . . . . . . . . . . . . . . . . Comparação das medidas obtidas pelo SPOT e um amperímetro. . . . Energia (mJ) em Função do Tempo (S). . . . . . . . . . . . . . . . . Corrente (mA) em função do Tempo (S). . . . . . . . . . . . . . . . Arquitetura do “Runtime Energy Monitoring System for Wireless Sensor Networks”. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Foto da placa de medição. . . . . . . . . . . . . . . . . . . . . . . . 31 2.19 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 28 28 31 32 33 35 35 36 37 38 3.10 3.11 3.12 3.13 3.14 3.15 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12 4.13 4.14 4.15 4.16 4.17 4.18 4.19 4.20 4.21 4.22 4.23 4.24 4.25 4.26 4.27 4.28 4.29 5.1 5.2 5.3 5.4 5.5 5.6 Curva de Erro do “Runtime Energy Monitoring System for Wireless Sensor Networks”. . . . . . . . . . . . . . . . . . . . . . . . . . . . Descarga de uma bateria de LiPO a 37.8mA. . . . . . . . . . . . . . Modos de economia de energia do ATMega128L. a: Busy (mul), b:Busy (jmp), c:NOP, d:Idle, e:ADC, f:Ext. Standby, g: Save. . . . . . Média do Consumo de Energia. . . . . . . . . . . . . . . . . . . . . Benefício de diminuir a frequência do ATMEGA128L. . . . . . . . . Consumo do CC2420. . . . . . . . . . . . . . . . . . . . . . . . . . 39 41 42 43 43 43 Fluxograma de Projeto da Placa de Medição . . . . . . . . . . . . . . Visal Geral da Arquitetura da Placa de Medição. . . . . . . . . . . . Voltímetro aferindo a queda de tensão no resistor “shunt”. . . . . . . Low-side current sensing . . . . . . . . . . . . . . . . . . . . . . . . High-side current sensing . . . . . . . . . . . . . . . . . . . . . . . Diagrama Funcional - MAX4372. . . . . . . . . . . . . . . . . . . . Um típico comportamento nodal de consumo consistindo de longos períodos de baixa corrente pontuado por curtos períodos de atividade com alta corrente. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Diagrama funcional do AD654. . . . . . . . . . . . . . . . . . . . . Configuração simples V/F do AD654. . . . . . . . . . . . . . . . . . Configuração do conversor de voltagem para frequência utilizada na placa de medição. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pinagem do PIC18F2620. . . . . . . . . . . . . . . . . . . . . . . . Panasonic PP3 (9 volt) battery. . . . . . . . . . . . . . . . . . . . . . Pinagem do LE33AB. . . . . . . . . . . . . . . . . . . . . . . . . . Circuito de Captura de Corrente. . . . . . . . . . . . . . . . . . . . . Fotos do Esquema de Captura de Corrente. . . . . . . . . . . . . . . Sensor Board MDA100CB e Matriz de Prototipação. . . . . . . . . . Barra de Pinos para Interconexão Mote x Placa de Medição. . . . . . Diagrama de Blocos do Modo de Captura. . . . . . . . . . . . . . . . Máquina de Estados do PIC18F2620. . . . . . . . . . . . . . . . . . Máquina de Estados do CCP. . . . . . . . . . . . . . . . . . . . . . . Máquina de Estados do MICAz. . . . . . . . . . . . . . . . . . . . . Diagrama de Blocos do Modo de Captura. . . . . . . . . . . . . . . . Tabela de Variação de tensão em função de Multímetro e Osciloscópio. Relação entre a tensão no multímetro e a tensão capturada. . . . . . . Relação entre a corrente no multímetro e a corrente capturada. . . . . Relação entre a corrente no multímetro e a corrente capturada. . . . . Diagrama Esquemático da Placa de Medição. . . . . . . . . . . . . . Placa de Circuito Impressso - PCB. . . . . . . . . . . . . . . . . . . Foto da Placa de Medição. . . . . . . . . . . . . . . . . . . . . . . . 47 48 49 50 50 51 Fluxograma de obtenção de medidas de consumo. . . . . . . . . . . . Cenário Experimental com detalhes para o raio de alcance de cada nó e rotas de comunicação. . . . . . . . . . . . . . . . . . . . . . . . . Cenário Experimental para Teste dos Protocolos de Roteamento . . . Software TinyOS Terminal . . . . . . . . . . . . . . . . . . . . . . . Dados de apenas um nó Individual . . . . . . . . . . . . . . . . . . . Nó Individual - Gráfico. Relação entre a Corrente e o tempo . . . . . 71 52 53 54 54 56 57 57 58 59 59 61 61 61 62 62 64 65 66 66 67 68 69 70 72 72 74 75 75 5.7 5.8 5.9 5.10 5.11 5.12 5.13 5.14 Protocolo Collection Dados do Nó 1 . . . . . . . . . . . . . . . . . . Protocolo Collection Dados do Nó 2 . . . . . . . . . . . . . . . . . . Protocolo Collection Dados do Nó 3 . . . . . . . . . . . . . . . . . . Protocolo Collection Gráfico. Relação entre a potência e o tempo dos 3 nós . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Protocolo Tymo Dados do Nó 1 . . . . . . . . . . . . . . . . . . . . Protocolo Tymo Dados do Nó 2 . . . . . . . . . . . . . . . . . . . . Protocolo Tymo Dados do Nó 3 . . . . . . . . . . . . . . . . . . . . Protocolo Tymo Gráfico. Relação entre a potência e o tempo dos 3 nós 75 76 76 76 77 77 77 77 Lista de Tabelas 1.1 Características de RSSF. . . . . . . . . . . . . . . . . . . . . . . . . 2.1 2.2 2.3 2.4 2.5 2.6 Componentes da Arquitetura do MICAz . . . . . Características - MICAz. . . . . . . . . . . . . . Função de cada pino da memória AT45DB041. . Principais Interfaces do componente CollectionC Tipos de Perfis no protocolo Collection . . . . . Camadas do protocolo TYMO. . . . . . . . . . . 4.1 4.2 4.3 Fases de Projeto da Placa de Medição . . . . . Etapas da Arquitetura da Placa de Medição. . . Relações entre Corrente, Tensão diferencial de Saída. . . . . . . . . . . . . . . . . . . . . . . Características principais do PIC18F2620. . . . Características principais do LE33AB. . . . . . Conector ICSP - Pinagem. . . . . . . . . . . . Conector MOTE - Pinagem. . . . . . . . . . . Modos do CCP. . . . . . . . . . . . . . . . . . 4.4 4.5 4.6 4.7 4.8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 . . . . . . 8 9 13 24 25 26 . . . . . . . . . . . . . . . . . . . . . . . . entrada e Tensão de . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 48 52 56 58 58 59 60 Resumo A limitação de energia disponível em nodos de redes de sensores sem fio é um fator crítico. Na maioria ou quase em sua totalidade, os sensores são colocados em áreas remotas que não permitem facilmente o acesso a esses elementos para troca de baterias. Nodos são alimentados a baterias e o desenvolvimento das baterias ainda é lento quando comparado ao rápido crescimento tecnológico dos componentes eletrônicos. O tempo de vida útil de um sensor depende da quantidade de energia disponível. Protocolos de roteamento e algoritmos devem ser escolhidos considerando a eficiência na descoberta e manutenção das rotas e a otimização na quantidade de energia consumida. A escolha correta destes fatores impactam diretamente no funcionamento da rede. Uma solução viável para minimizar tal problema, consiste na aferição prática do consumo tanto destes dispositivos individualmente quanto dos protocolos de roteamento funcionando conjuntamente numa rede densamente distribuída. Este documento aborda o planejamento, implementação e montagem de um protótipo de dispositivo para aferir o consumo de nós de uma rede de sensores sem fio (Placa de Medição). Uma análise considerando diferentes protocolos de roteamento visando avaliar o consumo de energia de cada um deles foi implementada. Palavras-chave: Redes de sensores sem fio, TinyOS, Zygbee, microcontroladores. Abstract The limitation of energy available in the nodes of wireless sensors networks is a critical factor. The sensors are placed in remote areas that do not easily allow access to these elements for changing batteries. Nodes are powered by batteries and the development of batteries is still slow compared to the rapid technological growth of electronic components. The lifetime of a sensor depends on the amount of energy available. Routing protocols and algorithms must be chosen considering the efficiency in finding and maintaining routes and optimizing the amount of energy consumed. The correct choice of these factors directly impact the functioning of the network. A feasible solution to minimize this problem is the practice of measuring consumption of both of these devices individually and the routing protocols running together in a densely distributed network. This document discusses the planning, implementation and installation of a prototype device to measure the consumption of nodes in a network of wireless sensors - Measuring Board. This includes an analysis considering different routing protocols to evaluate energy consumption. Keywords: MICAz, routing protocols, wireless sensors networks, energy consumption. Capítulo 1 Introdução Redes de Sensores sem Fio - RSSF é uma tecnologia que possibilita o monitoramento e controle do mundo físico[42]. Consistem de uma árvore de dispositivos - denominados sensores, nodos ou nós - densamente distribuídos em uma área na qual deseja-se investigar ou controlar um fenômeno físico. Nodos em RSSF podem ser equipados com sensores de infra-vermelho, acústicos, temperatura, humidade, sísmicos, etc... O desenvolvimento da indústria eletrônica, a miniaturização dos circuitos integrados, a popularização dos Micro-Electro-Mechanical Systems (MEMS)1 e a necessidade de uma arquitetura de rede auto-organizável de baixo custo e consumo, resultou no surgimento das redes de sensores sem fio - RSSF também conhecidas por Wireless Sensor Network (WSN). Em telecomunicações, redes ad hoc são um tipo de rede que não possui um nó ou terminal especial - geralmente designado como ponto de acesso - para o qual todas as comunicações convergem e que as encaminha para os respectivos destinos. Assim, uma rede de computadores ad hoc é aquela na qual todos os terminais funcionam como roteadores, encaminhando de forma comunitária as comunicações advindas dos terminais vizinhos. Ligeiramente diferente das redes ad hoc, as RSSF´s são uma sub-categoria das redes ad hoc que possuem um ou mais nós, também chamados de “base-station” ou estações base, cujo objetivo é a coleta de dados provenientes dos sensores da rede. A importância das Redes de Sensores sem Fio se deve à viabilização de uma infraestrutura de comunicações de baixo custo que possibilita a coleta, disseminação e monitoramento de uma variedade de fenômenos físicos. Redes de sensores têm grande aplicação em locais de difícil acesso ou áreas perigosas (reservas ambientais, oceanos, vulcões, rios, florestas, etc.)[41][51][52]. Algumas aplicações de RSSF´s são: Militar: funções de monitoramento, rastreamento, segurança, controle e manutenção; Industrial: funções de monitoramento, em processos químicos e biológicos; Aviação: substituindo as redes com fio, como já são usadas hoje; Ambiente: monitorando variáveis ambientais em prédios, florestas, oceanos, etc; Tráfego: monitoramento de vias, estacionamentos, etc; 1 Integração de elementos mecânicos, sensores, atuadores e eletrônica no mesmo substrato comum da tecnologia de microfabricação. 2 Medicina: Monitoramento de órgãos vitais de organismos vivos. Uma WSN pode ser definida portanto como uma infraestrutura compreendendo sensores, elementos computacionais (microcontroladores) e elementos de comunicação que possiblite ao administrador investigar os fenômenos do ambiente. O administrador pode ser um grupo de pesquisa, uma entidade governamental, industrial ou comercial. O ambiente pode ser o mundo físico, um sistema biológico, um grupo de pacientes sendo monitorados, entre outras aplicações[55]. Os principais componentes de um nó Sensor são o transceptor de comunicação sem fio[31], a fonte de energia[10] e o microcontrolador[24]. Neste trabalho será utilizado o sensor MICAz, produzido pela Crossbow Technology[57, 25, 17] para validar a metodologia de controle de consumo de energia. O escopo de desenvolvimento desse texto se limitará apenas a redes cujos nós são constituídos de sensores produzidos pela Crossbow, especificamente o MICAz. Esta limitação se deve principalmente à plataforma que temos disponível para desenvolvimento desta dissertação de mestrado. No entanto, tais aspectos não empobrecem o trabalho, tendo em vista que esta é uma solução do estado da arte com características que serão levantadas posteriormente. RSSFs diferem de redes de computadores tradicionais em vários aspectos[43, 52, 41]: • Geralmente possuem um grande número de sensores distribuídos que operam sem a intervenção humana. • Severas restrições de energia. • Possuem mecanismos de auto-gerenciamento, auto-organização, auto-manutenção e auto-proteção. • Todos os sensores operam de modo colaborativo. Assim, as RSSF´s desempenham uma tarefa importante através de um esforço colaborativo dos sensores que enviam os dados provenientes da rede até atingir a estação-base (base-station ou gateway). A base-station encarrega-se de entregar estes dados a um ou mais computadores que elaboram cálculos de maior complexidade tornando a informação visível aos observadores. 3 1.1 Características de Redes de Sensores sem Fio A Figura 1.1 é um cenário típico de uma RSSF. Observa-se uma árvore de sensores distribuídos e denominados “Wireless Sensor Network”. Uma rota cuja origem é o nodo Fonte foi estabelecida. O ponto denominado sorvedouro agrega as informações provenientes da rede. Este agregador pode ser uma estação conectada à internet ou diretamente a um PC. O usuário visualiza as informações provenientes da rede através de seu PC. Figura 1.1: Exemplo típico de uma RSSF. A Tabela 1.1 exibe algumas características de uma RSSF. Tabela 1.1: Características de RSSF. Endereçamento dos nós: Agregacão dos dados: Móvel ou Estacionária: Densidade: Limitação da energia disponível: Baixa capacidade de Processamento: Auto-organização da rede: Baixo duty cicle: Cada nó da rede possui um endereço distinto de 16 bits. Um ou mais nós, também chamados de “basestation” ou estação base que coletam os dados provenientes dos sensores. Os sensores podem ser estáticos ou móveis. Quantidade de sensores que foram distribuídos ao longo da cobertura da RSSF. Há uma limitação de energia porque os nós são alimentados com baterias. O processamento de um nó da rede é desempenhado por um microcontrolador com limitações de memória. O MICAz possui apenas 128Kbytes de memória Flash. Uma RSSF se auto-organiza no caso de sensores que apresentem problemas deixando de fazer parte da rede. Na maior parte do tempo os sensores estão no modo sleep. A taxa típica de duty cicle é de 1%. 4 1.2 1.2.1 Motivação Volcano Monitoring O “Volcano Monitoring” é um projeto do “Harvard Sensor Networks Lab” que consiste no monitoramento de erupções de vulcões ativos e perigosos através de RSSF´s. O baixo custo, tamanho e requisitos de energia das redes de sensores sem fio são algumas das vantagens existentes na instrumentação utilizada no estudo de atividades vulcânicas e tectonismo[37, 39, 63, 62]. Uma árvore de sensores foi distribuídas no vulcão “El Reventador” situado no Equador entre julho e agosto de 2005. A distribuição consistiu de 16 nós, equipados com sensores sísmicos com resolução de 24 bits por canal, numa faixa de 3 km a partir do cume até a base. A Figura 1.2 ilustra a organização e topologia usada nesta pesquisa[37, 39, 63, 62]. Figura 1.2: Arquitetura do Projeto “Volcano Monitoring”. 1.2.2 Monitoramento Estrutural da Golden Gate Bridge Em 7 de Novembro de 1940, a ponte Tacoma Narrows de 1.600 metros, cai após alguns meses de sua inauguração. Este fato se deu devido a um colapso gerado por fortes ventos naquela região. A Ponte de Tacoma sempre balançava, mas neste dia os ventos a uma velocidade de aproximadamente 65 km por hora gerou movimentos torsionais colocando a estrutura em ressonância provocando o seu desmoronamento.[64]. Para monitoração de fenômenos deste tipo, WSN´s têm sido utilizadas em estruturas críticas e vulneráveis a ações de fenômenos ambientais[35]. A Golden Gate Bridge (GGB), Figura 1.3, é analisada por uma RSSF constituída de 64 nós equipados com acelerômetros e distribuídos de forma a coletar vibrações a uma taxa de sample de 1Khz[34, 35]. Entre as duas colunas da ponte foram adicionados 51 nodos sensores cobrindo uma extensão de 4200ft. Em cada coluna foram colocados 8 nós ao longo de 500ft de altura. A limitação de energia disponivel nos nós das RSSF´s é um fator crítico. Na maioria ou quase em sua totalidade, os sensores são colocados em áreas remotas que não permitem facilmente o acesso a esses elementos para troca de baterias. Nodos de RSSF´s são alimentados a baterias e, segundo GINATTO, o desenvolvimento das baterias ainda é lento quando comparado ao rápido crescimento tecnológico dos componentes eletrônicos. Ainda segundo [21], além do aumento nas pesquisas sobre 5 Figura 1.3: Gold Gate Bridge. o desempenho das mesmas, o foco deixou de ser voltado apenas para o aumento da sua capacidade e passou a ser visto de forma unificada durante um projeto eletrônico. Segundo LOUREIRO et al., o tempo de vida de vida de um sensor depende da quantidade de energia disponível. Protocolos de roteamento e algoritmos para RSSF´s devem ser escolhidos considerando a eficiência na descoberta e manutenção das rotas e a otimização na quantidade de energia consumida. A escolha correta destes fatores implica diretamente na vida útil dos sensores e funcionamento da WSN como um todo. Uma solução viável para minimizar tal problema consiste na aferição prática do consumo tanto destes dispositivos individualmente quanto dos protocolos de roteamento funcionando conjuntamente numa rede densamente distribuída. 1.3 Objetivo Este documento aborda o planejamento, implementação e montagem de um protótipo de um dispositivo para aferir o consumo de nós de uma RSSF (Placa de Medição). Uma análise inédita considerando diferentes protocolos de roteamento visando avaliar o consumo de energia de RSSF´s é apresentada. Novos protocolos de roteamento podem ser avaliados quanto à eficiência energética através de avaliações nodais. O hardware de medição desenvolvido neste trabalho pode ser utilizado para aperfeiçoar modelos de energia de simuladores, tornando assim os resultados das simulações o mais próximo possível de um sistema real. 6 1.4 Organização dessa Dissertação O Capítulo 2 mostra a arquitetura do nodo utilizado nos experimentos práticos e os conceitos básicos sobre o desenvolvimento para RSSF. O Capítulo 3 ilustra as pesquisas do “estado da arte”, destacando o que há de mais recente no campo de aferição prática no consumo de nodos de RSSF´s. O Capítulo 4 ilustra o planejamento, organização, projeto, implementação e montagem do protótipo da placa de medição de consumo para nós em WSN. Adicionalmente são abordadas as alternativas e técnicas que foram utilizadas e o princípio de funcionamento de cada dispositivo empregado na montagem da Placa de Medição. O Capítulo 5 compreende os resultados obtidos através de três experimentos. Sendo 2 em função dos protocolos de roteamento Collection[20] e Tymo[7, 19, 58] e 1 consistindo de uma rede com apenas um nó enviando informações de consumo diretamente (1 salto) para uma base-station. Os protocolos utilizados[20, 7, 19, 58] são oficialmente incluídos na distribuição do TinyOS 2.1[4, 40]. As conclusões e sugestões de futuros trabalhos são apresentadas no Capítulo 6. Capítulo 2 Conceitos Básicos 2.1 Introdução “Wireless Sensor Networks” (WSN) são constituídas de um sistema de “motes”1 densamente distribuídos que operam de forma colaborativa. Cada dispositivo é dotado de capacidade computacional (microcontrolador), sensores, transceptor de rádio e fonte de energia. Estes sistemas conectam o ambiente físico combinando o gerenciamento de informações para monitoramento, automação e controle de diversas aplicações. O sensor utilizado nesta dissertação é o MICAz[57, 25], fabricado pela Crossbow que possui um vasto portifólio de produtos, kits e ambientes de desenvolvimento além de ser lider no mercado de soluções para WSN´s. O principal motivo por ter adotado o MICAz, plataforma oficial deste trabalho, se deve ao fato da disponibilidade de alguns kits de desenvolvimento cedidos gentilmente pelo co-orientador deste trabalho, Prof. Dr. Renato Mariz de Moraes. Este capítulo aborda cada um dos componentes da arquitetura do MICAz[57, 25] e o sistema operacional utilizado pelo MICAz. 2.2 2.2.1 MICAz Visão geral da Arquitetura A Figura 2.1 ilustra à esquerda a arquitetura do MICAZ, tecnicamente chamado de MPR2400[25], e à direita uma foto do sensor. 1 Sensores de pequenas dimensões projetados projetados para RSSF. 8 Figura 2.1: Arquitetura e foto do MICAz. A Tabela 2.1 sumariza os principais componentes do MICAz com base na Figura 2.1. Tabela 2.1: Componentes da Arquitetura do MICAz Item Antena Memória flash Light Emitting Diode (LED)´s CC2420 ATMEGA128L Conector de Expansão Descrição Comunicação ( 14 de onda) “data logger” dos dados coletados. É utilizada para armazenamento de parâmetros do software embarcado e para guardar uma sequência de dados que será posteriormente enviada à basestation. Dispositivo de uso geral que pode ser utilizado para sinalização ou alerta pela aplicação embarcada. Um rádio transceptor Direct Sequence Spread Spectrum (DSSS) que trabalha na faixa de 2.4 Ghz/ZigBee-ready, padrão Institute for Electrical and Electronics Engineers (IEEE) 802.15.4 e fabricado pela Texas Instruments[31]. Microcontrolador Complementary metal-oxidesemiconductor (CMOS) de 8 bits, baixo consumo, baseado na avançada tecnologia AVR Reduced Instruction Set Computer (RISC) fabricado pela ATMEL Corporation[24]. Conector de 51 pinos para interconexão e expansão produzido pela Hirose Electric Group[22] O conector de expansão possibilita a interceptação de qualquer pino do microcontrolador, tais como: Universal Synchronous Asynchronous Receiver Transmitter (USART)´s, Analog to Digital Converter (ADC)´s, pinos de uso geral, barramento I2C, LED´s, interrupções externas e fonte de energia. 9 Cada componente está conectado através de barramentos de comunicações. O rádio se comunica com o microcontrolador através de 12 pinos do barramento Serial Programming Interface (SPI) e a memória flash utiliza barramento SPI. O MICAz possui entrada para conexão externa de alimentação DC permitindo assim, que uma fonte de energia de maior capacidade seja também utilizada. A Figura 2.2 ilustra uma organização mais detalhada da arquitetura do MICAz. Figura 2.2: Arquitetura detalhada do MICAz. 2.2.2 Características A Tabela 2.2 expõe as principais características do MICAz: Tabela 2.2: Características - MICAz. Modelo Microcontrolador Transceptor de Rádio Memória flash Fonte de Energia Padrão MPR2400[25] Chip ATMEGA128L, frequência de clock 7.37Mhz, palavra de 8 bits, 128kb de memória de programa e 8kb de memória Random Access Memory (RAM). CC2420[31]. Chip AT45DB041 com capacidade de 512kb 2 baterias alcalinas do tipo AA[10] com capacidade de 2000 mA-h. 10 2.2.3 Microcontrolador - ATMEGA128L O microcontrolador ATMEGA128L[24] é uma arquitetura de 8 bits Havard2 modificada; baseado na avançada tecnologia AVR-RISC desenvolvida pela Atmel Corporation[47, 3]. O ATmega128 é “low-power”, tecnologia CMOS e executa uma instrução a cada ciclo de clock. Algumas características mais notáveis neste microcontrolador são: Memória flash 128kb; Memória EEPROM 4kb; Memória RAM estática 4kb; Joint Test Action Group (JTAG) Interface compatível com o padrão IEEE 1149.1; Timers 2 timers de 8 bits e 2 de 16 bits; Pulse Width Modulation (PWM) 6 canais com resolução programável de 2 a 16 Bits; ADC 8 canais com resolução de 10 Bits; USART 2 programáveis e independentes; SPI Interface serial “master” e “slave”; Modos de economia de energia 6 modos; “Idle”, “ADC Noise Reduction”, “Powersave”, “Power-down”, “Standby” e “Extended Standby”; Input/Output (IO)´s 51 pinos programáveis; Tensão de Operação 2.7 a 5.5 V. 2.2.4 Alimentação DC A MPR2400 foi projetada para operar com baterias alcalinas do tipo AA. Podendo utilizar qualquer combinação de baterias, desde que a tensão de alimentação esteja entre os limites de 2.7V a 3.6V DC. Possui um conector do tipo Molex[9] destinado à alimentação externa, desde que o nível de tensão não ultrapasse os 3.6V. A Figura 2.3 ilustra o circuito de alimentação da MPR2400. Quando a chave SW2 está na posição 1, o circuito é alimentado ou pelas baterias ou pela fonte de energia externa. Na posição 2 o circuito está desligado. Os capacitores eletrolíticos C1 e C2, mostrados na figura 2.3, têm a finalidade de filtrar espúrios de tensão provenientes de uma fonte de energia ruidosa. 2É uma arquitetura de computador que se distingue das outras por possuir duas memórias diferentes e independentes em termos de barramento e ligação ao processador. 11 Figura 2.3: Circuito de Alimentação DC do MICAz. 2.2.5 2.4 GHz IEEE 802.15.4 / ZigBee-ready RF Transceiver - CC2420 O CC22420[31] é um transceptor de 2.4Ghz compatível com o padrão IEEE 802.15.4 para aplicações de baixo consumo (“low-power”). O transceptor inclui um DSSS provendo uma taxa efetiva de comunicação de 250Kbps. Uma solução integrada e robusta para WSN´s na faixa de rádio frequência - “Industrial Scientific and Medical bands (ISM)”. A interface de comunicação do CC2420 é acessada via barramento SPI. As principais características do CC2420 são[31]: • Frequência de operação de 2.4Ghz; • Baixo consumo: (Recepção: 18.8mA, Transmissão:17.4 mA); • Tensão de alimentação entre 2.1V a 3.6V com regulador de tensão integrado; • Potência de Transmissão programável; • Poucos componentes são necessário para o funcionamento; • Suporte a Received Signal Strength Indication (RSSI) e Link Quality Indicator (LQI); • Criptografia Advanced Encryption Standard (AES) de 128 Bits; • Ferramentas de desenvolvimento disponíveis: SmartRF Studio[29] e SmartRF Protocol Packet Sniffer[30]. O valor do RSSI pode ser lido através de um registrador interno de 8 bits do CC2420 denominado RSSI.RSSI_VAL. A Figura 2.4 ilustra valores típicos para RSSI.RSSI_VAL em função da potência de entrada[31]. O LQI está relacionado quanto à caracterização da qualidade e potência do pacote recebido. O RSSI, descrito no parágrafo anterior, é utilizado pelo firmware da camada Media Access Control (MAC) para produzir o LQI. 12 Figura 2.4: Valores típicos para RSSI x potência de entrada. 2.2.6 Memória Flash (Data Logger) - AT45DB041 O AT45DB041D é uma memória flash com interface serial desenvolvida idealmente para uma variedade de aplicações, tais como: digitalização de voz e imagem, armazenamento de firmware´s e dados. Suporta a interface serial SPI com frequências acima de 66Mhz. Possui 4.325.376 bits de memória organizados em 2.048 páginas de 256/264 bytes cada. Adicionalmente possui buffers de RAM estática com 256/264 Bytes cada. Os buffers aumentam a velocidade de acesso porque possibilitam a recepção de dados enquanto a memória está sendo reprogramada[15]. As principais características desse dispositivo são: • Tensão de alimentação entre 2.5V a 3.6V; • Interface serial com 66 Mhz de clock; • Tamanho da página programável: 256/264 Bytes por página; • Opções flexíveis de apagar os dados; • Baixo consumo “low-power”: 7 mA (leitura), 25 µA (Standby); A Figura 2.5 expõe a configuração dos pinos da memória flash AT45DB041 e a Tabela 2.3 ilustra a função de cada pino respectivamente[15]. Figura 2.5: Pinagem da memória AT45DB041. 13 Tabela 2.3: Função de cada pino da memória AT45DB041. Pino CS SCK SI SO WP RESET VCC GND 2.2.7 Função Chip Select. Um nível baixo nesse pino põe o dispositivo em operação. Serial clock. Entrada de relógio. Serial input. Entrada de dados. Serial output. Saída de dados. Proteção contra escrita. Um nível baixo nesse pino desabilita a escrita de dados na memória. Um nível baixo nesse pino põe o dispositivo em estado “idle”. Alimentação DC. Terra em relação a VCC. Conversor DC-DC - MAX1678 O MAX1678 é um conversor DC-DC “buck” desenvolvido para dispositivos alimentados por baterias alcalinas, NiMH - Níquel Metal Hidreto e NiCd - Níquel-Cádmio ou células de lítio. A tensão de saída vem pré-configurada para 3.3V ou poderá ser ajustada entre 2.0V a 5.5V utilizando somente 2 resistores. O dispositivo alcança eficiência acima de 90% e possui um modo de “shutdown” com apenas 2µA de consumo[45]. A Figura 2.6 mostra um circuito típico de operação do conversor DC-DC MAX1678. Figura 2.6: Circuito típico de utilização do MAX1678. 2.2.8 Mote Interface Board - MIB520 A MIB520 é a placa utilizada para conectividade entre o MICAz e o PC. A Mote Interface Board (MIB520), apresentada na figura 2.7, através da porta UNIVERSAL SERIAL BUS (USB) do PC este dispositivo possibilita conectividade tanto para programação do firmware quanto para comunicação com o sensor[25]. 14 Figura 2.7: Vista superior da MIB520. A chave SW1, quando pressionada, reinicializa o sistema embarcado que está instalado no Mote. O conector Hirose[22] é a interface de conexão entre a MIB520 e a MPR2400. Os LEDs são apenas sinalizadores visuais da placa. A placa de interface com o PC é equipada com um chip FT2232C, fabricado pela Future Technology Devices International Ltd.[44]. Quando conectado ao PC, esse chip cria duas portas de comunicação seriais independentes. A primeira porta é utilizada exclusivamente para gravação In System Programming (ISP) enquanto que a segunda, pode ou não ser utilizada para comunicação serial com o MICAz através de protocolo RS232. Por exemplo: considere a situação na qual a primeira porta criada foi a COM5 e a segunda foi a COM6, então as funções das portas serão as seguintes: COM5: ISP - Gravação do firmware; COM6: Comunicação serial com o MICAz. O FT2232C é a terceira geração da família dos populares chips USB/USART da FTDI[44]. 2.2.9 Placa de Aquisição de dados - MDA100CB A MDA100CB (Figura 2.8)[17] é uma placa de extensão para o MICAz que possui um sensor de luz (fotoresistor), um sensor de temperatura de precisão (termistor 3 ) e uma área de prototipação que fornece acesso as duas portas seriais, barramento I2C, portas de IO, todos os oito canais ADC além de 45 ilhas desconectadas para uso geral. Figura 2.8: Foto da placa de aquisição de dados - MDA100CB. A Figura 2.9 ilustra a disposição da matriz de acesso da placa de aquisição de dados e prototipação MDA100CB. 3 Condutor sensível à temperatura. 15 Figura 2.9: Matriz MDA100CB. 2.3 2.3.1 TinyOS Introdução TinyOS é um Sistema Operacional (SO) Open Source desenvolvido inicialmente pela Universidade de Berkeley para aplicações de baixo consumo, WSNs, redes de sensores atuadores e robótica[18, 4]. Segundo BORGES; CARVALHO; CRUZ, os SO´s atuais que estão sendo desenvolvidos pela comunidade científica são, o TinyOs da Universidade de Berkeley[4], Contiki[12] do Instituto de Ciências de computação da Suécia, MantisOs[8] da Universidade do Colorado, SOS da Universidade de Califórnia, Yatos da Universidade de Minas Gerais, EYES da Universidade de Twente e o Nano-QPLUS da Divisão de Informática, CNU, Daejeon, Coréia do Sul. Ainda segundo BORGES; CARVALHO; CRUZ, o TinyOS tornou-se mais confiável para aplicações finais, mais portável e já é compatível com as plataformas eyesIFXv2, intelmote2, mica2, micaZ, telosb em seu novo versionamento. O TinyOs proporciona a escrita rápida de aplicações para RSSF através de: • Um modelo de programação orientado a componentes reutilizáveis com alto nível de abstração; • Modelo de execução concorrente que define como os componentes interagem entre si; • Uma vasta Application Programming Interfaces (API) consistindo de uma biblioteca para escrita de novas aplicações e serviços. O modelo de execução preemptivo com gerenciamento de tarefas executadas ao mesmo tempo enquanto o sistema dispõe de pouca memória RAM. As tarefas são escalonadas e divididas em fases. Esta seção tem a finalidade de prover uma breve noção do sistema operacional TinyOS bem como a utilização dos componentes necessários para utilização na Placa de Medição 16 de Consumo. Grande parte dela será baseada no livro TinyOS Programming[40] de autoria de Philip Levis e David Gay, amplamente utilizado pela comunidade acadêmica como o melhor ponto de referência para a iniciação da programação para RSSF, e o restante nas TinyOS Enhancement Proposalss (TEPs) e tutoriais disponíveis no site do TinyOS[4]. 2.3.2 Estrutura de Programação - nesC Programas que utilizam o sistema operacional TinyOS são escritos na linguagem nesC[6] e são construídos a partir de componentes interconectados wireds. Para ilustrar a diferença; considere um programa, que pisca alternadamente um LED durante um período de 500 milisegundos, escrito em C e o código equivalente escrito em nesC. O Código 2.1, corresponde hipoteticamente ao programa escrito em linguagem C. Código 2.1: BlinkLed.c 1 2 3 4 5 6 7 8 # i n c l u d e " mote . h " i n t main ( ) { mote_init () ; while ( 1 ) { led0_toggle () ; delay_ms (500) ; } } O programa equivalente em nesC possui dois componentes, configuração e módulo. Configurações em nesC realizam a interconexão wired da aplicação e instanciam outros componentes de alto nível disponíveis na árvore do TinyOS. Módulos possuem implementações de código e interfaces. Os Códigos 2.2 e 2.3 ilustram a configuração e o módulo da aplicação respectivamente[40]. Código 2.2: BlinkLedAppC.nc 1 2 3 4 5 6 7 8 9 10 11 12 13 14 c o n f i g u r a t i o n BlinkLedAppC {} implementation { /∗ ∗ Componentes u t i l i z a d o s p e l a a p l i c a ç ã o ∗/ components MainC , LedsC , BlinkLedC ; components new T i m e r M i l l i C ( ) a s T e m p o r i z a d o r ; /∗ ∗ Wired i n t e r c o n e x ã o d a s i n t e r f a c e s ∗/ BlinkLedC . Boot −>MainC ; BlinkLedC . Leds −>LedsC ; BlinkLedC . T e m p o r i z a d o r −>T e m p o r i z a d o r ; } Código 2.3: BlinkLedC.nc 1 2 3 4 5 6 7 module BlinkLedC { uses { i n t e r f a c e Boot ; / / Contém o e v e n t o de i n i c i a l i z a ç ã o do s i s t e m a i n t e r f a c e Leds ; / / I n t e r f a c e que i m p l e m e n t a o s t r ê s LEDs i n t e r f a c e Timer < T M i l l i > a s T e m p o r i z a d o r ; } } 17 8 9 10 11 12 13 14 15 16 17 implementation { e v e n t v o i d Boot . b o o t e d ( ) { c a l l T e m p o r i z a d o r . s t a r t P e r i o d i c ( 5 0 0 ) ; / / T i m e r d i s p a r a a cada 500 ms } event void Temporizador . f i r e d ( ) { c a l l Leds . l e d 0 T o g g l e ( ) ; / / Muda o e s t a d o do Led } } A rotina BlinkLedAppC utiliza diversos componentes e realiza a conexão entre eles conforme podemos observar na Figura 2.10 que ilustra o grafo da aplicação para piscar o Led0 do MICAz. Figura 2.10: Grafo da Aplicação BlinkLed. Os Códigos [2.1],[2.2] e [2.3], mostram a diferença entre nesC e C. Programas escritos em C são compostos de funções e programas escritos em nesC, são desenvolvidos a partir de um conjunto de componentes que implementam serviços particulares. Funções em C tipicamente interagem diretamente, enquanto que componentes nesC são especificados por interfaces. O módulo que utiliza a interface necessariamente precisa implementar os eventos e fazer chamadas call dos comandos quando necessário. Interfaces em nesC são semelhantes às interfaces da linguagem Java: um “contrato” para o desenvolvimento de uma classe. A Figura 2.11 mostra o fluxograma da aplicação BlinkLedAppC. 18 Figura 2.11: Fluxograma da aplicação BlinkLedAppC. 2.3.3 Assinatura de Componentes Um programa escrito em nesC é uma coleção de componentes. Todo componente tem o seu respectivo código fonte. Por exemplo, LedsC.nc contém o código nesC para o componente LedsC, enquanto que o código fonte para o componente BlinkLedC pode ser encontrado no arquivo BlinkLedC.nc(Código 2.3). Há dois tipos de componentes: Módulos (Module) e Configurações (Configuration), os quais são utilizados para interconectar uma combinação de serviços ou abstrações. Os dois tipos de componentes diferem na sua implementação conforme podemos observar através das respectivas assinaturas em 2.4 e 2.5. Código 2.4: configAppC.nc 1 2 3 4 5 6 c o n f i g u r a t i o n configAppC { } implementation { } Código 2.5: configC.nc 1 2 3 4 5 6 module BlinkLedC { } implementation { } A Implementação de módulos em nesC, consiste de um código fonte que aparenta um programa em linguagem C. Configurações consiste de código de interconexão entre componentes[40]. 19 2.3.4 Componente Essenciais para Uso na Plataforma de Medição 2.3.4.1 Componente MicaBusC Para trabalhar com portas de entrada e saída, conversores ADC e as interrupções externas do MICAz devemos utilizar o componente MicaBusC que provê acesso aos pinos através das seguintes interfaces: Adc0 interface MicaBusAdc as Adc0 Adc1 interface MicaBusAdc as Adc1 Adc2 interface MicaBusAdc as Adc2 Adc3 interface MicaBusAdc as Adc3 Adc4 interface MicaBusAdc as Adc4 Adc5 interface MicaBusAdc as Adc5 Adc6 interface MicaBusAdc as Adc6 Adc7 interface MicaBusAdc as Adc7 Int0 interface GeneralIO as Int0 Int1 interface GeneralIO as Int1 Int2 interface GeneralIO as Int2 Int3 interface GeneralIO as Int3 PW0 interface GeneralIO as PW0 PW1 interface GeneralIO as PW1 PW2 interface GeneralIO as PW2 PW3 interface GeneralIO as PW3 PW4 interface GeneralIO as PW4 PW5 interface GeneralIO as PW5 PW6 interface GeneralIO as PW6 PW7 interface GeneralIO as PW7 Os Códigos 2.6 e 2.7 mostram um exemplo de utilização da interface GeneralIO (acesso a porta digital de entrada e saída). Deve-se observar que somente na implementação do componente configuração (configuration) é que se atribui o endereço físico do pino (PW2) do microcontrolador. A programação no módulo é desempenhada considerando uma interface GeneralIO em alto nível de abstração. 20 Código 2.6: ioportAppC.nc 1 2 3 4 5 6 7 8 9 co nf ig ura ti on ioportAppC { } implementation { components MainC , MicaBusC , i o p o r t C ; components new T i m e r M i l l i C ( ) a s T e m p o r i z a d o r ; I 2 C T e s t i n g C . Boot −>MainC . Boot ; I 2 C T e s t i n g C . wakeUpPIC−>MicaBusC . PW2 ; i o p o r t C . T e m p o r i z a d o r −>T e m p o r i z a d o r ; } Código 2.7: ioportC.nc 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 module i o p o r t C { uses { i n t e r f a c e Boot ; i n t e r f a c e Timer < T M i l l i > a s T e m p o r i z a d o r ; i n t e r f a c e GeneralIO as portaIO ; } } implementation { e v e n t v o i d Boot . b o o t e d ( ) { c a l l p o r t a I O . makeOutput ( ) ; / / C o n f i g u r a o p i n o como s a í d a c a l l p o r t a I O . c l r ( ) ; / / Põe o p i n o em n í v e l b a i x o c a l l T e m p o r i z a d o r . s t a r t P e r i o d i c ( 5 0 0 0 ) ; / / T e m p o r i z a d o r a cada 5 segundos } event void Temporizador . f i r e d ( ) { c a l l p o r t a I O . t o g g l e ( ) ; / / A l t e r n a o n í v e l da p o r t a } } 2.3.4.2 Componente Atm128I2CMasterC O barramento I2C foi desenvolvido pela Philips em meados dos anos 80 para possibilitar fácil comunicação entre componentes localizados na mesma Printed Circuit Board (PCB). A Philips Semiconductors migrou para NXP em 2006[53]. O barramento I2C apresenta três modalidades com diferente taxas de comunicação[53]: Standard 100Kbps; Fast mode 400Kbps; Fast mode plus 3.4Mbps. Algumas características significativas neste tipo de barramento são: • Somente duas linhas de comunicação são requisitos; • Relação master/slave entre todos os dispositivos que fazem parte do barramento; • Cada dispositivo conectado possui um único endereço; • Detecta colisão. 21 O componente Atm128I2CMasterC, que implementa as duas interfaces ilustradas na Figura 2.12, é destinado a desempenhar comunicação I2C entre MICAz e outros dispositivos. É importante ressaltar que o projeto desse componente foi realizado de modo que o MICAz seja sempre e unicamente master enquanto que o restante dos dispositivos conectados ao barramento devem ser estritamente slaves. Este componente admite somente a modalidade Standard (100Kbps de taxa de comunicação)[4]. Figura 2.12: Conexões do módulo Atm128I2CMasterC. Fonte: [4] Os Códigos 2.8 e 2.9 demonstram a utilização do componente Atm128I2CMasterC. O programa escreve e ler no barramento I2C a cada 3 segundos. Código 2.8: I2CBusAppC.nc 1 2 3 4 5 6 7 8 9 10 11 12 13 c o n f i g u r a t i o n I2CBusAppC { } implementation { components MainC , I2CBusC ; components new T i m e r M i l l i C ( ) a s T e m p o r i z a d o r ; components new Atm128I2CMasterC ( ) ; I2CBusC . Boot −>MainC . Boot ; I2CBusC . T e m p o r i z a d o r −>T e m p o r i z a d o r ; /∗ ∗ I2C W i r i n g ∗/ I2CBusC . R e s o u r c e −>Atm128I2CMasterC ; I2CBusC . I 2 C P a c k e t −>Atm128I2CMasterC ; } Código 2.9: I2CBusC.nc 1 2 3 4 5 6 7 8 9 10 11 module I2CBusC { uses { i n t e r f a c e Boot ; /∗ ∗ Timers ∗/ i n t e r f a c e Timer < T M i l l i > a s T e m p o r i z a d o r ; /∗ ∗ P r o t o c o l o I2C ∗/ i n t e r f a c e I 2 C P a c k e t < TI2CBasicAddr > ; 22 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 i n t e r f a c e Resource ; } } implementation { uint8_t txData [ 8 ] ; u i n t 8 _ t rxData [ 8 ] ; enum { SLAVE_ADDR = 0 x60 / / E n d e r e ç o do d i s p o s i t i v o s l a v e no b a r r a m e n t o I2C }; event call } event call } / / 3 segundos void Temporizador . f i r e d ( ) { Resource . r e q u e s t ( ) ; event void Resource . g r a n t e d ( ) { memcpy ( t x D a t a , " t e s t e " , s t r l e n ( " t e s t e " ) ) ; c a l l I 2 C P a c k e t . w r i t e ( I2C_START | I2C_STOP , SLAVE_ADDR, s i z e o f ( r x D a t a ) , &t x D a t a [ 0 ] ) ; } 32 33 34 async e v e n t void I2CPacket . readDone ( e r r o r _ t e r r o r , u i n t 1 6 _ t addr , uint8_t length , uint8_t ∗ data ) { c a l l Resource . r e l e a s e ( ) ; } 35 36 37 38 async e v e n t void I2CPacket . writeDone ( e r r o r _ t e r r o r , u i n t 1 6 _ t addr , uint8_t length , uint8_t ∗ data ) { i f ( e r r o r ==SUCCESS ) { c a l l I 2 C P a c k e t . r e a d ( I2C_START | I2C_STOP , SLAVE_ADDR, s i z e o f ( r x D a t a ) , &r x D a t a [ 0 ] ) ; } } 39 40 41 42 43 v o i d Boot . b o o t e d ( ) { Temporizador . s t a r t P e r i o d i c (3000) ; } 2.3.5 Protocolos de Roteamento Roteamento é o processo de encontrar um caminho de uma origem até um destino. Redes de Sensores sem Fio (RSSF) são constituídas de uma árvore de nós densamente distribuídos que operam de forma colaborativa. Cada dispositivo é dotado de capacidade computacional (microcontrolador), sensores, transceptor de rádio e fonte de energia. O protocolo de roteamento é um algorítmo responsável pela busca, descoberta e manutenção das rotas entre um nó de origem e o nó de destino. O projeto de um algorítmo de roteamento além de ser complexo, deve considerar a rota mais curta entre a origem e o destino. O protocolo de roteamento pode ser desenvolvido em função dos seguintes fatores: • complexidade da rede; • modelo de mobilidade; • eficiência energética; 23 • gerenciamento de memória. 2.3.5.1 Protocolo Collection O protocolo Collection[20] é um serviço que soma esforços para entregar pacotes multi-hop em uma RSSF[20]. CollectionC é o componente responsável pelo funcionamento do protocolo Collection. O perfil do nó na RSSF é determinado pelo uso seletivo das interfaces disponíveis neste componente. O Algoritmo 2.10 ilustra a implementação e as interfaces disponíveis nesse protocolo. As informações na rota final são exibidas para os observadores da RSSF. Considere a Figura 2.13 que é um caso típico de uma WSN e as observações listadas abaixo: 1. Os nós A,B,C,D,E e F são responsáveis pelo sensoriamento da RSSF; 2. O nó G é a base-station, gateway ou node-sink; 3. Os círculos são apenas ilustrações do alcance do rádio dos respectivo nó central; 4. O nó G está conectado a uma placa de interface denominada MPR2400CB[25, 57] ou Mote Interface Board (MIB); 5. A rota mais curta para que um pacote cuja origem é o nó A e o destino o nó G é: A⇒B⇒D⇒E ⇒F ⇒G Figura 2.13: Cenário Típico com 7 sensores CollectionC é o componente responsável pelo funcionamento do protocolo Collection. O perfil do nó na RSSF é determinado pelo uso seletivo das interfaces disponíveis por este componente. O Algoritmo 2.10 ilustra a implementação e as interfaces disponíveis do protocolo. Código 2.10: Componente CollectionC 1 configuration 2 provides { 3 interface 4 interface 5 interface 6 interface CollectionC { StdControl ; Send [ u i n t 8 _ t c l i e n t ] ; Receive [ c o l l e c t i o n _ i d _ t id ] ; R e c e i v e a s Snoop [ c o l l e c t i o n _ i d _ t ] ; 24 7 interface I n t e r c e p t [ c o l l e c t i o n _ i d _ t id ] ; 8 9 interface Packet ; 10 interface CollectionPacket ; 11 interface CtpPacket ; 12 13 interface CtpInfo ; 14 interface CtpCongestion ; 15 interface RootControl ; 16 } 17 18 uses { 19 interface CollectionId [ uint8_t client ]; 20 interface CollectionDebug ; 21 } 22 } 23 24 i m p l e m e n t a t i o n { 25 components CtpP ; 26 27 S t d C o n t r o l = CtpP ; 28 Send = CtpP ; 29 R e c e i v e = CtpP . R e c e i v e ; 30 Snoop = CtpP . Snoop ; 31 I n t e r c e p t = CtpP ; 32 33 P a c k e t = CtpP ; 34 C o l l e c t i o n P a c k e t = CtpP ; 35 C t p P a c k e t = CtpP ; 36 37 C t p I n f o = CtpP ; 38 C t p C o n g e s t i o n = CtpP ; 39 R o o t C o n t r o l = CtpP ; 40 41 C o l l e c t i o n I d = CtpP ; 42 C o l l e c t i o n D e b u g = CtpP ; 43 } A Tabela 2.4 relaciona as principais interfaces do serviço Collection e as respectivas funções. Tabela 2.4: Principais Interfaces do componente CollectionC Interface StdControl Send Receive Snoop Intercept RootControl Função Inicialização e parada do serviço Collection. Obrigatória para todos os nós que façam parte da coleção. Envio de pacotes pelos producers. Recepção de pacotes pelos consumers. Escuta dos pacotes sem interferir na coleção. Responsável pelo encaminhamento multi-hop dos pacotes. Implementa comandos que definem se o nó é ou não uma rota final da coleção. Obrigatório para os consumers. Os nós no protocolo Collection desempenham tarefas específicas. Cada perfil, listado 25 na Tabela 2.5, corresponde a um papel diferente ou participação na RSSF. Tabela 2.5: Tipos de Perfis no protocolo Collection Perfil producer interface Send snooper in-network processor Snoop Intercept consumer Receive Descrição Coletam dados dos sensores e enviam para a rota final da rede. Escutam o tráfego de dados na rede. Interceptam os pacotes em trânsito na rede e os encaminham para o próximo salto (forward). O processo de interceptação e encaminhamento também permite a modificação do pacote. (update) Recebem os dados produzidos pela coleção de sensores distribuídos na rede. Nesta seção desenvolveremos uma aplicação prática (veja Figura 2.14) com os seguintes requisitos: 1. Para fins experimentais todos os nós tiveram a potência do rádio reduzidas para PdBm = −25dBm. A potência de -25dBm é equivalente a PW = 3.162 × 10−6W ou 3.16µW . O consumo do rádio reduz-se para 8.5mA e isto facilita a observação do comportamento do protocolo em pequenas distâncias; 2. Quatro nós híbridos, numerados de 1 a 4, serão distribuídos: (producers+in-network processor). A finalidade desses nós consiste na leitura dos sensores (temperatura e de luminosidade), envio dos dados para o consumer e encaminhamento multi-hop de pacotes - (forward); 3. O nó 5 desempenhará o papel de consumer; 4. A Figura 2.14 ilustra o cenário dessa experiência prática; 5. Dois sistemas embarcados diferentes são necessários; um para a árvore da rede (nós de 1 a 4) e outro para o nó 5 (gateway). Figura 2.14: Aplicação Prática: Proposta de Cenário 26 O código fonte referente à aplicação prática dessa seção está disponível no Apêndice V desse documento. 2.3.5.2 Protocolo de Roteamento - Tymo DYMO[7, 58] é um protocolo de roteamento reativo4 e multi-hop desenvolvido para Mobile Ad-hoc Networks (MANET) e baseado no mecanismo de funcionamento do Ad hoc On-Demand Distance Vector Routing (AODV)[48][7]. A especificação do DYMO pelo The Internet Engineering Task Force (IETF) ainda está em fase de desenvolvimento. Ilustraremos, nessa seção, os princípios básicos da operação do protocolo TYMO[58]. A Figura 2.15 ilustra a representação de uma RSSF onde o nó A deseja enviar um pacote para o nó H. As linhas representam conexões dos nós com os seus vizinhos. Figura 2.15: Exemplo: A envia um pacote para H. Conforme THOUVENIN, a fim de evitar contradições e incoerências verbais, dividiremos o processo de comunicação do protocolo em duas camadas segundo a Tabela 2.6. Tabela 2.6: Camadas do protocolo TYMO. Camada Link Layer Network Layer Descrição Os pacotes são trocados entre os emissores e receptores (vizinhos). Os pacotes são enviados do emissor para o receptor. O TYMO[58] é a implementação do DYMO em TinyOS 2.x. Este protocolo é abordado detalhadamente no documento de dissertação de mestrado de THOUVENIN. Um protocolo reativo não armazena informações da topologia da rede. Os nós processam informações sobre as rotas somente quando necessário. O resultado disso é um menor overhead na troca de informações de rotas entre os nós vizinhos e redução do tráfego economizando banda e energia. As características principais do DYMO são a descoberta e manutenção de rotas. Estas atividades são desempenhadas através da troca de mensagens: RREQ, RREP e RERR. O DYMO também possui mecanismos para evitar a utilização de informações de roteamento antigas e a formação de loops. A operação básica consiste no envio de mensagens de requisição de rota Route Request (RREQ); que é enviada quando um nó necessita obter o caminho entre a origem e o destino 4 Adaptativo quanto à mudanças na topologia da rede e descoberta de rotas sob demanda. 27 do pacote. Esta mensagem percorre toda a rede até o destino conforme a Figura 2.16[19, 58, 7]. Figura 2.16: Requisição de rota entre A e H. Cada nó que recebe uma RREQ, guarda a rota para a origem e reencaminha o pacote de controle para o destino. O destino responde com uma mensagem de resposta de rota - Reply Route (RREP) quando o pacote da origem encontra o nó de destino, conforme Figura 2.17. Figura 2.17: RREP é enviada pela rota mais curta entre A e H. Uma mensagem RREQ é bastante similar às mensagens RREP. A diferença reside no fato das mensagens RREP serem unicasts enquanto que RREQ são broadcasts. Quando um nó recebe uma RREQ ou RREP, as informações sobre a rota estão numa tabela (cache) que poderá ser utilizada posteriormente para fins de comunicação entre a origem e o destino sem a necessidade de envios de mensagens RREQ. As rotas são eliminadas quando não estão sendo utilizados por um período de tempo. Uma mensagem Route Error (RERR) é disseminada se um nó tentar encaminhar um pacote através de uma rota que foi perdida. A Figura 2.18 ilustra o processo da mensagem RERR. Nesta seção desenvolveremos uma aplicação prática (veja Figura 2.19) com os seguintes requisitos: 1. Para fins experimentais todos os nós tiveram a potência do rádio reduzidas para PdBm = −25dBm. A potência de -25dBm é equivalente a PW = 3.162 × 10−6W ou 3.16µW . O consumo do rádio reduz de 17,4mA para 8.5mA e, com isso, facilita a observação do comportamento do protocolo em pequenas distâncias; 2. Quatro nós (1,2,3 e 4) serão distribuídos com a finalidade desses de leitura dos sensores (temperatura e de luminosidade), envio dos dados para a base-station e encaminhamento multi-hop de pacotes - (forward); 28 Figura 2.18: O nó G deslocou-se para outra posição e o nó F não tem mais rota para alcançar G e H. B e C não encaminha RERR porquê C conhece o caminho para D. 3. O nó 36 desempenhará o papel de base-station; 4. A Figura 2.19 ilustra o cenário dessa experiência prática. 5. O código fonte do exemplo prático está disponível no Apêndice VI deste documento. Figura 2.19: Aplicação Prática: Proposta de Cenário O código fonte referente à aplicação prática dessa seção está disponível no Apêndice 8 desse documento. 2.4 Conclusão Foram abordados cada um dos componentes do MICAz, através de uma visão arquitetural detalhada de cada um de seus componentes e suas características. Em geral, desenvolvedores de sistemas embarcados utilizam a linguagem C. O TinyOS pode se mostrar, no início, um pouco difícil e diferente devido às difereças do C procedural e o nesC orientado a componentes. Todavia, com o passar o tempo, o projetista de sistemas embarcados para RSSF se acostuma com o paradigma da programação orientada a componentes e passa inclusive a admirar o vantajoso conjunto de APIs, níveis de abstrações e a vasta quantidade de componentes reutilizáveis que executam tarefas complexas. O desenvolvimento de subrotinas para sistemas embarcados onde o tempo é crítico é uma tarefa complexa. Sabe disso quem desenvolveu por exemplo: uma API para controle e acesso SPI de uma câmera CCD ou até mesmo quem precisou desenvolver um conjunto de 29 subrotinas de acesso ao barramento I2C. Tarefas complexas demandam tempo e quando se tem componentes que implementam estas tarefas com nível de abstração alto o tempo de desenvolvimento reduz-se significativamente. TinyOS é o Sistema Operacional para RSSF mais utilizado na comunidade acadêmica. Apresenta confiabilidade e o seu projeto foi desempenhado visando dispositivos com pouca memória, severas restrições de energia, baixo consumo e WSNs. Dois protocolos de roteamento, Collection e Tymo foram explicados resumidamente através de experimentos práticos com os seus respectivos códigos fonte. Capítulo 3 Estado da Arte 3.1 Introdução Nesta seção serão mencionados alguns trabalhos relacionados com estratégias de medição de consumo de energia em RSSF. Vários trabalhos serão referenciados neste texto, mas três destes serão discutidos em detalhes pois são fortemente relacionados ao tema desta dissertação de mestrado - Técnicas de Medições de Consumo de Energia em RSSF. O primeiro trabalho[32], demonstra o desenvolvimento de uma placa de medição de consumo denominada “Scalable Power Observation Tool - SPOT”, desenvolvido em 2007 por uma equipe do Departamento de Ciências da Computação da Universidade da Califórnia, Berkeley. O segundo trabalho[61], compreende o desenvolvimento da ferramenta de monitoramento de consumo “A Runtime Energy Monitoring System for Wireless Sensor Networks”, elaborado em 2008 pelo Instituto Tecnológico de Graz, Áustria. O terceiro trabalho[36], denominado de “Energy Measurements for MicaZ Node”, ilustra uma série de medições realizadas na MPR2400[25] obtidas a partir de instrumentação eletrônica e elaborados em 2006 por um grupo da Universidade de Kaiserslautern, Alemanha. 3.2 3.2.1 Micro Power Meter for Energy Monitoring of Wireless Sensor Networks at Scale Visão Geral Eficiência energética é um problema a ser solucionado nas pesquisas em WSN´s. A lacuna principal para avaliar eficientemente o consumo de energia de um nodo de uma RSSF é um método que viabilize a observação prática da realidade. Segundo JIANG et al., aproximações de simuladores baseadas no uso da energia nodal, derivada de estimativas a partir do duty cycle e taxas de comunicação não são capazes de capturar precisamente o comportamento do consumo em função do tempo (power profile). Os simuladores atuais extrapolam valores, generalizam características importantes e produzem dados incoerentes. O trabalho de JIANG et al. sugere a obtenção de medidas in situ a fim de corrigir modelos de simuladores caracterizando variâncias e validando generalizações. 31 A Figura 3.1 mostra o comportamento do consumo, durante 4 segundos, de uma típica aplicação para RSSF. Figura 3.1: Comportamento do consumo em função do tempo durante 4 segundos. Observando a Figura 3.1, nota-se longos períodos de baixo consumo pontuados por pulsos discretos de alta corrente. Isto acontece porque na maior parte do tempo o dispositivo encontra-se no estado sleep, só entrando em atividade (estado ativo) quando é necessário efetuar alguma tarefa de sensoriamento. RSSF´s trabalham com um duty cycle típico de 0.1% a 1%. Um sistema de medição de consumo deve ter uma faixa dinâmica que exceda três ordens de magnitude para capturar suficientemente a corrente no sleep mode com precisão. A Figura 3.2 mostra o detalhe de uma transição do modo sleep para o modo ativo com uma duração de 20 milisegundos. Observa-se que o nodo não drena uma corrente constante durante este período. Há dois transitórios nos últimos 10 microsegundos e quatro diferentes níveis e oscilações. O consumo de energia total é a soma dos consumos de cada um dos componentes que fazem parte do nodo. Esta abordagem sugere que taxas de amostragem da ordem de Khz ou Mhz podem ser necessárias para viabilizar a captura dessas características transitórias. Figura 3.2: Comportamento do consumo em função do tempo durante curto período. O sistema de medição deve ser minimamente invasivo, ou seja, deve-se evitar o máximo possível a influir no sistema que está se realizando as aferições. Finalmente, medições in situ têm como requisitos dispositivos de pequeno tamanho e baixo custo. A solução desenvolvida é mostrada na Figura 3.3. 32 Figura 3.3: O “Scalable Power Observation Tool -SPOT”, consiste de um resistor shunt, amplificador, conversor de voltagem para frequência e dois contadores. Este sistema possibilita a medição da potência e energial nodal com uma faixa dinâmica excedendo 10000:1 e uma resolução temporal da ordem de microsegundos. O Scalable Power Observation Tool (SPOT) acumula as medições de corrente, possui um mecanismo de calibração e utiliza a interface I2C para comunicação com o nodo da RSSF. 3.2.2 Formulação do Problema Esta seção apresenta os requisitos básicos do SPOT com ênfase na faixa dinâmica, taxa de amostragem, pertubação externa e sua fácil integração. Uma RSSF pode exibir uma variedade de diferentes “profiles”1 que dependem da finalidade e da aplicação firmware. Por exemplo: uma simples aplicação de sensoriamento e armazenamento poderá ter o comportamento exibido na Figura 3.1. Em outro cenário, uma outra aplicação poderá coletar e gravar dados a cada 5 minutos e executar um “upload”2 apenas uma vez por dia. O “profile” - comportamento do consumo em função do tempo - dessa aplicação é diferente do mostrado na Figura 3.1. O SPOT é utilizado como um dispositivo de medição independente do perfil de consumo da aplicação. Isto implica que o sistema necessida cobrir toda a densidade espectral do consumo. Sensores de WSN são aplicações pulsantes. A largura desses pulsos ou ciclo de trabalho ativo devem ser considerados para definir a taxa de amostragem do dispositivo de medição. Se a duração de um pulso for mais curta que o período de amostragem “sample”, os dados serão perdidos e a cobertura espectral estará comprometida. O dispositivo de medição deve atender o critério de Nyquist. Na Figura 3.2 temos uma janela de aproximadamente 20 milisegundos. A densidade espectral de potência exibe a energia através de todo espectro. É necessário limitar o sinal com um filtro passa baixa e a frequência de corte desse filtro deve ser a mais alta frequência presente na amostra de pulso ativo da Figura 3.2. A frequência de corte do exemplo é por volta de 20Khz e isto implica numa taxa mínima de amostragem “sample rate” de 20Khz × 2 = 40Khz, desta forma atendendo o 1 Perfil do consumo da aplicação. para a “base-station”. 2 Enviá-los 33 critério de Nyquist. O dispositivo de monitoramento de energia não deve influenciar no consumo do mote e isto implica que o mecanismo de medição deve ser alimentado por uma fonte de energia externa (separada do mote). Uma das características principais do projeto SPOT é que cada nodo numa RSSF pode ser equipado com um medidor de consumo. Isto sugere que o dispositivo necessita ser de fácil integração e também deve ter um custo irrisório comparado ao preço de um mote. 3.2.3 Arquitetura Utilizada Nesta seção é apresentada a arquitetura do SPOT e algumas características. A arquitetura consiste de quatro estágios: sensoriamento, condicionamento de sinal, digitalização e saída de energia (Figura 3.4). Figura 3.4: SPOT - Arquitetura. O estágio de sensoriamento compreende um resistor “shunt” colocado em série com o mote, convertendo corrente para tensão. Esta voltagem é proporcional ao consumo de potência do mote. No estágio de condicionamento, um amplificador diferencial e um filtro passa baixa é utilizado para amplificar e limitar a banda do sinal respectivamente. O estágio de digitalização compreende um conversor Voltage-to-Frequency (V/F), que produz na saída uma onda quadrada proporcional à tensão de entrada. No estágio de saída de energia, os pulsos de procedência do conversor V/F são somados (integrados) em um contador com a finalidade de obter a medição de energia. Um outro contador também é utilizado para armazenar a base de tempo da onda quadrada. Os valores dos contadores são obtidos pelo mote através do barramento I2C. O sensoriamento é o primeiro estágio assim como na maioria dos sistemas de captura e conversão de sinais. Particularmente no SPOT, a grandeza obtida é a potência que é o produto da tensão e corrente. A tensão foi considerada fixa no projeto do SPOT. Um resistor “shunt”3 foi colocado em série entre o mote e a fonte de energia. A queda de tensão através desse resistor é proporcional a corrente a ser medida. No projeto do SPOT o valor dessa resistência foi de 1Ω. Assumindo que a máxima corrente no mote é de 40mA então a máxima queda de tensão no “shunt” é de 40mV. 3 Resistência de muito pequeno valor. 34 Amplificadores diferenciais produzem tensões de “offset”. Isto é uma característica comum em amplificadores e a causa se deve ao desbalanceamento dos componentes internos. Supondo que a diferença entre as entradas do amplificador seja zero, mesmo assim haverá uma tensão residual presente na saída do amplificador; esta tensão é denominada “offset”. Para compensar este problema foi incluído no SPOT um mecanismo de calibração. Os valores são armazenados no mote e utilizados na curva de calibração a fim de compensar o “offset”. A amplificação de pequenos sinais é crítica porque qualquer ruído é significante na amostra do sinal. Foram colocados múltiplos estágios RC para diferentes frequências. Também foi descoberto que o oscilador, presente no estágio digital, introduzia um ruído no amplificador. Este problema foi solucionado isolando a parte analógica da digital através de anéis de terra distintos. Isto pode ser observado através da Figura 3.3. A corrente drenada por um mote situa-se na faixa de 20µA a 40mA. Utilizando um resistor de 1Ω, a mínima voltagem para capturar é 20µA × 1 = 20µV . Isto é um valor muito baixo para processamento de sinais. Por isso que esse sinal é amplificado através de um amplificador diferencial ilustrado na Figura 3.4. O ganho do amplificador utilizado no SPOT foi de 82.5; A digitalização é o estágio que converte o sinal analógico para o domínio digital viabilizando processamento digital de sinais para interconexões em sistemas digitais (microcontroladores). Conversores ADC são comumente utilizados como dispositivos de digitalização de sinais analógicos. ADC´s capturam uma tensão de entrada e produzem na saída um valor digital com uma especificada resolução. A faixa dinâmica do SPOT tem requisito de no mínimo 14 bits de resolução. Foram analisados quatro diferentes tipos de implementações: ADC Interno de Microcontroladores: Considerado inadequado porque são usualmente de 10 a 12 bits de resolução e também implicam em um aumento considerável no consumo do microcontrolador; 16 bits ADC´s: Significativamente mais caros e implicam na utilização de Digital Signal Processor (DSP)´s. Utilizar um DSP no projeto aumentaria a complexidade, custo e o consumo; Conversores V/F: São dispositivos analógicos de baixo custo cuja saída é um trem de pulsos digitais; Circuito Integrados de Medição de Consumo: Não foi encontrado nenhum que atenda os requisitos do SPOT. O último estágio é a acumulação de energia e a saída digital. Para viabilizar isto é necessário integrar a potência em função do tempo (Equação 3.1). Z t E(t) = P(t)dt (3.1) t0 O SPOT utiliza contadores para somar o trem de pulsos. Cada borda de subida do trem de pulsos incrementa o contador. Quando o consumo é alto verifica-se pulsos com maior frequência e menor intervalo de tempo. A diferença no contador entre os intervalos 35 de tempo t0 e t representam o consumo de energia durante o tempo t − t0. Para evitar “overflow”4 do contador o mote possui uma linha para zerar esses contadores. Adicionalmente foi utilizado como base de tempo um outro contador que mede precisamente o tempo decorrido da medida. Este contador é disparado pelo próprio oscilador do conversor V/F. 3.2.4 Resultados As Leituras dos contadores são obtidas do SPOT, calibradas e comparadas com uma curva de referência obtida de um equipamento de instrumentação eletrônica profissional (Figura 3.5). Figura 3.5: Comparação das medidas obtidas pelo SPOT e um amperímetro. Na Figura 3.5, o mote em observação está drenando 9µA. Após 6 minutos o erro é menor que 0.1mJ ou 3%. A Figura 3.6 ilustra a energia monitorada pelo SPOT comparativamente a de um osciloscópio. As porções mais longas da curva são representadas pelo consumo de energia durante modo “sleep” enquanto que os crescimentos repentinos entre os degraus da escada correspondem ao consumo durante o ciclo ativo. Figura 3.6: Energia (mJ) em Função do Tempo (S). 4 Quando o valor do buffer de contagem ultrapassa sua capacidade máxima. 36 A Figura 3.7 é o gráfico da corrente em função do tempo. Nota-se que a resolução é um pouco baixa. Isto se deve ao tempo de espera do mote para ativar uma medição. Figura 3.7: Corrente (mA) em função do Tempo (S). 3.2.5 Conclusão O trabalho abrange os requisitos, arquitetura, projeto e resultados do SPOT. Foi esclarecido que o dispositivo está habilitado a efetuar medições e ultrapassou os desafios. O SPOT emprega uma arquitetura que, através do domínio analógico, viabiliza uma larga faixa dinâmica. Os dois contadores: acumulador de energia e resolução temporal, possibilitam a realização das medições com boa precisão. O SPOT, devido às similaridades dos “profiles” das aplicações para WSN pode ser extendido para efetuar aferições em Personal Digital Assistants (PDA), telefones celulares e novas classes de sensores para WSN´s. 3.3 3.3.1 A Runtime Energy Monitoring System for Wireless Sensor Networks Visão Geral Eficiência energética é um dos tópicos mais importantes no desenvolvimento de RSSF. Há uma grande demanda de artigos sobre o problema do consumo de energia com foco em protocolos e aplicações. Observa-se que há uma lacuna quando se trata da obtenção de medidas reais. Segundo TRATHNIGG; WEISS, simuladores como o PowerTOSSIM[54] e AEON[38] têm grande valor, mas o modelo de energia é limitado. Medidas precisas do consumo de energia de cada nó em uma WSN é desejável por inúmeras razões. Primeira, o modelo de energia de simuladores são incoerentes. Segunda, o número de plataformas para RSSF está crescendo significativamente. Isto implica em um alto número de plataformas não suportadas por simuladores existentes. Terceira, a informação detalhada do consumo de um nodo viabiliza a investigação em todas as camadas da plataforma. Por exemplo, a técnica “dynamic power management” pode ser utilizada para adaptar a qualidade do serviço em função da energia remanescente. A informação de energia pode ser utilizada para a descoberta e manutenções das rotas. 37 A plataforma SPOT detalhada em [32] alcança boa precisão mas considera a tensão da fonte de energia constante. Isto não é nada realista no cenário de dispositivos alimentados à bateria porque a tensão da fonte de alimentação diminui com o passar do tempo. Foram identificadas algumas questões importantes em sistemas de medições de energia, são elas: Precisão: Deve ser melhor do que os resultados obtidos pelos simuladores; Faixa Dinâmica: A corrente drenada por um mica2 situa-se em torno de 35mA quando no estado ativo. No modo “sleep” a corrente baixa para cerca de 30µA; Custo e Tamanho: Cada nodo de uma RSSF deve ser monitorado simultaneamente e o sistema de monitoramento deve ser de pequenas dimensões e viabilidade econômica; Não invasivo: O sistema de medição deve influenciar o mínimo possível no consumo de energia do nó que está sendo aferido; Simplicidade: Fácil integração, instalação e utilização. 3.3.2 Arquitetura Utilizada O consumo de energia do nodo de uma RSSF depende da tensão aplicada. Por isso a arquitetura utilizada efetua medições tanto da tensão quanto da corrente simultaneamente. A Figura 3.8 mostra a arquitetura utilizada no projeto em [61]. Figura 3.8: Arquitetura do “Runtime Energy Monitoring System for Wireless Sensor Networks”. O esquema de medição apresentado no diagrama de blocos da Figura 3.8 é marginalmente invasivo. O mote, por si só, efetua a leitura do consumo através do barramento I2C[53]. A energia utilizada pelo mote é denotada por: Z T E= u(t) × i(t)dt (3.2) t=0 Como os valores são discretos, teremos então: N E= ∑ u[n] × i[n] × t[n] n=0 (3.3) 38 Para viabilizar as medições com o TinyOS[40, 4] foi implementada uma interface em camadas. A primeira camada basicamente implementa todas as funções da interface I2C. A segunda, simples mas suficientemente eficiente para medições de energia, é uma interface com nível de abstração mais alto do que a primeira. A aplicação inicializa o processo de medição por um período de tempo. Quando o processo termina, a energia é obtida da aplicação através de um evento. O Código 8 .5 ilustra a simplicidade e o nível de abstração da interface de medição projetada. Código 3.1: Interface de Medição 1 2 3 4 i n t e r f a c e EnergyMeasurement { command r e s u l t _ t s t a r t E n e r g y M e a s u r e m e n t ( u i n t 3 2 _ t s e c o n d s e v e n t void energyMeasurementDone ( double j o u l e ) ; } Um fator de calibração teve de ser determinado. O cálculo do fator de calibração K foi viabilizado utilizando um resistor de valor conhecido ao invés do mote, aplicando uma tensão estável e obtendo a energia consumida pelo resistor durante um período de tempo. A Equação 3.4 ilustra como o fator K foi calculado. N E = K × ∑ u[n] (3.4) n=0 Para calibração do “offset” utilizou-se a Equação 3.4 subtraindo o erro de “offset” do amplificador operacional (Equação 3.5). N E = K × ∑ u[n] − EO f f set (3.5) n=0 A disposição do medidor de energia foi implementada numa placa do tamanho de um mica2. O dispositivo de medição foi acoplado ao mote através do conector de extensão. Como não é possível interceptar a fonte de alimentação do mote através deste conector foi necessário substituir a fonte de alimentação do mote. A Figura 3.9 mostra a placa conectada ao mote. Figura 3.9: Foto da placa de medição. As diferenças de “clock” entre o mote e o microcontrolador ATtiny45 iria gerar erro nas medidas e na correção do “offset”. Por isso foi escolhido a utilização de um “timer” 39 do mote para temporização das medidas. Isto impõe uma carga extra no mote mas a energia adicional pode ser negligenciada. Como a medida de pequenos sinais são sensíveis a ruídos, foram utilizados capacitores “bypass”5 , anéis e planos de terra de forma a manter o ruído o mais baixo possível. 3.3.3 Resultados Para validar a precisão das medidas foi realizado um procedimento prático experimental com a finalidade de avaliar a energia consumida em função de várias cargas. Uma fonte de alimentação bem estável foi usada para manter a tensão estabilizada dentro da faixa de 2.7V a 3.3V. Vários resistores de valores fixos foram utilizados no lugar do mote e um multímetro digital modelo 34401A da Agilent foi utilizado para efetuar as medidas. Como a tensão e a resistência são conhecidas, a corrente pôde facilmente ser calculada. As medidas efetuadas pelo instrumento foram comparadas com as do protótipo. O gráfico ilustrado na Figura 3.10 mostra a curva de erro para várias cargas alimentadas por uma tensão fixa de 3.15V. O erro obtido foi de 2%. As medições da energia consumida pelo mica2 apresentaram excelente precisão. Figura 3.10: Curva de Erro do “Runtime Energy Monitoring System for Wireless Sensor Networks”. Para experimentos reais, mica2 conectado ao protótipo, a correção de “offset” sofre variações com a temperatura e o tempo. Esta avaliação não foi concluída e ainda está em fase de desenvolvimento. O ponto chave do “runtime energy-measurement setup” é a capacidade de efetuar medidas em cenários com muitos nodos distribuídos. O dispositivo pode ser utilizado para melhorar a eficiência de protocolos e aumentar o tempo de vida útil da RSSF. O instrumento se mostrou suficientemente hábil para efetuar aferições do consumo em nodos individuais de RSSF´s. 5 Arranjo de capacitores que filtram determinadas frequências. 40 3.3.4 Conclusão A precisão e a faixa dinâmica do SPOT e o “runtime energy-measurement setup” são equivalentes. Isto se deve principalmente às similaridades das abordagens para medições de corrente. Um importante avanço do “runtime energy-measurement setup” comparado com outras abordagens é a capacidade de monitorar a tensão continuamente. Isto é de grande importância porque a tensão da bateria decresce com o tempo. Custo, tamanho e fácil integração são semelhantes ao SPOT. O SPOT utiliza contadores baseados no protocolo I2C. Nesta abordagem, para evitar “overflow”, o mote deve periodicamente efetuar leitura desses contadores e zerá-los. Isto impõe um consumo extra de energia que, no caso de aplicações de muito baixo duty cycle, pode ser negligenciado. Conforme foi apresentado o “runtime energy-measurement setup” interfere o mínimo possível no consumo de energia do mote. O protótipo pode ser montado com baixo custo, pequenas dimensões, proporcionando boa precisão dentro de toda a faixa dinâmica típica dos motes. Este é a primeira abordagem de medição de energia de WSN que considera a tensão de alimentação variável. A montagem pode ser facilmente adaptada para outras plataformas de RSSF e futuros trabalhos serão focados na redução do consumo do protótipo e a integração das informações de consumo para utilização em protocolos e aplicações de RSSF. 3.4 3.4.1 Energy Measurements for MicaZ Node Introdução Dispositivos móveis são geralmente alimentados a baterias. Fabricantes de baterias recarregáveis especificam a capacidade da célula que é avaliada utilizando medições com uma carga fixa. Para baterias de polímeros de lítio esta carga é relativamente alta comparada com o consumo de um dispositivo “low-power”. A capacidade da bateria depende principalmente da tensão mínima operacional necessária para o funcionamento do dispositivo, a corrente e a temperatura. Para determinar o perfil do consumo de um dispositivo alimentado a bateria deve-se considerar dois itens importantes: a capacidade real e o consumo de energia do dispositivo móvel. O microcontrolador que faz parte do dispositivo pode operar no modo “idle”, “sleep” ou algum outro modo de economia de energia. Isto implica em variações no perfil do consumo de energia do equipamento. O consumo de energia é alto se o dispositivo não faz uso do modos de economia de energia. O microcontrolador do MICAz dispõe de seis modos diferentes de economia de energia. A transição dos modos ocasionam alguns efeitos importantes como por exemplo: desligar o oscilador principal da CPU, desabilitar “timers” ou interrupções externas. 3.4.2 Medições de uma bateria de polímero de lítio (LiPo) Para muitas aplicações é necessário saber quando a capacidade da bateria está abaixo de um certo nível. Se a bateria estiver no limite de sua carga, uma mensagem de alerta pode ser sinalizada ou o dispositivo poderá desligar-se automaticamente. A escolha da Lithium Polymer Battery (LiPo) foi idealizada porque os dispositivos móveis devem possuir fontes de energia de baixo peso e alta densidade energética. Para baterias de LiPo há 41 poucas curvas de demonstração da descarga e, na maioria das vezes, são correntes com níveis múltiplos da capacidade. A razão disso é que estes modelos de bateria são muito utilizados em aeronaves onde há um alto consumo de corrente. Para o experimento foi utilizada uma bateria recarregável de LiPo fabricada pela Kokam[1] com uma capacidade nominal de 1.5Ah e uma tensão de 3.7V. A bateria foi descarregada por uma corrente constante de 37.8mA circulando através de um conversor DC-DC e um resistor. Os valores foram obtidos através de um osciloscópio. O resultado do experimento é mostrado através da Figura 3.11. O eixo X compreende do tempo em unidade de 30 segundos e o eixo Y expõe a tensão da bateria e a saída do conversor DC-DC. A primeira seção da curva, com 250 unidades de tempo, decresce mais rapidamente que a seção do meio. Nas duas primeiras seções, a relação entre a tensão e o tempo são praticamente lineares. Somente na última seção, cerca de 3250 unidades de tempo, a tensão diminui abruptamente em um curto período de tempo até o ponto de total descarga t=3816. Figura 3.11: Descarga de uma bateria de LiPO a 37.8mA. A capacidade utilizável da bateria pode ser calculada através da seguinte Equação 3.6. 3816.30s × 37.8mA = 1202mAh 3600 hs (3.6) Um dos resultados importantes neste experimento é que a tensão varia com a descarga da bateria. 3.4.3 Medições em um MICAz 3.4.3.1 Microcontrolador ATMEGA128L A avaliação do tempo de operação de um nodo MICAz tem como requisito a obtenção de medidas exatas do consumo de energia do dispositivo. O MICAz consiste de um microcontrolador[24], um transceptor de rádio[31], três LED´s e alguns poucos componentes que não são relevantes citar nesta seção. Todos os componentes citados podem ser ligados e desligados ou migrar para algum mecanismo de economia de energia. O consumo de energia está presente nos “datasheets” da maioria desses componentes eletrônicos. A soma do consumo, especificado nos “datasheets”, pode diferir de um valor 42 correto porque há um consumo adicional dos outros componentes tais como resistores, capacitores, entre outros. Um outro problema é a diferença marcante no consumo apresentado pelo dispositivo no modo de economia de energia e no modo ativo. Para este experimento prático utilizou-se o mesmo regulador DC-DC citado na seção anterior para reduzir a tensão a nível de utilização do MICAz (3.1V). Na saída do regulador foi adicionado o MICAz. A corrente do MICAz e a tensão foram obtidas por instrumentação eletrônica (osciloscópio). Para cada um dos estados foram realizadas medidas do consumo de energia do MICAz. Outro paradigma utilizado foi a variação da frequência de clock “frequency scaler”. A figura 3.12 mostra o consumo de energia dos diferentes modos providos pelo microcontrolador ATMEGA128L[24]. Figura 3.12: Modos de economia de energia do ATMega128L. a: Busy (mul), b:Busy (jmp), c:NOP, d:Idle, e:ADC, f:Ext. Standby, g: Save. Antes de efetuar a transição para estes modos o programa espera a estabilização do consumo. As primeiras três medições concerne ao modo de operação normal. Duas delas representam “duty cycles” enquanto que a terceira corresponde a um “loop idle”. Ambos os “loops” apresentam um alto consumo, enquanto que o “loop NOP” tem um consumo baixo de 1mA. Todos as outras aferições mostram os modos de economia de energia. O modo “idle” apresenta um consumo alto relativo aos demais, mas tem a vantagem de ter os periféricos do microcontrolador em plena operação. Outros modos apresentam muito baixo consumo mas apresentam efeitos resultantes da desabilitação dos periféricos do microcontrolador. Nestas medições, os modos “standby” e “powerdown” não foram considerados. Estes dois modos param o relógio do microcontrolador e uma nova transição para outro modo somente é possível através de uma interrupção externa. A Tabela 3.13 mostra a média do consumo de energia em cada modo discutido[36]. Detalhes para diferentes modos podem ser obtidos na folha de dados do microcontrolador[24]. Uma segunda forma de limitar o consumo de energia consiste na redução da frequência de operação do microcontrolador[36]. Se a próxima tarefa pode ser executada em um tempo t, a frequência pode ser diminuída para um nível onde a tarefa termine no tempo t. Um exemplo disto é ilustrado na Figura 3.14. 43 Figura 3.13: Média do Consumo de Energia. Figura 3.14: Benefício de diminuir a frequência do ATMEGA128L. 3.4.3.2 Transceptor CC2420 O transceptor é o componente que mais consome energia no MICAz. Este componente tem quatro modos diferentes de operação: “down, idle, send e receive”. De acordo com o datasheet[31], o modo “receive” consome maior energia que o modo “send”. As medições experimentais determinaram um consumo de 20mA em ambos os modos. O modo “idle” tem um consumo de 0.4mA maior que o modo “down”. A Figura 3.15 mostra o perfil de consumo do rádio[36]. Neste experimento foi conservada a corrente do microcontrolador o mais baixo possível para obter precisão. A frequência de operação foi dividida por 16. O transceptor inicializa e entra no modo “receive”. Após um período, uma operação de transmissão “send” é iniciada. Isto não é visualizado pelo experimento e finalmente o dispositivo retorna de volta ao modo “receive”. Figura 3.15: Consumo do CC2420. 44 3.4.3.3 LEDs As aferições realizadas nos LED´s determinaram um consumo médio de 10.2mA incluindo o microcontrolador. Subtraindo o consumo do microcontrolador 7.69mA o consumo de 2.5mA por LED. 3.4.4 Conclusão As medidas efetuadas em baterias de LiPo tiveram uma boa relação com a capacidade remanescente da bateria. As avaliações no dispositivo foram suficientes para determinar a quantidade de energia consumida em cada modo de operação. Alguns modos de economia de energia disponíveis são ilusórios quanto aos valores presentes nos “datasheets” e não devem ser utilizados na contenção do consumo e eficiência energética. Doravante, o método de “frequency-scaling” pode ser utilizado para diminuir o consumo quando o modo “sleep” não for aplicável na situação. Com os resultados obtidos é possível aperfeiçoar o modelo de energia do simulador AVRORA[59]. Os próximos passos serão o desenvolvimento de um agendamento dinâmico que viabilizará estimar o consumo de energia das tarefas e suas prioridades. Haverá também espaço para diminuir a frequência do microcontrolador para execução das tarefas de forma a minimizar o consumo de energia. 3.5 Conclusão A Seção 3.2 expressa a elaboração da ferramenta de medição denominada de “Scalable Power Observation Tool -SPOT”. Este dispositivo apresentou boa estabilidade e alcançou a larga faixa dinâmica necessária para aferir o consumo em RSSF. O SPOT apresentou excelente precisão quando comparado com instrumentação eletrônica. No entanto, apresenta uma latência nas medições devido à espera do mote para disparar uma medida. Isto acontece quando o rádio recebe um pacote. Neste instante, o TinyOS dispara um evento, e somente depois desse evento acontecer é que o dispositivo, através barramento I2C, zera os contadores e solicita uma amostra da potência instantânea, provocando um atraso na medida. O ideal seria que a medida inicializasse antes do rádio sair do estado “idle” para “receive”. O segundo e maior problema de projeto do SPOT foi considerar a tensão do mote fixa. Esta simples falha de projeto gera resultados práticos incoerentes porque sabe-se que a tensão da fonte de energia do mote diminui com o tempo. Na Seção 3.3 foi mostrado o projeto de uma ferramenta de medição do consumo de energia denominada de “Runtime Energy Monitoring System for Wireless Sensor Networks”. Na visão geral é abordado os requisitos do projetos mas, a arquitetura poderia ser mais definida e detalhada. O dispositivo é mais simples que o SPOT e apresentou boa estabilidade e precisão nas medidas. O diferencial marcante foi a consideração de uma variável de grande importância nas medidas do consumo de energia em WSN, a tensão da fonte de energia. Portanto este é o único equipamento, até então, que considera a tensão do mote como uma grandeza variável. Foi citado que o dispositivo já está sendo utilizado para elaboração de um modelo de energia mais eficiente do simulador AVRORA[59]. A Seção 3.4 ilustrou medidas nos componentes eletrônicos mais importantes que fazem parte do MICAz. Os testes efetuados com uma bateria de LiPo foram fundamentais porque foi comprovado que a capacidade nominal da bateria, fornecidade pelo fabricante, 45 é dependente do tipo de aplicação a que será utilizada. A bateria de LiPo, utilizada nos testes, não fornece a capacidade de 1500mAh mas sim de 1202mAh como foi evidenciado no experimento. Foram efetuadas medições do consumo dos seis modos de operação do microcontrolador ATMEGA128L[24] e concluiu-se que alguns modos de economia de energia não devem ser utilizados. A diminuição da frequência “frequency-scaling”, quando possível, deve ser utilizada para diminuir o consumo de energia do MICAz. Os testes realizados no transceptor de rádio[31] mostraram que não há diversidade no consumo do rádio quanto à transmissão e recepção. Ao contrário do que está citado no “datasheet”, verificou-se que o dispositivo drena a mesma quantidade de corrente tanto no modo “send” quanto no modo “receive”. Os trabalhos citados neste capítulo estão diretamente relacionados com o projeto e implementação do dispositivo de medição desenvolvido nesta dissertação de mestrado. O princípio de captura das variáveis físicas e as arquiteturas apresentadas são equivalentes, no entanto diferem no aspecto de precisão, eficiência, integração e metodologia adotada no desenvolvimento do protótipo do Capítulo 4. Capítulo 4 Arquitetura Proposta 4.1 Introdução Há lacunas na análise de consumo de redes de sensores sem fio - RSSF. A necessidade de efetuar uma análise real de cada nó de uma RSSF motivou o projeto de uma placa de medição que proporcionasse flexibilidade e produzisse o mínimo de interferência no circuito a ser medido. Desta forma, este capítulo abrange o projeto, análise e montagem de um circuito de medição com as seguintes características: 1. “in situ” meter1 2. Minimamente invasivo - Mínima interferência no circuito a ser medido; 3. Pequenas dimensões; 4. Medicões de tensão e corrente instantânea e consultas desses valores através do protocolo I2C. 5. Cobertura dinâmica - Abrangência maior possível da faixa dinâmica; 6. Baixo consumo - circuito em “standby” entrando no modo normal somente mediante às solicitações do nó da RSSF; 7. Consideração do valor real da tensão e corrente em cada medida simultaneamente; 8. Baixo custo. 9. Monitoramento do consumo durante a operacão (“runtime”). As seções seguintes explicam individualmente os circuitos integrados utilizados, cálculos efetuados e os periféricos utilizados no processo de conversão. 4.2 Fluxograma de Projeto O projeto da placa de medição foi dividido em onze fases, conforme ilustradas na Figura 4.1. A Tabela 4.1 explica detalhadamente cada fase com suas características. 1A operação do instrumento é realizada sem interromper o estado normal do sistema. 47 Figura 4.1: Fluxograma de Projeto da Placa de Medição Tabela 4.1: Fases de Projeto da Placa de Medição Fase I II III IV Descrição Estudo de caso dos dados, sinais, interface com o mundo real, domínio digital e analógico e variáveis necessárias para medição. Cálculos dos modelos que serão adotados no projeto. Pesquisa aprofundada de componentes eletrônicos disponíveis no mercado com ênfase no atendimento dos requisitos da fase I, precisão e baixo custo. Verificar se os componentes eletrônicos atendem ou não as especificações do projeto. Desenho do diagrama esquemático (“layout”) do circuito utilizando software Eagle PCB[11]. 48 V VI VII VIII IX X XI 4.3 Desenho da placa de circuito impresso (“PCB”) do circuito utilizando software Eagle PCB[11]. Compra dos componentes eletrônicos. Montagem do protótipo com tecnologia Surface Mounted Devices (SMD) e desenvolvimento, em linguagem C, do software embarcado no microcontrolador PIC18F2620[26]. Desenvolvimento em TinyOS do sistema embarcado do MICAz. Desenvolvimento em Delphi do TinyOS Terminal. Verificação e testes do conjunto de sistemas. Análise dos resultados obtidos na fase experimental. Visão Geral da Arquitetura A figura 4.2 ilustra a visão geral da arquitetura do placa de medição desenvolvida. Figura 4.2: Visal Geral da Arquitetura da Placa de Medição. De acordo com a figura 4.2, verifica-se três etapas que são abordadas com detalhes na tabela 4.2. Tabela 4.2: Etapas da Arquitetura da Placa de Medição. Etapa Sensoriamento Conversão V/F Digitalização Descrição Condicionamento, amplificação e aquisição de corrente e tensão. Transforma os valores de tensão e corrente em um trem de pulsos cuja frequência é proporcional ao sinal de entrada. Captura de frequência de tensão e corrente através de periférico integrado ao microcontrolador PIC18F2620. 49 4.4 Módulo de Amplificação de Corrente Eficiência energética em sistemas eletrônicos é um fator crítico. O sensoriamento de corrente permite o monitoramento e avaliação dos níveis de consumo de energia do equipamento, bem como a prevenção de falhas de curto-circuito e as indesejáveis descargas abruptas da bateria. Existem diferentes topologias para sensores de corrente, cada uma com seus atributos e requisitos de aplicações. A escolha da configuração do sensor pode ser determinante no projeto final. Um sensor de corrente é um circuito que monitora o fluxo de corrente em um circuito elétrico, que através da passagem de corrente elétrica, provoca uma queda de tensão em um resistor-série (“shunt”) colocado no caminho da corrente[28]. Como apresentado na Figura 4.3. Esta conversão de corrente/tensão pode ser condicionada a níveis proporcionais para ser capturada em conversores e instrumento de medições[28, 46]. Figura 4.3: Voltímetro aferindo a queda de tensão no resistor “shunt”. 4.4.1 Alternativas para medição de corrente Esta seção descreve e justifica o uso e o tipo de amplificador de instrumentação utilizado no projeto para amplificação de corrente. Há dois métodos básicos disponíveis para sensoriamento de corrente elétrica. O primeiro método utiliza o processo de medição do campo magnético ao redor do condutor por onde flui a corrente elétrica e o segundo utiliza a inserção de um resistor de pequeno valor “shunt” no caminho da corrente para medir a queda de tensão através dele. A primeira abordagem, além do alto custo, é suscetível a perdas pela não linearidade e erros do coeficiente de temperatura. Sensores magnéticos são usualmente restritos para aplicações que justifiquem o alto custo associado[46]. Para medição de baixas correntes utiliza-se comumente duas configurações: • High-Side Current Monitoring • Low-Side Current Monitoring Muitas aplicações utilizam o princípio de Low-Side Current Monitoring, que consiste num resistor conectado em série entre a carga e o terra conforme Figura 4.4[46]. 50 Figura 4.4: Low-side current sensing Algumas desvantagens dessa abordagem são as corrrentes de curto-circuito resultantes de acidentes entre a bateria e a terra que não são detectáveis e o aparecimento dos efeitos indesejáveis de “terra flutuante” resultantes da resistência extra entre a carga e o terra. High-side current sensing (Figura 4.5 consiste em colocar o resistor “shunt” entre a fonte de alimentação e a carga. Esta abordagem elimina os problemas de flutuações de terra em “low-side sensing” e também possibilita a detecção de curto-circuitos acidentais da bateria para o terra [46, 49]. Figura 4.5: High-side current sensing 4.4.2 Amplificador de Corrente Escolhido Tipicamente para aplicações de baixa tensão a abordagem “high-side sense amplifier” utiliza-se um amplificador de instrumentação integrado Instrumentation Amplifier (IA). Para o projeto da placa de medição utilizou-se o MAX4372F, um monitor dedicado de corrente da Maxim Integrated Products[50]. O MAX4372F é um amplificador de precisão e de baixo custo, disponível em encapsulamento SOT23-5pinos. Este amplificador opera com uma fonte de alimentação assimétrica com faixa de 2.7-28V, consume apenas 30µA, possui ganho fixo de 50V/V e largura de banda de 200Khz. É ideal para monitoramento de corrente em sistemas alimentados a bateria. A Figura 4.6 ilustra um diagrama funcional do MAX4372F. Apresenta as seguintes vantagens[49, 50]: • Opera na faixa de temperatura de −40◦C até + 85◦C; 51 • projetado para pequenos sinais (0-28V); • baixo consumo 60µA; • facilidade de uso porque é um dispositivo específico para monitoramento de corrente; Figura 4.6: Diagrama Funcional - MAX4372. O circuito possui tensão de modo comum de 0 a 28V que é independente da fonte de alimentação. Esta característica possibilida o monitoramento do fluxo de corrente da bateria em “deep discharge”2 e tensões que ultrapassam a fonte de alimentação (VCC). A tensão diferencial de entrada VSENSE é igual a VIN-V- e o transistor, na saída de SENSE . A1, amplifica a corrente por um fator β , de modo que IM = β ×VRG1 A saída do amplificador A2 é dada por: VOUT = RGD × β ×V SENSE RG1(1 + R2 R1 ) (4.1) O ganho do dispositivo é dado por: VOUT RGD × β = V SENSE RG1(1 + R2 R1 ) (4.2) Função transferência do circuito adotado: VOUT = V SENSE × 50 (4.3) A Tabela 4.3 mostra na primeira coluna a corrente que está passando pelo resistor “shunt”. A segunda coluna ilustra a queda de tensão produzida pela passagem de corrente 2 Processo em que descarrega-se uma bateria até 20% ou menos da sua capacidade nominal. 52 Tabela 4.3: Relações entre Corrente, Tensão diferencial de entrada e Tensão de Saída. Corrente 0.300 mA 1.000 mA 5.000 mA 10.000 mA 50.000 mA Vsense 0.300 1.000 mV 5.000 mV 10.000 mV 50.000 mV Ganho do MAX4372 50 50 50 50 50 Vout 15mV 50mV 250mV 500mV 2,5V no resistor. A terceira coluna expõe o ganho fixo do amplificador de corrente e a quarta e última coluna corresponde à saída do amplificador de corrente que é o produto da segunda coluna com a terceira. 4.5 Conversor de Voltagem para Frequência Uma RSSF, dependendo da aplicação, exibe diferentes curvas de comportamentos de consumo (profiles)[32]. A título de exemplo, considere uma aplicação com 0.5Hz de duty cycle3 exibindo um profile ilustrado na Figura 4.7. Na Figura 4.7, o gráfico inferior corresponde a uma abertura “zoom” de apenas um dos pulsos exibidos no gráfico superior. Figura 4.7: Um típico comportamento nodal de consumo consistindo de longos períodos de baixa corrente pontuado por curtos períodos de atividade com alta corrente. A aplicação pode ler e guardar na RAM4 valores de sensores, armazenar os valores em 3 Descreve 4 Tipo a fração de tempo em que um sistema está em um estado “ativo”. de memória que permite a leitura e a escrita, utilizada como memória primária em sistemas ele- 53 memória flash5 uma vez por dia e realizar (“upload”) dos dados uma vez por semana[32]. A situação descrita no parágrafo anterior é ligeiramente diferente da que nós iremos utilizar nos casos de teste, uma vez que, o objetivo é cobrir uma faixa dinâmica do espectro de corrente e tensão neste projeto. Nós sensores em WSN são aplicações pulsantes. A largura do pulso ou o tempo de atividade deve ser considerado para determinar a taxa de amostragem (sampling rate). A cobertura da faixa dinâmica é um fator crítico no projeto. Utilizou-se um conversor de Voltagem para Frequência de baixo custo, o AD654 da Analog Devices[2], cujo diagrama funcional é ilustrado na Figura 4.8. Figura 4.8: Diagrama funcional do AD654. O AD654 é um circuito integrado conversor de voltagem para frequência que consiste de uma entrada amplificada, um sistema oscilador de precisão e um estágio de saída de alta corrente. Uma rede RC é o único requisito para configurar a frequência de fundo de escala[2]. Algumas características do AD654: • Opera com fonte simétrica ou assimétrica (5V a 36V, ±5V a ±18V); • Frequência de fundo de escala acima de 500KHz; • Simplicidade. Mínimo número de componentes externos são necessários para configuração; • Baixo consumo. 2.0mA de corrente quiescente; • 1mV de offset; • A frequência de fundo de escala é estabelecida pela simples realação: FS = Vin 10∗R∗C . Uma configuração do conversor V/F AD654 para tensões positivas de entrada é ilustrada na da Figura 4.9. Um amplificador operacional é o estágio de entrada e o propósito é converter o valor da tensão de entrada para o transistor de realimentação da saída. Bons desempenhos são alcançados quando esta corrente de 1mA é aplicada na entrada do conversor V/F. Há um multivibrador astável cuja função é produzir uma onda quadrada na saída. O transistor de saída possui o coletor aberto para que a lógica digital seja referenciada indiferente dos níveis de alimentação do circuito analógico. trônicos digitais. 5 Memória de computador do tipo EEPROM 54 Figura 4.9: Configuração simples V/F do AD654. No esquema de conexão da Figura 4.9, o amplificador de entrada apresenta uma impedância muito alta. Os resistores R1 e R2 são selecionados junto com o capacitor CT para prover a frequência de fundo de escala. O diodo Schottky CR1 (MBD101) normaliza os níveis lógicos digitais eliminando 500mV abaixo de -VS. Este diodo não foi requisito haja vista que no circuito de medição projetado o conversor opera com alimentação assimétrica[2]. A Figura 4.10 ilustra o circuito utilizado na placa de medição. Figura 4.10: Configuração do conversor de voltagem para frequência utilizada na placa de medição. A frequência de saída em função da tensão de entrada é dada pela Equação 4.4: Vin (4.4) 10 × 1E − 9 × 100E3 A corrente máxima em um MICAz é de 60mA, lembrando que 60mA equivale a uma queda de tensão de 60mV na entrada do MAX4372 e multiplificando pelo ganho (fator 50), temos uma tensão de entrada de 3V, portanto, isto nos fornecerá uma frequência de fundo de escala de 3KHz, que é provada pela Equação 4.5[2]: Fout = 60mA × 50 = 3KHz (4.5) 10 × 1E − 9 × 100E3 Utilizando V/F ao invés de ADC maximiza-se a precisão da faixa dinâmica de cobertura do espectro. O PIC18F2620 possui ADC de 10 Bits cuja resolução[60]6 (tamanho do Fout = 6 Definida como a menor alteração que pode ocorrer na saída. 55 degrau) é dada pela Equação 4.6: Resolução = 3.0 210 − 1 = 2.933mV (4.6) Para o cálculo da resolução do conversor V/F devemos considerar a tensão de offset[33] de entrada, que é 1mV, e a tensão de 3V correspondente à frequência de fundo de escala do conversor. Com um pouco de algebrismo calcula-se a resolução do conversor através da Equação 4.7. Resolução = 3.0 − 1 × 10−3 3.0−1×10−3 10×1×10−9 ×100×104 = 1mV (4.7) O ganho de resolução quando se utiliza conversor V/F é notável porque a cobertura dinâmica proporciona 3000 degraus de 1mV cada, ao invés dos 1023 degrais de 2.93mV do (ADC). Para alcançar os 3000 degraus utilizando um ADC seria necessário, no mínimo, um ADC externo de 12 bits que seria bastante oneroso no projeto e consumo de energia. 4.6 Microcontrolador A Microchip Inc. tem desenvolvido a série PIC18 de microcontroladores para uso em aplicações complexas. O PIC18F é uma solução custo-benefício para aplicações de propósito geral que utilizam Real Time Operating System (RTOS)7 e possuem requisitos de protocolos de comunicações complexos, tais como: TCP/IP, CAN, USB ou Zigbee[23, 26]. As características básicas principais da série do PIC18F são[23, 26]: • 77 instruções; • Compatível com a série PIC16; • Interrupções com níveis de prioridade; • Instruções de 16 bits e caminho de dados de 8 bits; • Capacidade de alta corrente (25mA); • Master Synchronous Serial Port (MSSP) (SPI e I2C); • Conversores ADC de 10 bits Neste projeto ficou definido que o microcontrolador a ser utilizado seria o da da série 18F da Microchip - PIC18F2620[26]. O PIC18F2620 é um microcontrolador com estrutura flexível, tecnologia nanoWatt[27]8 e várias configurações de osciladores. Algumas características principais são citadas na Tabela 4.4. 7 Um sistema operacional destinado à execução de múltiplas tarefas onde o tempo de resposta a um evento é pré-definido. 8 É um padrão industrial de baixo consumo, larga faixa de tensões de operação e gerenciamento de potência flexível concebido pela Microchip Technology Inc. 56 Tabela 4.4: Características principais do PIC18F2620. Parâmetro Tipo de Memória de Programa Memória de Programa (KB) CPU Speed (MIPS) Ram Bytes Data EEPROM (bytes) Periféricos de comunicação digital Capture/Compare/PWM Peripherals Timers ADC Comparadores Tensão de Operação Número de Pinos Valor Flash 64 10 3968 1024 1-A/E/USART, 1-MSSP(SPI/I2C) 2 Capture/Compare/PWM (CCP) 1 x 8-bit, 3 x 16-bit 10 canais de 10 bits 2 2V a 5.5V 28 Na escolha dos componentes do projeto, procurou-se sempre utilizar encapsulamentos SMD a fim de reduzir as dimensões finais da placa de medição. Para o microcontrolador PIC18F2620, utilizou-se Small-Outline Integrated Circuit (SOIC) porque possui dimensões menores que o encapsulamento Dual In Line Package (DIP), desta forma, ocupa menos espaço físico na PCB. A Figura 4.11 ilustra a pinagem do PIC18F2620. Figura 4.11: Pinagem do PIC18F2620. 4.7 Fonte de Alimentação DC e Circuitos Utilizados O circuito da placa de medição, conforme citado anteriormente, tem como requisito baixo consumo de energia. Desta forma, na maioria do tempo, ele estará desligado em standby e só entrará em operação quando o MICAz solicitar, através do barramento I2C as informações de consumo. Um outro requisito é ser minimamente invasivo, ou seja, a operação da placa de medição deverá produzir o mínimo de interferência na fonte de alimentação do circuito a ser medido, no caso o MICAz. Assim sendo, adotou-se uma bateria de 9V(Figura 4.12), também conhecida pelo nome coloquial de “PP3 battery” como fonte de alimentação. A alimentação do microcontrolador e o circuito digital é responsável pelo Integrated Circuit (IC) LE33AB; um regulador de tensão de 3.3V[56]. 57 Figura 4.12: Panasonic PP3 (9 volt) battery. O restante do circuito, conversores V/F e sensor de corrente são alimentados diretamente pela bateria de 9V. Figura 4.13: Pinagem do LE33AB. A Tabela 4.5 mostra as características do Low-Dropout Output (LDO) LE33AB que produz na saída uma tensão compatível com a operação do microcontrolador PIC18F2620. A Figura 4.13 ilustra respectivamente os pinos disponíveis no circuito integrado. O LE33AB é um LDO disponível com encapsulamentos TO-92 e SO-8 e opera com uma larga faixa de tensões de saída. 58 Tabela 4.5: Características principais do LE33AB. Parâmetro Encapsulamento Baixa corrente quiescente Vout Nominal Capacidade de corrente de saída Valor TO-92 50µA no estado OFF e 0.5mA no estado ON 3.3V 100mA O conector In-Circuit Serial Programming (ICSP) é uma barra de 6 pinos cuja finalidade é gravar o firmware no PIC18F2620. A Tabela 4.6 ilustra os 6 pinos disponíveis bem como a função de cada um deles. Tabela 4.6: Conector ICSP - Pinagem. Pino 1 2 3 4 5 6 4.8 Função VPP VDD - tensão de Alimentação do circuito digital. GND - terra digital PGD - Programável DATA PGC - Programável Clock NC - Não conectado Circuito de Corrente Para capturar a queda de tensão no resistor “shunt” antes de alimentar o MICAz, utilizou-se a estratégia ilustrada na Figura 4.14. Figura 4.14: Circuito de Captura de Corrente. A estratégia foi elaborada com intuito de influenciar o mínimo possível no circuito de alimentação do MICAz. A corrente de que será drenada pelo MICAz percorre antes o resistor de aferição - “shunt”. O circuito está ilustrado na Figura 4.14. A Figura 4.15 ilustra fotos da montagem. As baterias ilustradas na Figura 4.15 são a única fonte de 59 energia do MICAz. A corrente passa pelo circuito de medição, provocando uma queda de tensão no resistor, e retorna para a alimentação do MICAz. Figura 4.15: Fotos do Esquema de Captura de Corrente. A barra de 3 pinos denominada MICAZ_BAT tem por finalidade interceptar a corrente que passa pelo circuito do MICAz fazendo com que circule através do resistor “shunt” produzindo uma queda de tensão na entrada do amplificador diferencial MAX4372F. 4.9 Interface MICAz x Placa de Medição Para conectar a placa de medição ao MICAz, utilizou-se a MDA100CB[17], Sensor Board da Crossbow Technology, Inc., que disponibiliza todos os pinos de acesso ao microcontrolador AVR ATMEGA128L[24] conforme ilustrado na Figura 4.16. Figura 4.16: Sensor Board MDA100CB e Matriz de Prototipação. A barra de 5 pinos ilustrada na Figura 4.17 e denominada MOTE, realiza interface entre o MICAz e a placa de medição de consumo. Cada pino e sua respectiva função pode ser constatado correlacionando a Figura 4.16 com a barra de pinos ilustrada na Figura 4.17. A matriz de interconexão está especificada na Tabela 4.7. Tabela 4.7: Conector MOTE - Pinagem. Linha 10 Coluna A 9 C Função Alimentação do MICAz segundo esquema especificado na figura . I2C - Serial Data. 60 4.10 8 4 C F 14 A I2C - Serial Clock Interrupção externa INT0 do PIC18F2620. Quando este pino vai para nível alto, o microcontrolador PIC realiza um “wakeup” do modo standby para o modo ativo. GND - Terra Captura de Frequência O PIC18F2620 possui o CCP, que é um periférico que pode ser utilizados para três finalidades ilustrados na Tabela 4.8: Tabela 4.8: Modos do CCP. Modo Capture Mode Compare Mode PWM Mode Finalidade Um par de registradores de 8 bits, CCPRXH e CCPRXL, capturam o valor do timer 1 ou timer 3 quando os eventos (borda de subida ou descida) do sinal de entrada ocorrem. O valor do registrador CCPRX é constantemente comparado com timer 1 ou timer 3. Quando este valor coincide com os registradores, pino CCPX do PIC18F2620 poderá realizar as seguintes ações: ir para nível alto, ir para nível baixo ou alternar o nível lógico. O pino CCPX do PIC18F2620 produz um pulso de 10 bits de resolução. No projeto da placa de medição utilizou-se o Modo de Captura, cujo diagrama de blocos está ilustrado na Figura 4.18. No diagrama de blocos da Figura 4.18, nos pinos CCP1 ou CCP2, estão presentes um sinal quadrado que dispara a flag CCP1IF ou CCP2IF na borda de subida ou de descida. O modo de disparo, preescaler e a associação do timer 1 ou timer 3 ao respectivo módulo CCP é configurado através de registradores específicos do PIC18F2620. O timer fica contando e esperando que um evento (“trigguer”) ocorra. Quando isto acontece, a “flag” CCPXIF irá para nível alto e o conteúdo do timer é transferido para o registrador CCPXRH e CCPXRL que forma um número inteiro de 16 bits correspondente ao período da forma de onda de entrada. 61 Figura 4.17: Barra de Pinos para Interconexão Mote x Placa de Medição. Figura 4.18: Diagrama de Blocos do Modo de Captura. 4.11 Máquinas de Estados Esta seção abordará as três máquinas de estados principais do sistema da Placa de Medição. A primeira, Figura 4.19, corresponde ao software embarcado instalado no PIC18F2620, a segunda, Figura 4.20 ,ilustra o funcionamento do periférico CCP (captura de freqüência) e a terceira, Figura 4.21, ilustrará o funcionamento do sistema embarcado do MICAz que é responsável por manter a comunicação e pelas solicitações da potência instantânea através do barramento I2C. Figura 4.19: Máquina de Estados do PIC18F2620. A figura 4.19 ilustra a máquina de estados do PIC18F2620. O Estado inicial corres- 62 ponde à inicialização do dispositivo. Momento em que aplica-se um sinal DC e o dispositivo realiza a ação initPIC() que desempenha as configurações dos periféricos, ajuste dos timers, definições de I/O e põe o dispositivo no modo sleep. No estado 1, o dispositivo permanece no modo sleep até que o MICAz aplique um nível alto no pino INT0, que põe o microcontrolador no modo ativo. O estado 2 aguarda uma solicitação de medição do consumo do MICAz através do barramento I2C. A transição do estado 2 para o estado 3 ocorre quando acontece o evento RxI2C e o dispositivo captura a freqüência nos pinos de tensão e corrente indo para o estado 3. Na transição do estado 3 para o estado 1, o dispositivo envia para o MICAz o valor da potência instantânea e retorna para o modo de operação sleep. Figura 4.20: Máquina de Estados do CCP. A figura 4.20 ilustra a máquina de estados do CCP. O estado inicial corresponde ao momento em que o dispositivo foi alimentado por uma fonte DC e executa a ação configCCP() que atribui valores a registradores, configura timers e o modo de captura. O estado 1 permanece aguardando uma borda de subida do sinal quadrado na entrada do pino de captura e, quando isto acontece, o evento CCPIF sinaliza para o periférico armazenar nos registradores os valores de tensão e corrente através da ação storeCCPRX(). Em seguida, ocorre a transição do estado 2 para o estado 1 que é acompanhada do evento clearCCPIF e a ação resetTimer(), cuja função é zerar o timer de captura e apagar a flag de interrupção. Figura 4.21: Máquina de Estados do MICAz. A figura 4.21 ilustra a máquina de estados do MICAz. O estado inicial corresponde ao momento em que a chave foi colocada no estado ON pelo usuário. O evento Boot é disparado e ocorre a transição do estado inicial para o estado 1. Na transição do estado 1 para 63 o estado 2, é disparado o evento booted e ocorre a ação radioON(), cuja função é ligar o rádio. O estado 2 aguarda a resposta da ação radioON() e, se houver uma falha no rádio, o evento radioFail é disparado resultando na transição do estado 2 para o estado 1. Este processo se repete até que o rádio esteja em condições de operação, o que resulta na transição do estado 2 para o estado 3 através da ação configNode(), cuja função é configurar o barramento I2C, os temporizadores e os pinos de I/O do MICAz. O evento configNodeOk é disparado após a execução da ação configNode() resultando na transição do estado 3 para o estado 4. O estado 4 fica aguardando o overflow do timer e, quando isto acontece, o evento timerFired é disparado e o MICAz executa a ação reqI2CPower(), cuja função é solicitar à placa de medição uma amostra de potência instantânea naquele momento. O estado 5 aguarda uma resposta da placa de medição (waitI2CPower). Quando o MICAz recebe as amostras de tensão e corrente solicitadas, o evento I2CPowerRx é disparado e a ação TxPower() envia, através do rádio, os valores de tensão e corrente obtidos retornando para o estado 4. 64 4.12 Validação da Arquitetura Todos os instrumentos de medição necessitam de um parâmetro de avaliação. Uma avaliação paramétrica fornece os requisitos suficientes para verificar a exatidão e a precisão do instrumento de medida. A placa de medição utiliza dois canais de captura: um para tensão e outro para corrente. Para validação da arquitetura utilizou-se os seguintes equipamentos: 1. Multímetro Minipa Modelo ET1400[13]; 2. Osciloscópio Analógico Modelo:MO-1225[14]; 3. Uma fonte chaveada de PC de 450W; 4. Protoboard de 840 pontos. 5. Potenciômetro de 470Ω; 6. Potenciômetro de 5kΩ; 7. Capacitor eletrolítico 0.47µF; 8. Capacitor eletrolítico 1µF; 9. Regulador de Tensão variável LM317T[16]. 4.12.1 Validação da Tensão Para validação da tensão utilizou-se um regulador de tensão variável LM317 utilizando o circuito proposto de aplicação típica ilustrado na Figura 4.22. Figura 4.22: Diagrama de Blocos do Modo de Captura. Efetuou-se medidas discretas de forma a variar a tensão no intervalo de 3.00 Volts até o limiar de 2.00 Volts. O escopo de tensão foi restrito porque se a bateria indicar uma tensão abaixo 2.10 Volts o nodo não funciona e sua bateria está totalmente descarregada. Uma substituição das baterias é necessária. Logo, não há necessidade de verificar intervalo maior que o especificado na Tabela 4.23. 65 Figura 4.23: Tabela de Variação de tensão em função de Multímetro e Osciloscópio. Conforme podemos observar as colunas na Tabela 4.23, da esquerda para direita, temos: Coluna 1 Número sequencial da medida efetuada; Coluna 2 Valor da tensão no multímetro; Coluna 3 Ciclos de clock da captura. Cada ciclo de clock corresponde a 200nS; Coluna 4 Frequência capturada ( Ciclos de clock da1captura×200E−9 ); Coluna 5 Tensão capturada. Frequência capturada × 10 × 100E3 × 1E − 9; Coluna 6 Desvio. Diferença entre a tensão capturada e a tensão no multímetro; Coluna 7 Valor corrigido. Diferença entre a tensão capturada e a média dos desvios (0.07). da tensão no multímetro × 100). Coluna 8 Erro Relativo Percentual. ( Valor corrigido−Valor Valor corrigido O valor da coluna 7 da Tabela 4.23 foi obtido através da Equação 4.8: Valor corrigido = Tensão capturada − Desvio Médio (4.8) O erro percentual médio foi de 0.2%. O instrumento, com apenas um ajuste, mostrou uma notável exatidão com relação aos dispositivos de medidas paramétricas utilizados. A precisão alcançada pelo instrumento foi de ±0.7 Volts. A Figura 4.24 expõe a relação entre a tensão no multímetro e a tensão capturada pela placa de medição. O valor capturado sempre é maior que o valor medido pelo equipamento de instrumentação. Isto se dá devido a um leve desbalanceamento do resistor de temporização (Rt) do conversor V/F. Apenas subtraindo a tensão capturada pela média dos desvios (0.07) temos um resultado aceitável e realista. 66 Figura 4.24: Relação entre a tensão no multímetro e a tensão capturada. 4.12.2 Validação da Corrente Para validação da corrente utilizou-se regulador de tensão variável LM317 com a mesma configuração proposta na Figura 4.22. Efetuou-se as medidas variando a corrente no intervalo de 1.56mA até 30.60mA. Obtemos os dados registrados na Tabela 4.25. Figura 4.25: Relação entre a corrente no multímetro e a corrente capturada. Conforme podemos observar as colunas na Tabela 4.25, da esquerda para direita, temos: Coluna 1 Número sequencial da medida efetuada; Coluna 2 Valor da corrente no multímetro; Coluna 3 Ciclos de clock da captura. Cada ciclo de clock corresponde a 200nS; Coluna 4 Frequência capturada ( Ciclos de clock da1captura×200E−9 ); 67 × 1000); Coluna 5 Corrente capturada. ( Frequência capturada×10×100E3×1E−9 50 Coluna 6 Desvio. Diferença entre a corrente capturada e a corrente no multímetro; Coluna 7 Valor corrigido. Produto da corrente capturada e a média dos desvios - (0.94). da corrente no multímetro Coluna 8 Erro Relativo Percentual. ( Valor corrigido−Valor × 100). Valor corrigido Na coluna 7 da Tabela 4.25, o valor 50 corresponde ao ganho do amplificador de corrente. A corrente capturada é multiplicada pelo fator 1000 somente para ser ilustrada em unidades de mA. O erro percentual médio foi de 0.89%. O instrumento novamente mostrou-se excelente exatidão com relação aos dispositivos de medidas paramétricas utilizados. A precisão alcançada para medições de corrente foi de ±0.94 mA. A gráfico ilustrado na Figura 4.26 ilustra a relação entre a corrente no amperímetro e a corrente capturada pela placa de medição. Figura 4.26: Relação entre a corrente no multímetro e a corrente capturada. A corrente capturada é sempre maior. Há um comportamento linear observado na captura da corrente, e esta linearidade converge para o valor real à medida que a corrente se aproxima do limiar de “offset” do amplificador de corrente - 1mA. 68 4.13 Esquemático da Placa de Medição Figura 4.27: Diagrama Esquemático da Placa de Medição. 69 4.14 Placa de Circuito Impresso Figura 4.28: Placa de Circuito Impressso - PCB. 70 4.15 Conclusão O circuito da placa de medição foi projetado de maneira que proporcione flexibilidade suficiente para atender os requisitos para aferição do consumo do MICAz, mas também para ser estendido na execução de aferições em outros nós de RSSF, tais como: • Btnode3 • EyesIFX • IntelMote2 • Mica2 • Mica2dot • Telosa e Telosb A faixa dinâmica foi ampliada através do uso de conversores V/F. Utilizou-se um amplificador de instrumentação com largura de faixa de 250KHz e um microcontrolador capaz de capturar eficientemente o consumo do dispositivo, possibilitando análises de longos e curtos períodos. O Capítulo 5, aborda sobre a organização, planejamento integração e obtenção dos resultados obtidos nas medições de consumo. A Figura 4.29 é uma foto do “hardware” de medição desenvolvido acoplado ao MICAz. Figura 4.29: Foto da Placa de Medição. Capítulo 5 Resultados 5.1 Introdução Este capítulo é dedicado à organização, planejamento, integração e obtenção dos resultados obtidos nos testes de campo com a placa de medição. Foram analisados 3 experimentos sendo 2 em função dos protocolos de roteamento Collection[20] e Tymo[7, 19, 58] e 1 consistindo de uma rede com apenas um nó enviando informações de consumo diretamente (1 salto) para a base-station. Os protocolos utilizados[20, 7, 19, 58] são oficialmente incluídos na distribuição do TinyOS 2.x[4, 40]. Não foram utilizados protocolos de terceiros que não fazem parte da árvore oficial de distribuição do TinyOS. O fluxograma de obtenção das medidas de consumo está ilustrado através da Figura 5.1. Figura 5.1: Fluxograma de obtenção de medidas de consumo. A primeira fase consiste na distribuição linear dos nós da RSSF. A segunda etapa compreende a aquisição dos dados originados dos nós através do software TinyOS Terminal que foi desenvolvido exclusivamente para este propósito e será apresentado na Seção 5.3. Na terceira fase os dados coletados são formatados para visualização final em planilha 72 de cálculo e a quarta e última etapa compreende a observação dos resultados obtidos nas medidas. 5.2 Cenário Experimental Para análise dos protocolos de roteamento foi definido um cenário padrão para os testes que consiste de 4 nós, sendo 1 gateway e três nós distribuídos linearmente de forma que o raio de alcance do rádio de cada nó coincida com a interseção do alcance do próximo nó (Figura 5.2). Como cada nó está ao alcance de seu adjacente, quando um necessita enviar um pacote, os nós vizinhos desempenham encaminhamento necessário da mensagem para que a mensagem seja encaminhada ao destino final (base-station). Figura 5.2: Cenário Experimental com detalhes para o raio de alcance de cada nó e rotas de comunicação. A configuração adotada nos testes está também ilustrada através da Figura 5.3, onde podemos vizualizar não só o nó de número 36 que corresponde ao gateway como também os nós 1,2 e 3 responsáveis pelo sensoriamento e envio das informações para o nó 36. Figura 5.3: Cenário Experimental para Teste dos Protocolos de Roteamento A finalidade de cada um dos itens especificado nas Figuras 5.2 e 5.3 são os seguintes: 1. Os nós 1,2 e 3 são responsáveis pelo sensoriamento da RSSF; 2. O nó 36 é a base-station, gateway ou node-sink; 3. As setas são apenas ilustrações das rotas disponíveis; 73 4. O nó 36 está conectado a uma placa de interface denominada MPR2400CB[25, 57] ou MIB; 5. A rota mais curta para que um pacote cuja origem é o nó 3 e o destino o nó 36 é: 3 ⇒ 2 ⇒ 1 ⇒ 36; 6. Os nodos foram distribuídos linearmente com distância fixa de 3 metros. Os nós responsáveis pelo sensoriamento enviam a informação de consumo a cada 3 segundos. A potência do rádio foi ajustada em -5dBm, que corresponde a uma corrente de 13.9mA. 74 5.3 TinyOS Terminal O TinyOS Terminal foi desenvolvido com o propósito de agregar as informações provenientes da RSSF, mostrando os dados recebidos em tempo real. A Figura 5.4 ilustra um “screenshot” do software. Figura 5.4: Software TinyOS Terminal A primeira coluna (“Packet”) ilustra o número sequencial do pacote recebido, a segunda (“Payload”) corresponde aos dados recebidos e a terceira corresponde ao Cyclic redundancy check (CRC)1 . O painel inferior tem a finalidade de escolher a porta serial, selecionar parâmetros da comunicação serial, modificar a forma com que os dados são disponibilizados (hexadecimal ou texto pleno) e uma opção de escrever ou não em um arquivo de “log”. O código fonte desse do TinyOS Terminal está disponível no Apêndice III deste documento. 5.4 Experimento - Nó Individual A Figura 5.5 ilustra uma amostra dos primeiros 10 valores obtidos no experimento prático: O gráfico ilustrado na Figura 5.6 ilustra a relação entre a Corrente e o tempo. O código fonte desse experimento prático está disponível no Apêndice I deste documento. 1 Verificação de redundância cíclica. É um código detector de erros, um tipo de função hash que gera um valor expresso em poucos bits em função de um bloco maior de dados de forma a detectar erros de transmissão. 75 Figura 5.5: Dados de apenas um nó Individual Figura 5.6: Nó Individual - Gráfico. Relação entre a Corrente e o tempo 5.5 Experimento - Protocolo Collection As Figuras 5.7,5.8 e 5.9 ilustram uma amostra dos primeiros 10 valores obtidos no experimento prático: Figura 5.7: Protocolo Collection Dados do Nó 1 O Gráfico 5.10 ilustra a relação entre a potência e o tempo dos 3 nós através de 3 séries. O código fonte desse experimento pratico está disponível no Apêndice II deste documento. 76 Figura 5.8: Protocolo Collection Dados do Nó 2 Figura 5.9: Protocolo Collection Dados do Nó 3 Figura 5.10: Protocolo Collection Gráfico. Relação entre a potência e o tempo dos 3 nós 5.6 Experimento - Protocolo Tymo As Figuras 5.11,5.12 e 5.13 ilustram uma amostra dos primeiros 10 valores obtidos no experimento prático: O Gráfico 5.14 ilustra a relação entre a potência e o tempo dos 3 nós através de 3 séries. O código fonte desse experimento pratico está disponível no Apêndice V deste documento. 77 Figura 5.11: Protocolo Tymo Dados do Nó 1 Figura 5.12: Protocolo Tymo Dados do Nó 2 Figura 5.13: Protocolo Tymo Dados do Nó 3 Figura 5.14: Protocolo Tymo Gráfico. Relação entre a potência e o tempo dos 3 nós 78 5.7 Conclusão Analisando o experimento da Seção 5.4, verificou-se que o consumo do rádio fica em torno de 13.9mA, conforme o “datasheet” do CC2420[31] e o nível de potência escolhida de -5dBm. Este experimento foi realizado somente para verificação do consumo de um nó individual onde não há recepção mas sim transmissão de pacotes e também não foi implementado um protocolo de roteamento. Ao observar o consumo nos experimentos realizados com os protocolos de roteamento através das Seções 5.5 e 5.6, notou-se um aumento considerável no consumo. Este aumento do consumo se deve a três fatores: 1. O software embarcado instalado para descoberta e manutenção de rotas; 2. A recepção e transmissão de pacotes; 3. Transmissão e Recepção de pacotes de controle do protocolo de roteamento. O protocolo Tymo[7, 19, 58] perdeu 10 pacotes no momento que o nó 3 foi ligado. Este fator é de bastante importância uma vez que, no momento que o nó começa a fazer parte da rede, há normalmente um período de latência para o estabelecimento das rotas. Este período depende da implementação do protocolo de roteamento e pode ser longo ou curto e também é intrínseco a diversos fatores tais como: distância, alcance, distribuição dos nós, densidade da rede e potência do rádio. O protocolo Collection [20] apresentou boa estabilidade no consumo, transmissão e recepção de pacotes e manutenção das rotas. Este protocolo, de acordo com a TEP119[20], é baseado no módulo LinkEstimatorP[4, 40], o qual vincula a transmissão e recepção dos pacotes através da qualidade do “link” dos nós vizinhos. Por isso que tanto o nó 2 quanto o nó 3 apresentam um número de saltos menor no início do experimento e logo depois a rota mais coerente é estabelecida (Figuras 5.8 e 5.9). Observa-se um consumo maior entre os nós 1 e 2 nos respectivos experimentos das Seções 5.5 e 5.6. Este consumo adicional se deve à recepção, transmissão e interceptação dos pacotes que os referidos protocolos desempenham. O protocolo Tymo, apesar da latência ocasionando a perda dos pacotes no início do experimento, apresentou uma potência média menor e portanto minimizando o consumo de energia do nodo de RSSF. Sob o ponto de vista de eficiência energética e levando em consideração a simplicidade do experimento prático adotado, observou-se que o Tymo se mostrou mais econômico no consumo de energia. O código fonte desse experimento pratico está disponível nos Apêndice I,II e IV deste documento. Capítulo 6 Considerações Finais 6.1 Conclusão O dispositivo de medição proposto neste documento atendeu aos requisitos para efetuar medições do consumo de energia em RSSF. Estabilidade, simplicidade, baixo custo e fácil integração são algumas de suas características. O esquema de sensoriamento de corrente possuem uma banda de 250Khz. Isto é muito mais do que os 40Khz citados por JIANG et al.. Utilizou-se um dispositivo eletrônico analógico para converter amostras de tensão e cobrir a faixa dinâmica típica dos motes. O microcontrolador utilizado opera com um relógio 3 vezes mais rápido que o mote além de possuir um periférico integrado para medir frequências, o CCP. Isto facilitou bastante a captura do trem de pulsos fornecido pelo conversor V/F utilizado. As ferramentas de “debugger” fornecidas pelo TinyOS trabalham em modo texto (console), não são nada intuitivas e sempre possuem caráter específico e limitado de cada aplicação. O TinyOS terminal, com sua interface gráfica e intuitiva, é um projeto inédito, foi projetado com o propósito geral de agregar as informações provenientes da RSSF e comunicar-se com com a base-station. Através desse aplicativo é possível coletar os dados que chegam da rede e comunicar-se efetivamente com qualquer dispositivo que faça parte da árvore de distribuição nodal da WSN. Este aplicativo ainda encontra-se em fase de desenvolvimento. O mecanismo de medição do consumo foi desenvolvido com flexibilidade suficiente para ser extendido a outras plataformas tais como: • Telefones celulares; • PDA´s; • “Laptops”; • Outras plataformas de RSSF. Os protocolos de roteamento analisados fazem parte da distribuição oficial do TinyOS[4] e são considerados hoje “estado do conhecimento”. A análise individual dos protocolos de roteamento foi desempenhada considerando o consumo de energia, descoberta e manutenção das rotas e a latência. Isto possibilita uma escolha correta do protocolo de roteamento em função do tipo de aplicação para RSSF. 80 Finalmente, este trabalho somou esforços no projeto de um “hardware” de medição com a finalidade de aferir o consumo em WSN e avaliou conjuntamente os principais protocolos de roteamento existentes. Isto viabilizou uma contribuição tanto para a comunidade científica quanto para a ciência. 6.2 Trabalhos Futuros A placa de medição pode ser extendida a outras plataformas. Portanto, há uma lacuna a ser preenchida porque diferentes plataformas apresentam consumos de energia divergentes. São dispositivos com características e componentes eletrônicos diferentes do MICAz. Também devem ser avaliados quanto ao consumo de energia e a aplicação de roteamento. Segundo JIANG et al. e TRATHNIGG; WEISS, simuladores como o PowerTOSSIM[54], AEON[38] e AVRORA[59] possuem um modelo de estimativa de consumo limitado. Fatores importantes no consumo de um nodo são por eles negligenciados além das generalizações com as diferentes plataformas. O hardware de medição desenvolvido neste trabalho pode ser utilizado para aperfeiçoar esses modelos de simulações, tornando assim os seus resultados o mais próximo possível da realidade. Novos protocolos de roteamento podem ser avaliados. O hardware de medição pode ser utilizado para avaliações mais longas, criteriosas e eficientes. 81 Referências [1] AMERICA, K. Kokam 603870H. Último acesso em 23/04/2009, http://www. kokamamerica.com/ka/rc.aspx. [2] ANALOG DEVICES, I. AD654- Datasheet. Último acesso em 29/05/2009, http://www.analog.com/static/imported-files/data_sheets/ AD654.pdf. [3] BARRETT, S. F.; PACK, D. Atmel AVR Microcontroller Primer: programming and interfacing (synthesis lectures on digital circuits and systems). [S.l.]: Morgan & Claypool Publishers, 2002. [4] BERKELEY, U. TinyOS Community Forum. [Online; acessado em 18/08/2009], http://www.tinyos.net/. [5] BORGES, L.; CARVALHO, L.; CRUZ, D. Sistemas Operacionais para Redes de Sensores. 2008. [6] BREWER, E.; CULLER, D.; GAY, D.; LEVIS, P.; BEHREN, R. von; WELSH, M. nesC: a programming language for deeply networked systems. [Online; acessado em 09/09/2009], http://nescc.sourceforge.net/. [7] CHAKERES, I.; PERKINS, C. Dynamic MANET On-demand DYMO routing. [Online; acessado em 11/10/2009], http://tools.ietf.org/html/ draft-ietf-manet-dymo-04. [8] COLORADO, U. of. MANTIS project Site. [Online; acessado em 10/10/2010], http://mantis.cs.colorado.edu/index.php/tiki-index.php. [9] COMPANY, M. P. Molex Connectors, Interconnects and Cable Assemblies. [Online; acessado em 12/01/2010], http://www.molex.com. [10] COMPANY, P. I. Alkaline Battery Specification. [S.l.: s.n.], 2005. [Online; acessado em 03/09/2009]. [11] COMPUTER, C. Eagle Layout Editor. [S.l.: s.n.], 2009. [Online; acessado em 19/12/2009]. [12] COMPUTER SCIENCE (SICS), S. I. of. The Contiki Operating System Site. [Online; acessado em 10/10/2010], http://www.tinyos.net/. [13] COMéRCIO, M. I. e. Multímetro Digital Modelo:et-1400. último acesso em 01/02/2010, http://www.minipa.com.br/Produtos/DetailsProduct. aspx?id=184. 82 [14] COMéRCIO, M. I. e. Osciloscópio Analógico Modelo:mo-1225. último acesso em 01/02/2010, http://www.minipa.com.br/produtos/DetailsProduct. aspx?id=154. [15] CORPORATION, A. 4-megabit 2.5-volt or 2.7-volt DataFlash. [S.l.: s.n.], 2008. [Online; acessado em 13/01/2010]. [16] CORPORATION, N. S. 3-Terminal Adjustable Regulator. último acesso em 01/02/2010, http://www.national.com/mpf/LM/LM317.html# Overview. [17] CROSSBOW TECHNOLOGY, I. MTS/MDA Sensor Board Users Manual. Último acesso em 21/12/2009, http://www.xbow.com/Support/Support_ pdf_files/MTS-MDA_Series_Users_Manual.pdf. [18] DAWSON-HAGGERTY, S.; GNAWALI, O.; GAY, D.; LEVIS, P.; MUSALOIUE., R.; KLUES, K.; REGEHR, J. TinyOS 2.1. [Online; acessado em 09/09/2009], http://docs.tinyos.net/index.php/Ipsn2009-tutorial. [19] FERNANDES, N. C. Resumo: dynamic manet on-demand routing protocol -dymo. Programa de Engenharia Elétrica (PEE) - UFRJ, [S.l.], 2008. [Online; acessado em 11/10/2009]. [20] FONSECA, R.; GNAWALI, O.; JAMIESON, K.; LEVIS, P. TEP119 - Collection. [Online; acessado em 01/10/2009], http://www.tinyos.net/tinyos-2.1. 0/doc/html/tep119.html. [21] GINATTO, A. L. Otimização do tempo de vida em redes de sensores sem fio utilizando algoritmo de energia e protocolo difusão direcionada. [S.l.]: Universidade de São Paulo, Escola de Engenharia de São Carlos, São Carlos, SP, 2008. [22] GROUP, H. E. Electrical and Electronic Connectors - Hirose Electric. [Online; acessado em 09/09/2009], http://www.hirose.com/. [23] IBRAHIM, D. Advanced PIC Microcontroller Projects in C - From USB to RTOS with the PIC18F Series. [S.l.]: Elsevier Ltd., 2008. [24] INC., A. C. 8-bit AVR Microcontroller with 128K Bytes In-System Programmable Flash (Datasheet). [S.l.: s.n.], 2009. [Online; acessado em 03/09/2009]. [25] INC, C. T. MPR MIB Users Manual. [Online; acessado em 30/09/2009], http: //www.xbow.com. [26] INC., M. T. PIC18F2525/2620/4525/4620 Data Sheet. Último acesso em 19/12/2009, http://ww1.microchip.com/downloads/en/DeviceDoc/ 39626e.pdf. [27] INC., M. T. What is nanoWatt Technology? Último acesso em 19/12/2009, http://ww1.microchip.com/downloads/en/Market_ Communication/nanowatt1jan03.pdf. [28] INCORPORATED, T. I. Getting Started with Current Sensing. [Online; acessado em 16/11/2009], http://focus.ti.com/analog/docs/. 83 [29] INCORPORATED, T. I. SmartRF Studio. último acesso em 01/02/2010, http://focus.ti.com/docs/toolsw/folders/print/ smartrftm-studio.html. [30] INCORPORATED, T. I. SmartRF Protocol Packet Sniffer. último acesso em 01/02/2010, http://focus.ti.com/docs/toolsw/folders/print/ packet-sniffer.html. [31] INSTRUMENTS, T. 2.4 GHz IEEE 802.15.4 / ZigBee-ready RF Transceiver (Datasheet). [S.l.: s.n.], 2008. [Online; acessado em 03/09/2009]. [32] JIANG, X.; DUTTA, P.; CULLER, D.; STOICA, I. Micro Power Meter for Energy Monitoring of Wireless Sensor Networks at Scale. The Sixth International Conference on Information Processing in Sensor Networks (IPSN07) Track on Sensor Platforms, Tools, and Design Methods (SPOTS07), [S.l.], 2007. [33] JúNIOR, A. P. Amplificadores Operacionais e Filtros Ativos - Teoria, Projetos, Aplicações e Laboratório. [S.l.]: Makron Books, 1996. [34] KIM, S.; PAKZAD, S.; CULLER, D.; DEMMEL, J.; FENVES, G.; GLASER, S.; TURON, M. Structural Health Monitoring of the Golden Gate Bridge. Último acesso em 12/01/2010, http://www.eecs.berkeley.edu/ ~binetude/ggb/. [35] KIM, S.; PAKZAD, S.; CULLER, D.; DEMMEL, J.; FENVES, G.; GLASER, S.; TURON, M. Health monitoring of civil infrastructures using wireless sensor networks. In: IPSN ’07: PROCEEDINGS OF THE 6TH INTERNATIONAL CONFERENCE ON INFORMATION PROCESSING IN SENSOR NETWORKS, 2007, New York, NY, USA. Anais. . . ACM, 2007. p.254–263. [36] KRAMER, M.; GERALDY, A. Energy Measurements for MicaZ Node. University of Kaiserslautern, Germany, [S.l.], 2006. Último acesso em 23/04/2009. [37] LAB, H. S. N. Volcano Monitoring. Último acesso em 30/08/2009, http:// fiji.eecs.harvard.edu/Volcano. [38] LANDSIEDEL, O.; WEHRLE, K.; RIECHE, S.; GOETZ, S.; PETRAK, L. Projet AEON. 4th GI/ITG KuVS Fachgespräch - Wireless Sensor Networks. ETH Zurich, [S.l.], 2005. [39] LEES, J. M.; JOHNSON, J. B.; RUIZ, M.; TRONCOSO, L.; WELSH, M. Reventador Volcano 2005: eruptive activity inferred from seismo-acoustic observation. 2007. [40] LEVIS, P.; GAY, D. TinyOS Programming. 1.ed. [S.l.]: Cambridge University Press, 2009. [41] LI, Y.; THAI, M. T.; WU, W. Wireless Sensor Networks and Applications. [S.l.]: Springer Science+Business Media, LLC, 2008. [42] LOUREIRO, A. A. F. Redes de Sensores Sem Fio. Último acesso em 01/02/2010, http://www.ic.unicamp.br/~cmbm/desafios_SBC/ loureiroredesensores.pdf. 84 [43] LOUREIRO, A. A.; NOGUEIRA, J. M. S.; RUIZ, L. B.; FREITAS, R. A. de. Redes de Sensores Sem Fio. Último acesso em 31/08/2009, http://homepages.dcc. ufmg.br/~loureiro/cm/docs/sbrc03.pdf. [44] LTD., F. T. D. I. FT2232C Dual USB UART/FIFO Integrated Circuit. [S.l.: s.n.], 2005. [Online; acessado em 13/01/2010]. [45] MAXIM, D. S. 1-Cell to 2-Cell, Low-Noise, High-Efficiency, Step-Up DC-DC Converter. [S.l.: s.n.], 1998. [Online; acessado em 13/01/2010]. [46] MEHTA, A. Understand low-side vs. high-side current sensing. [Online; acessado em 16/11/2009], http://www.analog-europe.com/howto/ 215801634. [47] MORTON, J. AVR: an introductory course. [S.l.]: Newnes, 2002. [48] PERKINS, C.; BELDING-ROYER, E.; DAS, S. Ad hoc On-Demand Distance Vector (AODV) Routing. 2003. [49] PRODUCTS, M. I. High-Side Current-Sense Measurement: circuits and principles. [Online; acessado em 16/11/2009], http://pdfserv.maxim-ic.com/ en/an/AN746.pdf. [50] PRODUCTS, M. I. Low-Cost, UCSP/SOT23, Micropower, High-Side CurrentSense Amplifier with Voltage Output. [Online; acessado em 16/11/2009], http: //datasheets.maxim-ic.com/en/ds/MAX4372-MAX4372T.pdf. [51] REZENDE, J. F. de. Redes de Sensores sem Fio. Último acesso em 30/08/2009, http://www.gta.ufrj.br/~rezende/cursos/eel879/trabalhos/ rssf1/. [52] RUIZ, L. B.; CORREIA, L. H. A.; VIEIRA, L. F. M.; MACEDO, D. F. Arquiteturas para Redes de Sensores Sem Fio. [S.l.]: Departamento de Ciência da Computação da UFMG, 2004. [53] SEMICONDUCTORS., N. I2C-Bus: what’s that? 09/09/2009], http://www.i2c-bus.org/. [Online; acessado em [54] SHNAYDER, V.; HEMPSTEAD, M.; CHEN, B.; ALLEN, G. W.; WELSH, M. Simulating the Power Consumption of LargeScale Sensor Network Applications. último acesso em 20/04/2009, http://www.eecs.harvard.edu/~shnayder/ papers/sensys04ptossim.pdf. [55] SOHRABY, K.; MINOLI, D.; ZNATI, T. WIRELESS SENSOR NETWORKS: technology, protocols, and applications. [S.l.]: John Wiley and Sons, INC., Publication, 2007. [56] STMICROELECTRONICS. Very low drop voltage regulators with inhibit. Último acesso em 19/12/2009, http://www.st.com/stonline/products/ literature/od/2573/le33ab.pdf. [57] TECHNOLOGY, C. MICAz Datasheet. [Online; acessado em 02/09/2009]. 85 [58] THOUVENIN, R. Implementing and Evaluating the Dynamic Manet Ondemand Protocol in Wireless Sensor Networks. 2007. Dissertação (Mestrado em Ciência da Computação) — University of Aarhus, Dinamarca. [59] TITZER, B. L.; LEE, D. K.; PALSBERG, J. Avrora: scalable sensor network simulation with precise timing. In: IPSN ’05: PROCEEDINGS OF THE 4TH INTERNATIONAL SYMPOSIUM ON INFORMATION PROCESSING IN SENSOR NETWORKS, 2005, Piscataway, NJ, USA. Anais. . . IEEE Press, 2005. p.67. [60] TOCCI, R. J. Digital systems: principles and applications. [S.l.]: Prentice Hall, 1995. [61] TRATHNIGG, T.; WEISS, R. A Runtime Energy Monitoring System for Wireless Sensor Networks. In: INTERNATIONAL SYMPOSIUM ON WIRELESS PERVASIVE COMPUTING, 3., 2008, Santorini,Greece. Proceedings. . . IEEE, 2008. p.21– 25. [62] WERNER-ALLEN, G.; JOHNSON, J.; RUIZ, M.; LEES, J.; WELSH, M. Monitoring Volcanic Eruptions with a Wireless Sensor Network. In: PROCEEDINGS OF THE SECOND EUROPEAN WORKSHOP ON WIRELESS SENSOR NETWORKS EWSN 05, 2005. Anais. . . [S.l.: s.n.], 2005. [63] WERNER-ALLEN, G.; LORINCZ, K.; JOHNSON, J.; LEES, J.; WELSH, M. Fidelity and Yield in a Volcano Monitoring Sensor Network. In: FIDELITY AND YIELD IN A VOLCANO MONITORING SENSOR NETWORK OSDI 06, 2006. Anais. . . USENIX Association, 2006. p.381–396. [64] WIKIPéDIA. Tacoma Narrows Bridge. Último acesso em 12/01/2010, http:// pt.wikipedia.org/w/index.php?title=BibTeX&oldid=4879810. Apêndice I Código fonte do Experimento - No Individual Código 7 .1: Makefile 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 # ############################################## # U n i v e r s i d a d e de Pernambuco − UPE # D e p a r t a m e n t o de S i s t e m a s e Computacao − DSC # P r o g r a m a de Academico em E n g e n h a r i a da Computacao # O r i e n t a d o r : P r o f . Abel G u i l h e r m i n o da S i l v a F i l h o # Co−o r i e n t a d o r : P r o f . R e n a t o M a r i z de Moraes # Aluno : F r e d e r i c o Cox # ############################################## # Makefile # ############################################## # V a r i a v e i s de a m b i e n t e COMPONENT=ShortTimeAppC CFLAGS += −I $ ( TOSDIR ) / l i b / n e t / −I $ ( TOSDIR ) / l i b / n e t / c t p / net /4 b i t l e # ############################################ # D e f i n i c o e s para o r a d i o − Canal e P o t e n c i a # ############################################ # PA_LEVEL [dBm] C u r r e n t C o n s u m p t i o n [mA] # 31 0 17.4 # 27 −1 16.5 # 23 −3 15.2 # 19 −5 13.9 # 15 −7 12.5 # 11 −10 11.2 # 7 −15 9.9 # 3 −25 8.5 # ############################################ PFLAGS += −DCC2420_DEF_RFPOWER=31 # ############################################ # IEEE 8 0 2 . 1 5 . 4 e s p e c i f i c a 16 c a n a i s # n u m e r a d o s de 11 a 26 # ############################################ PFLAGS += −DCC2420_DEF_CHANNEL=26 # ############################################ −I $ ( TOSDIR ) / l i b 87 40 41 42 43 44 45 i f d e f APP_MAKERULES i n c l u d e $ (APP_MAKERULES) else i n c l u d e $ (MAKERULES) endif # ############################################ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 /∗ ∗ =============================================== ∗ U n i v e r s i d a d e de Pernambuco − UPE ∗ D e p a r t a m e n t o de S i s t e m a s e Computacao − DSC ∗ Programa de Academico em E n g e n h a r i a da Computacao ∗ O r i e n t a d o r : P r o f . A b e l G u i l h e r m i n o da S i l v a F i l h o ∗ Co−o r i e n t a d o r : P r o f . R e n a t o M a r i z de Moraes ∗ A l u n o : F r e d e r i c o Cox ∗ =============================================== ∗ ∗ ∗ . : : A n a l i s e Nodal de E n e r g i a em : : . ∗ .:: R e d e s de S e n s o r e s sem F i o : : . ∗ ∗ ∗/ Código 7 .2: Global.h # i f n d e f GLOBAL_H # d e f i n e GLOBAL_H /∗ ∗ E n d e r e c o do gateway , i d e n t i f i c a d o r ∗ de mensagem do r a d i o e I2C S l a v e ∗/ enum { RADIO_MSG_ID = 6 }; /∗ ∗ E s t r u t u r a da mensagem do r a d i o ∗/ t y p e d e f n x _ s t r u c t RadioMsg { nx_uint16_t contador ; } RadioMsg_t ; # e n d i f / ∗ GLOBAL_H ∗ / Código 7 .3: ShortTimeM.nc 1 2 # include " Global . h" 3 4 module ShortTimeM { 5 uses { 6 i n t e r f a c e Boot ; 7 i n t e r f a c e Leds ; 8 i n t e r f a c e Timer < T M i l l i > a s F l a s h L e d ; 9 interface Packet ; 10 i n t e r f a c e AMSend a s RadioTx ; 88 11 i n t e r f a c e AMPacket ; 12 i n t e r f a c e S p l i t C o n t r o l as RadioControle ; 13 i n t e r f a c e R e c e i v e a s RadioRx ; 14 } 15 } 16 i m p l e m e n t a t i o n { 17 message_t pkt ; 18 RadioMsg_t ∗ r a d i o P o i n t e r ; 19 uint16_t contador = 0; 20 21 e v e n t v o i d Boot . b o o t e d ( ) { 22 c a l l RadioControle . s t a r t ( ) ; 23 } 24 25 event void RadioControle . s t a r t D o n e ( e r r o r _ t e r r o r ) { 26 i f ( e r r o r ! =SUCCESS ) { 27 c a l l RadioControle . s t a r t ( ) ; 28 } else { 29 c a l l FlashLed . s t a r t P e r i o d i c (500) ; 30 } 31 } 32 33 34 e v e n t v o i d R a d i o C o n t r o l e . s t o p D o n e ( e r r o r _ t e r r o r ) {} 35 36 e v e n t v o i d RadioTx . sendDone ( m e s s a g e _ t ∗msg , e r r o r _ t e r r o r ) { 37 i f ( e r r o r ==SUCCESS ) { 38 c a l l Leds . led0On ( ) ; 39 c a l l RadioControle . stop ( ) ; 40 c a l l FlashLed . stop ( ) ; 41 } 42 } 43 44 event void FlashLed . f i r e d ( ) { 45 r a d i o P o i n t e r = ( RadioMsg_t ∗ ) ( c a l l P a c k e t . g e t P a y l o a d (& p k t , NULL) ) ; 46 r a d i o P o i n t e r −> c o n t a d o r = c o n t a d o r ; 47 c a l l RadioTx . s e n d (AM_BROADCAST_ADDR,& p k t , s i z e o f ( RadioMsg_t ) ) ; 48 c o n t a d o r ++; 49 / / c a l l Leds . l e d 2 T o g g l e ( ) ; 50 } 51 52 e v e n t m e s s a g e _ t ∗ RadioRx . r e c e i v e ( m e s s a g e _ t ∗msg , v o i d ∗ p a y l o a d , u i n t 8 _ t tamanho ) { 53 / / c a l l Leds . l e d 1 T o g g l e ( ) ; 54 r e t u r n msg ; 55 } 56 } Código 7 .4: ShortTimeAppC.nc 1 2 # include " Global . h" 3 4 c o n f i g u r a t i o n ShortTimeAppC {} 5 6 implementation { 7 components MainC , ShortTimeM , LedsC , A c t i v e M e s s a g e C ; 8 components new T i m e r M i l l i C ( ) a s F l a s h L e d ; 89 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 } components new AMSenderC ( RADIO_MSG_ID ) ; components new AMReceiverC ( RADIO_MSG_ID ) ; ShortTimeM . Boot −>MainC . Boot ; ShortTimeM . Leds −>LedsC ; ShortTimeM . F l a s h L e d −>F l a s h L e d ; /∗ ∗ W i r i n g do R a d i o ∗/ ShortTimeM . R a d i o C o n t r o l e −>A c t i v e M e s s a g e C ; ShortTimeM . P a c k e t −>AMSenderC ; ShortTimeM . RadioTx −>AMSenderC ; ShortTimeM . AMPacket−>AMSenderC ; ShortTimeM . RadioRx −>AMReceiverC ; Apêndice II Código fonte do Experimento - Collection Código 8 .1: Makefile 1 # ############################################################################# 2 3 4 5 6 7 8 # # # # # # # U n i v e r s i d a d e de Pernambuco − UPE D e p a r t a m e n t o de S i s t e m a s e Computacao − DSC P r o g r a m a de Academico em E n g e n h a r i a da Computacao O r i e n t a d o r : P r o f . Abel G u i l h e r m i n o da S i l v a F i l h o Co−o r i e n t a d o r : P r o f . R e n a t o M a r i z de Moraes Aluno : F r e d e r i c o Cox ############################################################################# 9 # Makefile 10 # ############################################################################# 11 12 13 14 15 16 17 # # # # # # # $ A u t h o r : F r e d Cox $ $Rev : 70 $ $ D a t e : 2008−12−19 1 6 : 2 0 : 5 1 −0200 ( Sex , 19 Dez 2 0 0 8 ) $ $ I d : T i n y O S _ P l u g i n _ M a k e f i l e 70 2008−12−19 1 8 : 2 0 : 5 1 Z F r e d Cox $ ############################################################################# 18 # V a r i a v e i s de a m b i e n t e 19 20 COMPONENT=BaseAppC 21 22 CFLAGS += −I $ ( TOSDIR ) / l i b / n e t / −I $ ( TOSDIR ) / l i b / n e t / c t p / net /4 b i t l e 23 24 25 # ############################################ 26 # D e f i n i c o e s p a r a o r a d i o − C a n a l e P o t e n c i a 27 # ############################################ 28 # PA_LEVEL [dBm] C u r r e n t C o n s u m p t i o n [mA] 29 # 31 0 17.4 30 # 27 −1 16.5 31 # 23 −3 15.2 −I $ ( TOSDIR ) / l i b 91 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 # 19 −5 13.9 # 15 −7 12.5 # 11 −10 11.2 # 7 −15 9.9 # 3 −25 8.5 # ############################################ PFLAGS += −DCC2420_DEF_RFPOWER=19 # ############################################ # IEEE 8 0 2 . 1 5 . 4 e s p e c i f i c a 16 c a n a i s # n u m e r a d o s de 11 a 26 # ############################################ PFLAGS += −DCC2420_DEF_CHANNEL=26 # ############################################ # I n c l u e a b i b l i o t e c a p r i n t f NOVA CFLAGS += −I $ ( TOSDIR ) / l i b / p r i n t f / 2 _0_2 # ############################################ # Aumenta o p a y l o a d do p r i n t f # ############################################ CFLAGS +=−DTOSH_DATA_LENGTH=80 # ############################################ # I n c l u e S u p o r t e a p l a c a MDA100 CFLAGS += −I $ ( TOSDIR ) / s e n s o r b o a r d s / mda100 / CFLAGS += −I $ ( TOSDIR ) / s e n s o r b o a r d s / mda100 / cb # ############################################ i f d e f APP_MAKERULES i n c l u d e $ (APP_MAKERULES) else i n c l u d e $ (MAKERULES) endif # ############################################ Código 8 .2: Global.h 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 /∗ ∗ =============================================== ∗ U n i v e r s i d a d e de Pernambuco − UPE ∗ D e p a r t a m e n t o de S i s t e m a s e Computacao − DSC ∗ Programa de Academico em E n g e n h a r i a da Computacao ∗ O r i e n t a d o r : P r o f . A b e l G u i l h e r m i n o da S i l v a F i l h o ∗ Co−o r i e n t a d o r : P r o f . R e n a t o M a r i z de Moraes ∗ A l u n o : F r e d e r i c o Cox ∗ =============================================== ∗ ∗ ∗ . : : A n a l i s e Nodal de E n e r g i a em : : . ∗ .:: R e d e s de S e n s o r e s sem F i o : : . ∗ ∗ ∗/ # i f n d e f GLOBAL_H # d e f i n e GLOBAL_H /∗ ∗ E s t r u t u r a da mensagem do r a d i o 92 23 ∗ / 24 t y p e d e f n x _ s t r u c t RadioMsg { 25 n x _ u i n t 1 6 _ t origem ; 26 nx_uint16_t perdas ; 27 nx_uint16_t saltos ; 28 n x _ u i n t 1 6 _ t temp ; 29 nx_uint16_t foto ; 30 nx_uint8_t potencia [16]; 31 nx_uint16_t contador ; 32 } RadioMsg_t ; 33 34 # e n d i f / ∗ GLOBAL_H ∗ / Código 8 .3: BaseC.nc 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 /∗ ∗ =============================================== ∗ U n i v e r s i d a d e de Pernambuco − UPE ∗ D e p a r t a m e n t o de S i s t e m a s e Computacao − DSC ∗ Programa de Academico em E n g e n h a r i a da Computacao ∗ O r i e n t a d o r : P r o f . A b e l G u i l h e r m i n o da S i l v a F i l h o ∗ Co−o r i e n t a d o r : P r o f . R e n a t o M a r i z de Moraes ∗ A l u n o : F r e d e r i c o Cox ∗ =============================================== ∗ ∗ ∗ . : : A n a l i s e Nodal de E n e r g i a em : : . ∗ .:: R e d e s de S e n s o r e s sem F i o : : . ∗ ∗ ∗/ # include " Global . h" # include " p r i n t f . h" module BaseC { uses { interface interface interface interface Boot ; Leds ; S p l i t C o n t r o l as P r i n t f C o n t r o l ; PrintfFlush ; i n t e r f a c e Timer < T M i l l i > a s F l a s h L e d ; interface interface interface interface interface S p l i t C o n t r o l as RadioControl ; StdControl as C o l l e c t i o n C o n t r o l ; RootControl ; Receive ; CollectionPacket ; } } implementation { u n s i g n e d char b u f f e r [ 1 6 ] ; message_t sndBuffer ; RadioMsg_t ∗ r a d i o P o i n t e r ; e v e n t v o i d Boot . b o o t e d ( ) { 93 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 } c a l l RadioControl . s t a r t ( ) ; } event void RadioControl . s t a r t D o n e ( e r r o r _ t e r r o r ) { i f ( e r r o r ! =SUCCESS ) { c a l l RadioControl . s t a r t ( ) ; } else { call CollectionControl . start () ; c a l l RootControl . setRoot ( ) ; c a l l FlashLed . s t a r t P e r i o d i c (500) ; call PrintfControl . start () ; } } e v e n t m e s s a g e _ t ∗ R e c e i v e . r e c e i v e ( m e s s a g e _ t ∗msg , v o i d ∗ p a y l o a d , uint8_t len ) { RadioMsg_t ∗ RadioMsg = ( RadioMsg_t ∗ ) p a y l o a d ; RadioMsg−> s a l t o s ++; memcpy ( b u f f e r ,& RadioMsg−> p o t e n c i a [ 2 ] , ( s i z e o f ( b u f f e r ) −2) ) ; p r i n t f ( "%u;%u;%u;%u;%u;%u;% s \ r \ n " , RadioMsg−>origem , RadioMsg−> s a l t o s , RadioMsg−>p e r d a s , RadioMsg−>temp , RadioMsg−>f o t o , RadioMsg−>c o n t a d o r , buffer ); call PrintfFlush . flush () ; r e t u r n msg ; } e v e n t v o i d R a d i o C o n t r o l . s t o p D o n e ( e r r o r _ t e r r o r ) {} event void FlashLed . f i r e d ( ) { c a l l Leds . l e d 2 T o g g l e ( ) ; } event void P r i n t f C o n t r o l . stopDone ( e r r o r _ t e r r o r ) { } event void P r i n t f C o n t r o l . s t a r t D o n e ( e r r o r _ t e r r o r ) { i f ( e r r o r ! =SUCCESS ) { call PrintfControl . start () ; } else { p r i n t f ( " S e r v i c o s ok . . . \ r \ n " ) ; call PrintfFlush . flush () ; } } event void P r i n t f F l u s h . flushDone ( e r r o r _ t e r r o r ) { } 94 Código 8 .4: NodeAppC.nc 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 /∗ ∗ =============================================== ∗ U n i v e r s i d a d e de Pernambuco − UPE ∗ D e p a r t a m e n t o de S i s t e m a s e Computacao − DSC ∗ Programa de Academico em E n g e n h a r i a da Computacao ∗ O r i e n t a d o r : P r o f . A b e l G u i l h e r m i n o da S i l v a F i l h o ∗ Co−o r i e n t a d o r : P r o f . R e n a t o M a r i z de Moraes ∗ A l u n o : F r e d e r i c o Cox ∗ =============================================== ∗ ∗ ∗ . : : A n a l i s e Nodal de E n e r g i a em : : . ∗ .:: R e d e s de S e n s o r e s sem F i o : : . ∗ ∗ ∗/ # include " Global . h" # include " p r i n t f . h" c o n f i g u r a t i o n NodeAppC{ } implementation { components MainC , ActiveMessageC , MicaBusC , LedsC , NodeC ; components C o l l e c t i o n C ; components new C o l l e c t i o n S e n d e r C ( RADIO_ID ) ; components new T i m e r M i l l i C ( ) a s I2CTimer ; components new T i m e r M i l l i C ( ) a s RxTimer ; components new T i m e r M i l l i C ( ) a s F l a s h L e d ; components new Atm128I2CMasterC ( ) ; components new TempC ( ) ; components new PhotoC ( ) ; NodeC . Boot −>MainC . Boot ; NodeC . Leds −>LedsC . Leds ; NodeC . F l a s h L e d −>F l a s h L e d ; NodeC . I2CTimer −>I2CTimer ; NodeC . RxTimer−>RxTimer ; NodeC . TempSensor −>TempC ; NodeC . F o t o S e n s o r −>PhotoC ; /∗ ∗ I2C W i r i n g ∗/ NodeC . R e s o u r c e −>Atm128I2CMasterC ; NodeC . I 2 C P a c k e t −>Atm128I2CMasterC ; NodeC . wakeUpPIC−>MicaBusC . PW2 ; /∗ ∗ W i r i n g do P r o t o c o l o C o l l e c t i o n ∗/ NodeC . R a d i o C o n t r o l −>A c t i v e M e s s a g e C ; NodeC . C o l l e c t i o n C o n t r o l −> C o l l e c t i o n C ; NodeC . Send−> C o l l e c t i o n S e n d e r C ; NodeC . I n t e r c e p t −> C o l l e c t i o n C . I n t e r c e p t [ RADIO_ID ] ; 95 58 } Código 8 .5: NodeC.nc 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 /∗ ∗ =============================================== ∗ U n i v e r s i d a d e de Pernambuco − UPE ∗ D e p a r t a m e n t o de S i s t e m a s e Computacao − DSC ∗ Programa de Academico em E n g e n h a r i a da Computacao ∗ O r i e n t a d o r : P r o f . A b e l G u i l h e r m i n o da S i l v a F i l h o ∗ Co−o r i e n t a d o r : P r o f . R e n a t o M a r i z de Moraes ∗ A l u n o : F r e d e r i c o Cox ∗ =============================================== ∗ ∗ ∗ . : : A n a l i s e Nodal de E n e r g i a em : : . ∗ .:: R e d e s de S e n s o r e s sem F i o : : . ∗ ∗ ∗/ # include " Global . h" # include " p r i n t f . h" module NodeC{ uses { i n t e r f a c e Boot ; i n t e r f a c e Leds ; /∗ ∗ Timers ∗/ i n t e r f a c e Timer < T M i l l i > a s I2CTimer ; i n t e r f a c e Timer < T M i l l i > a s RxTimer ; i n t e r f a c e Timer < T M i l l i > a s F l a s h L e d ; /∗ ∗ P r o t o c o l o I2C ∗/ i n t e r f a c e I 2 C P a c k e t < TI2CBasicAddr > ; i n t e r f a c e Resource ; /∗ ∗ I n t e r r u p c a o e x t e r n a INT0 do PIC ∗/ i n t e r f a c e G e n e r a l I O a s wakeUpPIC ; /∗ ∗ Sensores ∗/ i n t e r f a c e Read < u i n t 1 6 _ t > a s F o t o S e n s o r ; i n t e r f a c e Read < u i n t 1 6 _ t > a s TempSensor ; /∗ ∗ I n t e r f a c e s do P r o t o c o l o C o l l e c t i o n ∗/ i n t e r f a c e S p l i t C o n t r o l as RadioControl ; i n t e r f a c e StdControl as C o l l e c t i o n C o n t r o l ; i n t e r f a c e Send ; 96 55 interface Intercept ; 56 interface CollectionPacket ; 57 } 58 } 59 i m p l e m e n t a t i o n { 60 61 uint8_t txData [ 8 ] ; 62 u i n t 8 _ t rxData [ 1 6 ] ; 63 u i n t 1 6 _ t tempSensor = 0; 64 uint16_t fotoSensor = 0; 65 message_t sndBuffer ; 66 RadioMsg_t ∗ r a d i o P o i n t e r ; 67 uint16_t contador = 0; 68 uint16_t perdas = 0; 69 70 t a s k void sendPacket ( ) ; 71 s t a t i c void f a t a l _ p r o b l e m ( ) ; 72 73 e v e n t v o i d Boot . b o o t e d ( ) { 74 c a l l RadioControl . s t a r t ( ) ; 75 } 76 event void RadioControl . s t a r t D o n e ( e r r o r _ t e r r o r ) { 77 i f ( e r r o r ! =SUCCESS ) { 78 c a l l RadioControl . s t a r t ( ) ; 79 } else { 80 i f ( c a l l C o l l e c t i o n C o n t r o l . s t a r t ( ) ! = SUCCESS ) f a t a l _ p r o b l e m ( ) ; 81 c a l l wakeUpPIC . makeOutput ( ) ; 82 c a l l wakeUpPIC . c l r ( ) ; 83 c a l l I2CTimer . s t a r t P e r i o d i c ( 3 0 0 0 ) ; 84 c a l l TempSensor . r e a d ( ) ; 85 c a l l FotoSensor . read ( ) ; 86 c a l l Send . m a x P a y l o a d L e n g t h ( ) ; 87 } 88 } 89 90 91 e v e n t v o i d I2CTimer . f i r e d ( ) { 92 c a l l TempSensor . r e a d ( ) ; 93 c a l l FotoSensor . read ( ) ; 94 c a l l wakeUpPIC . s e t ( ) ; 95 c a l l Resource . r e q u e s t ( ) ; 96 c o n t a d o r ++; 97 } 98 99 event void Resource . g r a n t e d ( ) { 100 memcpy ( t x D a t a , " $C# " , s t r l e n ( " $C# " ) ) ; 101 c a l l I 2 C P a c k e t . w r i t e ( I2C_START | I2C_STOP , SLAVE_ADDR, s i z e o f ( r x D a t a ) , &t x D a t a [ 0 ] ) ; 102 } 103 104 async e v e n t void I2CPacket . readDone ( e r r o r _ t e r r o r , u i n t 1 6 _ t addr , uint8_t length , uint8_t ∗ data ) { 105 i f ( e r r o r ==SUCCESS ) { 106 post sendPacket ( ) ; 107 } 108 c a l l Resource . r e l e a s e ( ) ; 109 c a l l wakeUpPIC . c l r ( ) ; 110 } 97 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 async e v e n t void I2CPacket . writeDone ( e r r o r _ t e r r o r , u i n t 1 6 _ t addr , uint8_t length , uint8_t ∗ data ) { i f ( e r r o r ==SUCCESS ) { c a l l RxTimer . s t a r t O n e S h o t ( 1 0 0 ) ; } else { c a l l Resource . r e l e a s e ( ) ; c a l l wakeUpPIC . c l r ( ) ; } } t a s k void sendPacket ( ) { uint8_t i ; r a d i o P o i n t e r = ( RadioMsg_t ∗ ) ( c a l l Send . g e t P a y l o a d (& s n d B u f f e r , s i z e o f ( RadioMsg_t ) ) ) ; r a d i o P o i n t e r −>o r i g e m = TOS_NODE_ID ; r a d i o P o i n t e r −> s a l t o s = 0 ; r a d i o P o i n t e r −> f o t o = fotoSensor ; r a d i o P o i n t e r −>temp = tempSensor ; r a d i o P o i n t e r −> p e r d a s = p e r d a s ; f o r ( i = 0 ; i < 1 6 ; i ++) { r a d i o P o i n t e r −> p o t e n c i a [ i ] = r x D a t a [ i ] ; } r a d i o P o i n t e r −> c o n t a d o r = c o n t a d o r ; c a l l Send . s e n d (& s n d B u f f e r , s i z e o f ( RadioMsg_t ) ) ; c a l l Leds . led2On ( ) ; c a l l FlashLed . startOneShot (200) ; } e v e n t v o i d R a d i o C o n t r o l . s t o p D o n e ( e r r o r _ t e r r o r ) {} e v e n t b o o l I n t e r c e p t . f o r w a r d ( m e s s a g e _ t ∗msg , v o i d ∗ p a y l o a d , u i n t 8 _ t len ) { RadioMsg_t ∗ RadioFw = ( RadioMsg_t ∗ ) p a y l o a d ; RadioFw−> s a l t o s ++; r e t u r n TRUE ; } e v e n t v o i d RxTimer . f i r e d ( ) { memset (& r x D a t a [ 0 ] , 0 x00 , s i z e o f ( r x D a t a ) ) ; c a l l I 2 C P a c k e t . r e a d ( I2C_START | I2C_STOP , SLAVE_ADDR, s i z e o f ( r x D a t a ) , &r x D a t a [ 0 ] ) ; } e v e n t void Fo toSe nsor . readDone ( e r r o r _ t r e s u l t , u i n t 1 6 _ t v a l ) { i f ( r e s u l t ==SUCCESS ) { fotoSensor = val ; } } e v e n t v o i d TempSensor . r e a d D o n e ( e r r o r _ t r e s u l t , u i n t 1 6 _ t v a l ) { i f ( r e s u l t ==SUCCESS ) { tempSensor = val ; } } 98 165 166 167 168 169 170 171 172 173 174 175 176 177 178 } event void FlashLed . f i r e d ( ) { c a l l Leds . l e d 2 O f f ( ) ; } e v e n t v o i d Send . sendDone ( m e s s a g e _ t ∗msg , e r r o r _ t e r r o r ) {} / / Use LEDs t o r e p o r t v a r i o u s s t a t u s i s s u e s . s t a t i c void f a t a l _ p r o b l e m ( ) { c a l l Leds . led0On ( ) ; / / c a l l L e d s . led1On ( ) ; / / c a l l L e d s . led2On ( ) ; c a l l I2CTimer . s t o p ( ) ; } Apêndice III Código fonte do TinyOS Terminal Código 9 .1: UnitPrincipal.pas 1 unit UnitPrincipal ; 2 3 interface 4 5 uses 6 Windows , Messages , S y s U t i l s , V a r i a n t s , C l a s s e s , G r a p h i c s , C o n t r o l s , Forms , 7 D i a l o g s , n r c l a s s e s , nrcomm , S t d C t r l s , nrcommbox , E x t C t r l s , n r t e r m i n a l , 8 n r d a t a p r o c , B u t t o n s , ComCtrls , n r s e m a p h o r e , j p e g , CPort , C P o r t C t l , 9 OverbyteIcsEmulVT , OverbyteIcsTnEmulVT , O v e r b y t e I c s T n S c r i p t , HotLog , ShellAPI ; 10 11 t y p e 12 T F o r m P r i n c i p a l = c l a s s ( TForm ) 13 Panel : TPanel ; 14 Label2 : TLabel ; 15 Label1 : TLabel ; 16 BitBtnOpen : TBitBtn ; 17 SpeedButtonAbout : TSpeedButton ; 18 BitBtnClear : TBitBtn ; 19 StatusBar : TStatusBar ; 20 BitBtn1 : TBitBtn ; 21 ComPort : TComPort ; 22 PanelHeader : TPanel ; 23 Label4 : TLabel ; 24 RichEditHeader : TRichEdit ; 25 PanelPayload : TPanel ; 26 Label3 : TLabel ; 27 RichEditPayload : TRichEdit ; 28 PanelCRC : T P a n e l ; 29 Label5 : TLabel ; 30 RichEditCRC : T R i c h E d i t ; 31 ComRadioGroup1 : TComRadioGroup ; 32 ComRadioGroup2 : TComRadioGroup ; 33 ComRadioGroup3 : TComRadioGroup ; 34 ComboBoxBaud : TComComboBox ; 35 ComComboBox2 : TComComboBox ; 36 ComRadioGroup4 : TComRadioGroup ; 37 CheckBoxHex : TCheckBox ; 100 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 O p e n D i a l o g : TOpenDialog ; E d i t F i l e : TEdit ; B u t t o n F i l e : TSpeedButton ; ImageTinyOS : TImage ; ImageDSC : TImage ; CheckBoxWriteToLog : TCheckBox ; f u n c t i o n SoNumeros ( Const T e x t o : S t r i n g ) : S t r i n g ; procedure B i t B t n 1 C l i c k ( Sender : TObject ) ; function String2Hex ( const Buffer : A n s i s t r i n g ) : string ; f u n c t i o n ByteToHex ( I n B y t e : b y t e ) : s h o r t s t r i n g ; f u n c t i o n HexToBin ( H e x a d e c i m a l : s t r i n g ) : s t r i n g ; procedure BitBtnOpenClick ( Sender : TObject ) ; p r o c e d u r e ComPortRxChar ( S e n d e r : T O b j e c t ; Count : I n t e g e r ) ; procedure P r i n t P a c k e t ( s t r : s t r i n g ) ; procedure z e r a V a r i a v e i s ; procedure a t u a l i z a S t a t u s B a r ; p r o c e d u r e FormShow ( S e n d e r : T O b j e c t ) ; procedure AddColorText ( s z T e x t : S t r i n g ; c l C o l o r : TColor ; R i c h E d i t : TRichEdit ) ; f u n c t i o n HexToTColor ( s C o l o r : s t r i n g ) : T C o l o r ; procedure B i t B t n C l e a r C l i c k ( Sender : TObject ) ; procedure B u t t o n F i l e C l i c k ( Sender : TObject ) ; p r o c e d u r e ImageDSCClick ( S e n d e r : T O b j e c t ) ; procedure ImageTinyOSClick ( Sender : TObject ) ; function I s I n t e g e r ( TestaString : String ) : boolean ; private { Private declarations } public { Public declarations } end ; var FormPrincipal : TFormPrincipal ; rcvStateMachine : Integer ; bufferInput : AnsiString ; P a c o t e s , rx , t x : I n t e g e r ; tos_data_length : Integer ; hLog : THotLog ; / / D e f i n i c a o da maquina de e s t a d o s const waitFramingByte = 0; rcvPacket = 3; implementation { $R ∗ . dfm } procedure T F o r m P r i n c i p a l . z e r a V a r i a v e i s ; begin Pacotes :=0; rx :=0; 101 95 tx :=0; 96 rcvStateMachine := waitFramingByte ; 97 b u f f e r I n p u t := ’ ’ ; 98 end ; 99 100 101 p r o c e d u r e T F o r m P r i n c i p a l . a t u a l i z a S t a t u s B a r ; 102 b e g i n 103 w i t h S t a t u s B a r . P a n e l s do 104 begin 105 i f ComPort . C o n n e c t e d t h e n 106 Items [ 0 ] . Text := ’ Connected ’ 107 else 108 Items [ 0 ] . Text := ’ Disconnected ’ ; 109 110 I t e m s [ 1 ] . T e x t : = ComboBoxBaud . T e x t + ’ b p s ’ ; 111 Items [ 2 ] . Text := ’ Packets ’ + IntToStr ( Pacotes ) ; 112 Items [ 3 ] . Text := ’ Packet Length ’ + i n t t o s t r ( t o s _ d a t a _ l e n g t h ) + ’ bytes ’ ; 113 I t e m s [ 4 ] . T e x t : = ’ Rx ’ + i n t t o s t r ( r x ) ; 114 I t e m s [ 5 ] . T e x t : = ’ Tx ’ + i n t t o s t r ( t x ) ; 115 end ; 116 117 end ; 118 119 120 p r o c e d u r e T F o r m P r i n c i p a l . B i t B t n 1 C l i c k ( S e n d e r : T O b j e c t ) ; 121 b e g i n 122 123 Application . Terminate ; 124 end ; 125 126 p r o c e d u r e T F o r m P r i n c i p a l . B i t B t n C l e a r C l i c k ( S e n d e r : T O b j e c t ) ; 127 b e g i n 128 RichEditHeader . Clear ; 129 RichEditPayload . Clear ; 130 RichEditCRC . C l e a r ; 131 zeraVariaveis () ; 132 end ; 133 134 f u n c t i o n T F o r m P r i n c i p a l . SoNumeros ( Const T e x t o : S t r i n g ) : S t r i n g ; 135 var 136 I : integer ; 137 S: string ; 138 b e g i n 139 S := ’ ’ ; 140 f o r I : = 1 To Length ( T e x t o ) Do 141 begin 142 i f ( Texto [ I ] in [ ’ 0 ’ . . ’ 9 ’ ] ) then 143 begin 144 S : = S + Copy ( Texto , I , 1 ) ; 145 end ; 146 end ; 147 r e s u l t := S ; 148 end ; 149 150 151 102 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 function TFormPrincipal . String2Hex ( const Buffer : A n s i s t r i n g ) : string ; var n: Integer ; begin Result := ’ ’ ; f o r n : = 1 t o Length ( B u f f e r ) do R e s u l t : = UpperCase ( R e s u l t + IntToHex ( Ord ( B u f f e r [ n ] ) , 2 ) ) ; end ; procedure T F o r m P r i n c i p a l . BitBtnOpenClick ( Sender : TObject ) ; begin / / $ I d : U n i t P r i n c i p a l . p a s 10 2008−12−19 1 7 : 2 8 : 2 0 Z Fred Cox $ i f ComPort . C o n n e c t e d t h e n begin B i t B t n O p e n . C a p t i o n : = ’&Open ’ ; ComPort . C o n n e c t e d : = f a l s e ; B u t t o n F i l e . Enabled := t r u e ; E d i t F i l e . Enabled := t r u e ; i f CheckBoxWriteToLog . Checked t h e n hLog . Free ; CheckBoxWriteToLog . E n a b l e d : = t r u e ; end else begin E d i t F i l e . T e x t : = O p e n D i a l o g . FileName + f o r m a t d a t e t i m e ( ’ ddmmyyyyhhnnss ’ , now ) + ’ . l o g ’ ; E d i t F i l e . Enabled := f a l s e ; i f CheckBoxWriteToLog . Checked t h e n begin hLog : = THotLog . C r e a t e ; hLog . h l W r i t e r . h l F i l e D e f . f i l e N a m e : = E d i t F i l e . T e x t ; hLog . S t a r t l o g g i n g ; hLog . add ( ’ TinyOS T e r m i n a l [ S t a r t i n g l o g g i n g ] − > {now} ’ ) ; hLog . add ( ’ {OSVI} ’ ) ; hLog . add ( ’ {CPUI} ’ ) ; hLog . add ( ’ { D i s k } ’ ) ; hLog . add ( ’ {Ram} ’ ) ; hLog . add ( ’ { T i m e r s } ’ ) ; CheckBoxWriteToLog . E n a b l e d : = f a l s e ; end ; B i t B t n O p e n . C a p t i o n : = ’&C l o s e ’ ; B u t t o n F i l e . Enabled := f a l s e ; rcvStateMachine := waitFramingByte ; ComPort . C o n n e c t e d : = t r u e ; end ; atualizaStatusBar ; end ; procedure T F o r m P r i n c i p a l . B u t t o n F i l e C l i c k ( Sender : TObject ) ; begin i f OpenDialog . Execute then begin E d i t F i l e . T e x t : = O p e n D i a l o g . FileName ; end ; end ; f u n c t i o n T F o r m P r i n c i p a l . ByteToHex ( I n B y t e : b y t e ) : s h o r t s t r i n g ; 103 209 210 211 212 213 214 215 216 c o n s t D i g i t s : a r r a y [ 0 . . 1 5 ] o f c h a r = ’ 0123456789ABCDEF ’ ; begin r e s u l t : = d i g i t s [ I n B y t e s h r 4 ] + d i g i t s [ I n B y t e and $0F ] ; end ; p r o c e d u r e T F o r m P r i n c i p a l . ComPortRxChar ( S e n d e r : T O b j e c t ; Count : I n t e g e r ) ; var input : AnsiString ; i : Integer ; begin r x : = r x + Count ; ComPort . R e a d S t r ( i n p u t , Count ) ; f o r i : = 0 t o Count do begin case rcvStateMachine of waitFramingByte : begin i f i n p u t [ i ]= ’~ ’ then begin b u f f e r I n p u t := i n p u t [ i ] ; rcvStateMachine := rcvPacket ; end ; end ; rcvPacket : begin i f i n p u t [ i ]= ’~ ’ then begin P r i n t P a c k e t ( b u f f e r I n p u t + ’~ ’ ) ; Inc ( P a c o t e s ) ; rcvStateMachine := waitFramingByte ; R i c h E d i t H e a d e r . P e r f o r m (WM_VSCROLL, SB_BOTTOM, 0 ) ; R i c h E d i t P a y l o a d . P e r f o r m (WM_VSCROLL, SB_BOTTOM, 0 ) ; RichEditCRC . P e r f o r m (WM_VSCROLL, SB_BOTTOM, 0 ) ; end else b u f f e r I n p u t := b u f f e r I n p u t + i n p u t [ i ] ; 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 end ; 249 end ; 250 end ; 251 atualizaStatusBar ; 252 253 end ; 254 255 256 p r o c e d u r e T F o r m P r i n c i p a l . FormShow ( S e n d e r : T O b j e c t ) ; 257 b e g i n 258 zeraVariaveis ; 259 atualizaStatusBar ; 260 BitBtnClear . Click ; 261 E d i t F i l e . T e x t : = G e t C u r r e n t D i r + ’ \ ’ + O p e n D i a l o g . FileName + f o r m a t d a t e t i m e ( ’ ddmmyyyyhhnnss ’ , now ) + ’ . l o g ’ ; 262 263 264 end ; 104 265 266 p r o c e d u r e T F o r m P r i n c i p a l . P r i n t P a c k e t ( s t r : s t r i n g ) ; 267 var 268 i , j : integer ; 269 c r c 1 6 r c v : Word ; 270 c r c 1 6 c a l c : Word ; 271 index : i n t e g e r ; 272 b e g i n 273 274 / / A d i c i o n a o numero do p a c o t e 275 AddColorText ( ’ [ ’ , clWhite , RichEditHeader ) ; 276 A d d C o l o r T e x t ( Format ( ’ %.4 d ’ , [ P a c o t e s ] ) , clRed , R i c h E d i t H e a d e r ) ; 277 AddColorText ( ’ ] ’ , clWhite , RichEditHeader ) ; 278 R i c h E d i t H e a d e r . L i n e s . Add ( ’ ’ ) ; 279 / / adiciona o payload 280 i :=5; 281 w h i l e ( ( ord ( s t r [ i ] ) = 0 ) or ( ord ( s t r [ i ] ) = 2 5 5 ) ) do I n c ( i ) ; 282 283 t o s _ d a t a _ l e n g t h : = ord ( s t r [ i ] ) ; 284 285 Inc ( i ) ; 286 w h i l e ( ord ( s t r [ i ] ) = 0 ) do I n c ( i ) ; 287 Inc ( i ) ; 288 289 i f CheckBoxHex . Checked t h e n 290 A d d C o l o r T e x t ( S t r i n g 2 H e x ( copy ( s t r , i , t o s _ d a t a _ l e n g t h ) ) , HexToTColor ( ’ 40E0D0 ’ ) , R i c h E d i t P a y l o a d ) 291 else 292 begin 293 / / A d d C o l o r T e x t ( c o p y ( s t r , i , t o s _ d a t a _ l e n g t h ) , HexToTColor ( ’ FFFF00 ’ ) , RichEditPayload ) ; 294 / / Adiciona o payload colorido 295 f o r i n d e x : = i t o ( t o s _ d a t a _ l e n g t h − 1 ) do 296 begin 297 / / S w i t c h case para c o l o r i r o payload 298 case s t r [ index ] of 299 chr ( 0 ) . . chr ( 3 1 ) : continue ; / / AddColorText ( s t r [ index ] , HexToTColor ( ’ FFFFCC ’ ) , R i c h E d i t P a y l o a d ) ; 300 ’ : ’ . . ’@’ : A d d C o l o r T e x t ( s t r [ i n d e x ] , HexToTColor ( ’ CCFF66 ’ ) , RichEditPayload ) ; 301 ’0 ’ . . ’9 ’ : A d d C o l o r T e x t ( s t r [ i n d e x ] , HexToTColor ( ’ FFFF99 ’ ) , RichEditPayload ) ; 302 ’ ’ .. ’/ ’: A d d C o l o r T e x t ( s t r [ i n d e x ] , HexToTColor ( ’ CC0033 ’ ) , RichEditPayload ) ; 303 ’[ ’ .. ’] ’: A d d C o l o r T e x t ( s t r [ i n d e x ] , HexToTColor ( ’ 33FFCC ’ ) , RichEditPayload ) ; 304 else A d d C o l o r T e x t ( s t r [ i n d e x ] , HexToTColor ( ’ FFFFFF ’ ) , RichEditPayload ) ; 305 end ; 306 end ; 307 R i c h E d i t P a y l o a d . l i n e s . Add ( ’ ’ ) ; 308 end ; 309 310 311 312 / / A d i c i o n a o CRC 313 A d d C o l o r T e x t ( ’ [ ’ , c l W h i t e , RichEditCRC ) ; 314 A d d C o l o r T e x t ( S t r i n g 2 H e x ( copy ( s t r , ( l e n g t h ( s t r ) −2) , 2 ) ) , HexToTColor ( ’ 90 105 315 316 317 318 319 320 321 322 EE90 ’ ) , RichEditCRC ) ; A d d C o l o r T e x t ( ’ ] ’ , c l W h i t e , RichEditCRC ) ; RichEditCRC . L i n e s . Add ( ’ ’ ) ; i f CheckBoxWriteToLog . Checked t h e n begin h l o g . Add ( ’ { / } { LNumOff }{∗80∗} ’ ) ; h l o g . Add ( ’ >> Recv P a c k e t Number : ’ + Format ( ’ %.4 d ’ , [ P a c o t e s ] ) ) ; h l o g . Add ( ’ D a t e Time : {60@} ( { now } ) ’ ) ; h l o g . Add ( ’ H e x a d e c i m a l { ∗ 2 5 . } : ’ + S t r i n g 2 H e x ( copy ( s t r , i , tos_data_length ) ) ) ; h l o g . Add ( ’Raw b y t e s { ∗ 2 5 . } : ’ + copy ( s t r , i , t o s _ d a t a _ l e n g t h ) ) ; end ; 323 324 325 326 end ; 327 328 329 p r o c e d u r e T F o r m P r i n c i p a l . A d d C o l o r T e x t ( s z T e x t : S t r i n g ; c l C o l o r : T C o l o r ; RichEdit : TRichEdit ) ; 330 b e g i n 331 / / Set the selected t e x t color 332 RichEdit . S e l A t t r i b u t e s . Color := clColor ; 333 / / Add t h e t e x t 334 RichEdit . SelText := szText ; 335 / / S e t t h e s e l e c t e d t e x t back t o t h e d e f a u l t 336 / / R i c h E d i t . S e l A t t r i b u t e s . C o l o r := c l W i n d o w T e x t ; 337 end ; 338 339 340 f u n c t i o n T F o r m P r i n c i p a l . HexToBin ( H e x a d e c i m a l : s t r i n g ) : s t r i n g ; 341 c o n s t 342 BCD: a r r a y [ 0 . . 1 5 ] o f s t r i n g = 343 ( ’ 0000 ’ , ’ 0001 ’ , ’ 0010 ’ , ’ 0011 ’ , ’ 0100 ’ , ’ 0101 ’ , ’ 0110 ’ , ’ 0111 ’ , 344 ’ 1000 ’ , ’ 1001 ’ , ’ 1010 ’ , ’ 1011 ’ , ’ 1100 ’ , ’ 1101 ’ , ’ 1110 ’ , ’ 1111 ’ ) ; 345 var 346 i : integer ; 347 b e g i n 348 f o r i : = Length ( H e x a d e c i m a l ) downto 1 do 349 R e s u l t : = BCD[ S t r T o I n t ( ’ $ ’ + H e x a d e c i m a l [ i ] ) ] + R e s u l t ; 350 end ; 351 352 353 f u n c t i o n T F o r m P r i n c i p a l . HexToTColor ( s C o l o r : s t r i n g ) : T C o l o r ; 354 b e g i n 355 R e s u l t : =RGB( 356 S t r T o I n t ( ’ $ ’ +Copy ( s C o l o r , 1 , 2 ) ) , 357 S t r T o I n t ( ’ $ ’ +Copy ( s C o l o r , 3 , 2 ) ) , 358 S t r T o I n t ( ’ $ ’ +Copy ( s C o l o r , 5 , 2 ) ) 359 ) ; 360 end ; 361 362 363 364 365 366 p r o c e d u r e T F o r m P r i n c i p a l . ImageDSCClick ( S e n d e r : T O b j e c t ) ; 367 b e g i n 368 369 S h e l l E x e c u t e ( A p p l i c a t i o n . Handle , 106 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 PChar ( ’ open ’ ) , PChar ( ’ h t t p : / / d s c . upe . b r / ’ ) , PChar ( 0 ) , nil , SW_NORMAL) ; end ; procedure T F o r m P r i n c i p a l . ImageTinyOSClick ( Sender : TObject ) ; begin S h e l l E x e c u t e ( A p p l i c a t i o n . Handle , PChar ( ’ open ’ ) , PChar ( ’ h t t p : / / www. t i n y o s . n e t / ’ ) , PChar ( 0 ) , nil , SW_NORMAL) ; end ; function TFormPrincipal . I s I n t e g e r ( TestaString : String ) : boolean ; begin try StrToInt ( T e s t a S t r i n g ) ; except On E C o n v e r t E r r o r do r e s u l t : = F a l s e ; else r e s u l t := True ; end ; end ; end . Apêndice IV Código fonte do Experimento - Tymo Código 10 .1: Makefile 1 ############################################################################## 2 3 4 5 6 7 8 # U n i v e r s i d a d e de Pernambuco − UPE # D e p a r t a m e n t o de S i s t e m a s e Computacao − DSC # P r o g r a m a de Academico em E n g e n h a r i a da Computacao # O r i e n t a d o r : P r o f . Abel G u i l h e r m i n o da S i l v a F i l h o # Co−o r i e n t a d o r : P r o f . R e n a t o M a r i z de Moraes # Aluno : F r e d e r i c o Cox ############################################################################## 9 # Makefile 10 ############################################################################## 11 12 13 14 15 16 17 # # $ A u t h o r : F r e d Cox $ # $Rev : 70 $ # $ D a t e : 2008−12−19 1 6 : 2 0 : 5 1 −0200 ( Sex , 19 Dez 2 0 0 8 ) $ # $ I d : T i n y O S _ P l u g i n _ M a k e f i l e 70 2008−12−19 1 8 : 2 0 : 5 1 Z F r e d Cox $ # ############################################################################## 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 # V a r i a v e i s de a m b i e n t e COMPONENT=TymoBaseAppC CFLAGS += −I $ ( TOSDIR ) / −I $ ( TOSDIR ) / −I $ ( TOSDIR ) / −I $ ( TOSDIR ) / −I . TFLAGS += −I ( TOSDIR ) / t y p e s lib lib lib lib / / / / net net net net \ / tymo \ / tymo / dymo \ / tymo / mh \ DOCDIR= html −doc ############################################# # D e f i n i c o e s para o r a d i o − Canal e P o t e n c i a ############################################# 108 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 # PA_LEVEL [dBm] C u r r e n t C o n s u m p t i o n [mA] # 31 0 17.4 # 27 −1 16.5 # 23 −3 15.2 # 19 −5 13.9 # 15 −7 12.5 # 11 −10 11.2 # 7 −15 9.9 # 3 −25 8.5 ############################################# PFLAGS += −DCC2420_DEF_RFPOWER=19 ############################################# # IEEE 8 0 2 . 1 5 . 4 e s p e c i f i c a 16 c a n a i s # n u m e r a d o s de 11 a 26 ############################################# PFLAGS += −DCC2420_DEF_CHANNEL=26 ############################################# # I n c l u e a b i b l i o t e c a p r i n t f NOVA CFLAGS += −I $ ( TOSDIR ) / l i b / p r i n t f / 2 _0_2 ############################################# # Aumenta o p a y l o a d do p r i n t f ############################################# CFLAGS +=−DTOSH_DATA_LENGTH=160 ############################################# # I n c l u e S u p o r t e a p l a c a MDA100 CFLAGS += −I $ ( TOSDIR ) / s e n s o r b o a r d s / mda100 / CFLAGS += −I $ ( TOSDIR ) / s e n s o r b o a r d s / mda100 / cb ############################################# i f d e f APP_MAKERULES i n c l u d e $ (APP_MAKERULES) else i n c l u d e $ (MAKERULES) endif ############################################# Código 10 .2: Global.h 1 /∗ 2 ∗ =============================================== 3 ∗ U n i v e r s i d a d e de Pernambuco − UPE 4 ∗ D e p a r t a m e n t o de S i s t e m a s e Computacao − DSC 5 ∗ P r o g r a m a de Academico em E n g e n h a r i a da Computacao 6 ∗ O r i e n t a d o r : P r o f . Abel G u i l h e r m i n o da S i l v a F i l h o 7 ∗ Co−o r i e n t a d o r : P r o f . R e n a t o M a r i z de Moraes 8 ∗ Aluno : F r e d e r i c o Cox 9 ∗ =============================================== 10 ∗ 11 ∗ 12 ∗ . : : A n a l i s e Nodal de E n e r g i a em : : . 13 ∗ .:: Redes de S e n s o r e s sem F i o : : . 14 ∗ 15 ∗ 16 ∗ / 17 18 # i f n d e f GLOBAL_H 109 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 # d e f i n e GLOBAL_H /∗ ∗ E n d e r e c o do g a t e w a y ou e s t a c a o b a s e ∗/ enum { DESTINO = 36 }; /∗ ∗ E s t r u t u r a da mensagem do r a d i o ∗/ t y p e d e f n x _ s t r u c t RadioMsg { n x _ u i n t 1 6 _ t origem ; nx_uint16_t perdas ; nx_uint16_t saltos ; n x _ u i n t 1 6 _ t temp ; nx_uint16_t foto ; nx_uint8_t potencia [16]; nx_uint16_t contador ; } RadioMsg_t ; # e n d i f / ∗ GLOBAL_H ∗ / Código 10 .3: TymoBaseAppC.nc 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 /∗ ∗ =============================================== ∗ U n i v e r s i d a d e de Pernambuco − UPE ∗ D e p a r t a m e n t o de S i s t e m a s e Computacao − DSC ∗ P r o g r a m a de Academico em E n g e n h a r i a da Computacao ∗ O r i e n t a d o r : P r o f . Abel G u i l h e r m i n o da S i l v a F i l h o ∗ Co−o r i e n t a d o r : P r o f . R e n a t o M a r i z de Moraes ∗ Aluno : F r e d e r i c o Cox ∗ =============================================== ∗ ∗ ∗ . : : A n a l i s e Nodal de E n e r g i a em : : . ∗ .:: Redes de S e n s o r e s sem F i o : : . ∗ ∗ ∗/ c o n f i g u r a t i o n TymoBaseAppC { } implementation { c o m p o n e n t s MainC , LedsC , P r i n t f C , TymoBaseC , DymoNetworkC ; c o m p o n e n t s new T i m e r M i l l i C ( ) a s F l a s h T i m e r ; TymoBaseC . Boot −>MainC . B o o t ; TymoBaseC . P r i n t f C o n t r o l −>P r i n t f C . P r i n t f C o n t r o l ; TymoBaseC . P r i n t f F l u s h −>P r i n t f C . P r i n t f F l u s h ; TymoBaseC . F l a s h T i m e r −>F l a s h T i m e r ; TymoBaseC . Leds −>LedsC . L e d s ; /∗ ∗ W i r i n g do Tymo ∗/ TymoBaseC . R a d i o C o n t r o l −>DymoNetworkC . S p l i t C o n t r o l ; TymoBaseC . MHPacket−>DymoNetworkC . MHPacket ; 110 34 TymoBaseC . MHSend−>DymoNetworkC . MHSend [ 1 ] ; 35 TymoBaseC . R e c e i v e −>DymoNetworkC . R e c e i v e [ 1 ] ; 36 TymoBaseC . I n t e r c e p t −>DymoNetworkC . I n t e r c e p t [ 1 ] ; 37 38 } Código 10 .4: TymoBaseC.nc 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 /∗ ∗ =============================================== ∗ U n i v e r s i d a d e de Pernambuco − UPE ∗ D e p a r t a m e n t o de S i s t e m a s e Computacao − DSC ∗ P r o g r a m a de Academico em E n g e n h a r i a da Computacao ∗ O r i e n t a d o r : P r o f . Abel G u i l h e r m i n o da S i l v a F i l h o ∗ Co−o r i e n t a d o r : P r o f . R e n a t o M a r i z de Moraes ∗ Aluno : F r e d e r i c o Cox ∗ =============================================== ∗ ∗ ∗ . : : A n a l i s e Nodal de E n e r g i a em : : . ∗ .:: Redes de S e n s o r e s sem F i o : : . ∗ ∗ ∗/ # include " p r i n t f . h" # include " Global . h" # i n c l u d e " I2C . h " /∗ ∗ P r o t o c o l o de c o m u n i c a c a o I2C ∗ ∗ ∗ $C# −> S o l i c i t a Consumo ∗ ∗ ∗/ module TymoBaseC { uses { i n t e r f a c e Boot ; i n t e r f a c e S p l i t C o n t r o l as P r i n t f C o n t r o l ; interface PrintfFlush ; i n t e r f a c e Timer < T M i l l i > a s F l a s h T i m e r ; i n t e r f a c e Leds ; /∗ ∗ I n t e r f a c e s n e c e s s a r i a s do Tymo ∗/ i n t e r f a c e S p l i t C o n t r o l as RadioControl ; i n t e r f a c e AMPacket a s MHPacket ; i n t e r f a c e AMSend a s MHSend ; i n t e r f a c e Receive ; interface Intercept ; } } implementation { b o o l ledOn = TRUE ; 111 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 unsigned char b u f f e r [ 1 6 ] ; message_t sndBuffer ; RadioMsg_t ∗ r a d i o P o i n t e r ; e v e n t v o i d Boot . booted ( ) { c a l l RadioControl . s t a r t ( ) ; } event void RadioControl . startDone ( e r r o r _ t e r r o r ) { i f ( e r r o r !=SUCCESS ) { c a l l RadioControl . s t a r t ( ) ; } else { call PrintfControl . start () ; } } event void P r i n t f C o n t r o l . startDone ( e r r o r _ t e r r o r ) { i f ( e r r o r !=SUCCESS ) { call PrintfControl . start () ; } else { c a l l L e d s . led0On ( ) ; c a l l FlashTimer . startOneShot (10) ; p r i n t f ( " S e r v i c o s i n i c i a l i z a d o s com s u c e s s o . . . " ) ; call PrintfFlush . flush () ; } } event void P r i n t f C o n t r o l . stopDone ( e r r o r _ t e r r o r ) { } event void P r i n t f F l u s h . flushDone ( e r r o r _ t e r r o r ) { } event void FlashTimer . f i r e d ( ) { i f ( ledOn ) { c a l l L e d s . led0On ( ) ; c a l l FlashTimer . startOneShot (10) ; } else { c a l l Leds . l e d 0 O f f ( ) ; c a l l FlashTimer . startOneShot (1000) ; } ledOn = ledOn ^ TRUE ; } event void RadioControl . stopDone ( e r r o r _ t e r r o r ) { } e v e n t v o i d MHSend . sendDone ( m e s s a g e _ t ∗msg , e r r o r _ t e r r o r ) { } e v e n t m e s s a g e _ t ∗ R e c e i v e . r e c e i v e ( m e s s a g e _ t ∗msg , v o i d ∗ p a y l o a d , uint8_t len ) { R a d i o M s g _ t ∗ RadioMsg = ( R a d i o M s g _ t ∗ ) p a y l o a d ; i f ( c a l l MHPacket . d e s t i n a t i o n ( msg )==DESTINO ) { RadioMsg−> s a l t o s ++; memcpy ( b u f f e r ,& RadioMsg−>p o t e n c i a [ 2 ] , ( s i z e o f ( b u f f e r ) −2) ) ; p r i n t f ("% u;%u;%u;%u;%u;%u;% s \ r \ n " , RadioMsg−>origem , RadioMsg−>s a l t o s , RadioMsg−>p e r d a s , RadioMsg−>temp , 112 108 109 110 111 112 113 114 115 116 117 118 RadioMsg−>f o t o , RadioMsg−>c o n t a d o r , buffer ); call PrintfFlush . flush () ; } r e t u r n msg ; } 119 120 121 122 123 124 125 } e v e n t b o o l I n t e r c e p t . forward ( m e s s a g e _ t ∗msg , v o i d ∗ p a y l o a d , u i n t 8 _ t len ) { R a d i o M s g _ t ∗ RadioFw = ( R a d i o M s g _ t ∗ ) p a y l o a d ; RadioFw−> s a l t o s ++; r e t u r n TRUE ; } Código 10 .5: volumes-at45db.xml 1 2 3 Código 10 .6: TymoNodeAppC.nc 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 /∗ ∗ =============================================== ∗ U n i v e r s i d a d e de Pernambuco − UPE ∗ D e p a r t a m e n t o de S i s t e m a s e Computacao − DSC ∗ P r o g r a m a de Academico em E n g e n h a r i a da Computacao ∗ O r i e n t a d o r : P r o f . Abel G u i l h e r m i n o da S i l v a F i l h o ∗ Co−o r i e n t a d o r : P r o f . R e n a t o M a r i z de Moraes ∗ A l u n o : F r e d e r i c o Cox ∗ =============================================== ∗ ∗ ∗ . : : A n a l i s e Nodal de E n e r g i a em : : . ∗ . :: Redes de S e n s o r e s sem F i o : : . ∗ ∗ ∗/ c o n f i g u r a t i o n TymoNodeAppC{ } implementation { c o m p o n e n t s MainC , TymoNodeC , MicaBusC , DymoNetworkC , LedsC ; c o m p o n e n t s new T i m e r M i l l i C ( ) a s I2CTimer ; c o m p o n e n t s new T i m e r M i l l i C ( ) a s RxTimer ; c o m p o n e n t s new T i m e r M i l l i C ( ) a s F l a s h L e d ; c o m p o n e n t s new Atm128I2CMasterC ( ) ; c o m p o n e n t s new TempC ( ) ; c o m p o n e n t s new PhotoC ( ) ; TymoNodeC . Boot −>MainC . Boot ; TymoNodeC . Leds −>LedsC . Leds ; TymoNodeC . I2CTimer −>I2CTimer ; 113 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 } TymoNodeC . RxTimer−>RxTimer ; TymoNodeC . F l a s h L e d −>F l a s h L e d ; TymoNodeC . TempSensor −>TempC ; TymoNodeC . F o t o S e n s o r −>PhotoC ; /∗ ∗ I2C W i r i n g ∗/ TymoNodeC . R e s o u r c e −>Atm128I2CMasterC ; TymoNodeC . I 2 C P a c k e t −>Atm128I2CMasterC ; TymoNodeC . wakeUpPIC−>MicaBusC . PW2 ; /∗ ∗ W i r i n g do Tymo ∗/ TymoNodeC . R a d i o C o n t r o l −>DymoNetworkC . S p l i t C o n t r o l ; TymoNodeC . MHPacket−>DymoNetworkC . MHPacket ; TymoNodeC . MHSend−>DymoNetworkC . MHSend [ 1 ] ; TymoNodeC . R e c e i v e −>DymoNetworkC . R e c e i v e [ 1 ] ; TymoNodeC . I n t e r c e p t −>DymoNetworkC . I n t e r c e p t [ 1 ] ; Código 10 .7: TymoNodeC.nc 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 /∗ ∗ =============================================== ∗ U n i v e r s i d a d e de Pernambuco − UPE ∗ D e p a r t a m e n t o de S i s t e m a s e Computacao − DSC ∗ P r o g r a m a de Academico em E n g e n h a r i a da Computacao ∗ O r i e n t a d o r : P r o f . Abel G u i l h e r m i n o da S i l v a F i l h o ∗ Co−o r i e n t a d o r : P r o f . R e n a t o M a r i z de Moraes ∗ A l u n o : F r e d e r i c o Cox ∗ =============================================== ∗ ∗ ∗ . : : A n a l i s e Nodal de E n e r g i a em : : . ∗ . :: Redes de S e n s o r e s sem F i o : : . ∗ ∗ ∗/ //# include " p r i n t f . h" # include " Global . h" # i n c l u d e " I2C . h " /∗ ∗ P r o t o c o l o de c o m u n i c a c a o I2C ∗ ∗ ∗ $C# −> S o l i c i t a Consumo ∗ ∗ ∗/ module TymoNodeC{ uses { i n t e r f a c e Boot ; 114 33 i n t e r f a c e Leds ; 34 35 /∗ 36 ∗ Timers 37 ∗/ 38 i n t e r f a c e Timer < T M i l l i > a s I2CTimer ; 39 i n t e r f a c e Timer < T M i l l i > a s RxTimer ; 40 i n t e r f a c e Timer < T M i l l i > a s F l a s h L e d ; 41 42 /∗ 43 ∗ P r o t o c o l o I2C 44 ∗/ 45 i n t e r f a c e I2CPacket ; 46 i n t e r f a c e Resource ; 47 48 /∗ 49 ∗ I n t e r r u p c a o e x t e r n a INT0 do PIC 50 ∗/ 51 i n t e r f a c e G e n e r a l I O a s wakeUpPIC ; 52 /∗ 53 ∗ Sensores 54 ∗/ 55 i n t e r f a c e Read< u i n t 1 6 _ t > a s F o t o S e n s o r ; 56 i n t e r f a c e Read< u i n t 1 6 _ t > a s TempSensor ; 57 58 /∗ 59 ∗ I n t e r f a c e s n e c e s s a r i a s do Tymo 60 ∗/ 61 i n t e r f a c e S p l i t C o n t r o l as RadioControl ; 62 i n t e r f a c e AMPacket a s MHPacket ; 63 i n t e r f a c e AMSend a s MHSend ; 64 i n t e r f a c e Receive ; 65 interface Intercept ; 66 } 67 } 68 i m p l e m e n t a t i o n { 69 70 uint8_t txData [ 8 ] ; 71 u i n t 8 _ t rxData [ 1 6 ] ; 72 u i n t 1 6 _ t tempSensor = 0; 73 uint16_t fotoSensor = 0; 74 message_t sndBuffer ; 75 RadioMsg_t ∗ r a d i o P o i n t e r ; 76 uint16_t contador = 0; 77 uint16_t perdas = 0; 78 79 task void sendPacket ( ) ; 80 81 e v e n t v o i d Boot . b o o t e d ( ) { 82 c a l l RadioControl . s t a r t ( ) ; 83 } 84 85 event void RadioControl . startDone ( e r r o r _ t e r r o r ) { 86 i f ( e r r o r ! =SUCCESS ) { 87 c a l l RadioControl . s t a r t ( ) ; 88 } else { 89 c a l l wakeUpPIC . makeOutput ( ) ; 90 c a l l wakeUpPIC . c l r ( ) ; 115 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 c a l l I2CTimer . s t a r t P e r i o d i c ( 3 0 0 0 ) ; c a l l TempSensor . r e a d ( ) ; c a l l FotoSensor . read ( ) ; } } e v e n t v o i d I2CTimer . f i r e d ( ) { c a l l TempSensor . r e a d ( ) ; c a l l FotoSensor . read ( ) ; c a l l wakeUpPIC . s e t ( ) ; c a l l Resource . r e q u e s t ( ) ; c o n t a d o r ++; } event void Resource . granted ( ) { memcpy ( t x D a t a , " $C# " , s t r l e n ( " $C# " ) ) ; c a l l I 2 C P a c k e t . w r i t e ( I2C_START | I2C_STOP , SLAVE_ADDR, s i z e o f ( r x D a t a ) , &t x D a t a [ 0 ] ) ; } async e v e n t void I2CPacket . readDone ( e r r o r _ t e r r o r , u i n t 1 6 _ t addr , uint8_t length , uint8_t ∗ data ) { i f ( e r r o r ==SUCCESS ) { post sendPacket ( ) ; } c a l l Resource . r e l e a s e ( ) ; c a l l wakeUpPIC . c l r ( ) ; } async e v e n t void I2CPacket . writeDone ( e r r o r _ t e r r o r , u i n t 1 6 _ t addr , uint8_t length , uint8_t ∗ data ) { i f ( e r r o r ==SUCCESS ) { c a l l RxTimer . s t a r t O n e S h o t ( 1 0 0 ) ; } else { c a l l Resource . r e l e a s e ( ) ; c a l l wakeUpPIC . c l r ( ) ; } } task void sendPacket ( ) { uint8_t i ; r a d i o P o i n t e r = ( RadioMsg_t ∗ ) c a l l MHSend . g e t P a y l o a d (& s n d B u f f e r , s i z e o f ( RadioMsg_t ) ) ; r a d i o P o i n t e r −>o r i g e m = TOS_NODE_ID ; r a d i o P o i n t e r −> s a l t o s = 0 ; r a d i o P o i n t e r −> f o t o = fotoSensor ; r a d i o P o i n t e r −>temp = tempSensor ; r a d i o P o i n t e r −> p e r d a s = p e r d a s ; f o r ( i = 0 ; i < 1 6 ; i ++) { r a d i o P o i n t e r −> p o t e n c i a [ i ] = r x D a t a [ i ] ; } r a d i o P o i n t e r −> c o n t a d o r = c o n t a d o r ; c a l l MHSend . s e n d ( DESTINO , &s n d B u f f e r , s i z e o f ( RadioMsg_t ) ) ; c a l l Leds . led2On ( ) ; c a l l FlashLed . startOneShot (200) ; 116 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 } } e v e n t v o i d R a d i o C o n t r o l . s t o p D o n e ( e r r o r _ t e r r o r ) {} e v e n t v o i d MHSend . sendDone ( m e s s a g e _ t ∗msg , e r r o r _ t e r r o r ) { i f ( e r r o r ==SUCCESS ) { perdas = 0; } else { p e r d a s ++; } } e v e n t m e s s a g e _ t ∗ R e c e i v e . r e c e i v e ( m e s s a g e _ t ∗msg , v o i d ∗ p a y l o a d , uint8_t len ) { r e t u r n msg ; } e v e n t b o o l I n t e r c e p t . f o r w a r d ( m e s s a g e _ t ∗msg , v o i d ∗ p a y l o a d , u i n t 8 _ t len ) { RadioMsg_t ∗ RadioFw = ( RadioMsg_t ∗ ) p a y l o a d ; RadioFw−> s a l t o s ++; r e t u r n TRUE ; } e v e n t v o i d RxTimer . f i r e d ( ) { memset (& r x D a t a [ 0 ] , 0 x00 , s i z e o f ( r x D a t a ) ) ; c a l l I 2 C P a c k e t . r e a d ( I2C_START | I2C_STOP , SLAVE_ADDR, s i z e o f ( r x D a t a ) , &r x D a t a [ 0 ] ) ; } e v e n t void F oto Sens or . readDone ( e r r o r _ t r e s u l t , u i n t 1 6 _ t v a l ) { i f ( r e s u l t ==SUCCESS ) { fotoSensor = val ; } } e v e n t v o i d TempSensor . r e a d D o n e ( e r r o r _ t r e s u l t , u i n t 1 6 _ t v a l ) { i f ( r e s u l t ==SUCCESS ) { tempSensor = val ; } } event void FlashLed . f i r e d ( ) { c a l l Leds . l e d 2 O f f ( ) ; } Apêndice V Código fonte da experiência prática - Collection Código 11 .1: Global.h 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 /∗ ∗ =============================================== ∗ U n i v e r s i d a d e de Pernambuco − UPE ∗ D e p a r t a m e n t o de S i s t e m a s e Computacao − DSC ∗ P r o g r a m a de Academico em E n g e n h a r i a da Computacao ∗ O r i e n t a d o r : P r o f . Abel G u i l h e r m i n o da S i l v a F i l h o ∗ Co−o r i e n t a d o r : P r o f . R e n a t o M a r i z de Moraes ∗ A l u n o : F r e d e r i c o Cox ∗ =============================================== ∗ ∗ ∗ . : : A n a l i s e Nodal de E n e r g i a em : : . ∗ . :: Redes de S e n s o r e s sem F i o : : . ∗ ∗ ∗/ # i f n d e f GLOBAL_H # d e f i n e GLOBAL_H /∗ ∗ Define o c o l l e c t i o n _ i d ∗/ enum { TEMP_PHOTO_ID = 37 }; /∗ ∗ E s t r u t u r a da mensagem do r a d i o ∗/ t y p e d e f n x _ s t r u c t RadioMsg { nx_uint16_t origem_id ; nx_uint16_t saltos ; nx_uint16_t rota [ 5]; n x _ u i n t 1 6 _ t temp ; nx_uint16_t foto ; } RadioMsg_t ; # e n d i f / ∗ GLOBAL_H ∗ / Código 11 .2: ProducerInterceptAppC.nc 118 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 /∗ ∗ =============================================== ∗ U n i v e r s i d a d e de Pernambuco − UPE ∗ D e p a r t a m e n t o de S i s t e m a s e Computacao − DSC ∗ P r o g r a m a de Academico em E n g e n h a r i a da Computacao ∗ O r i e n t a d o r : P r o f . Abel G u i l h e r m i n o da S i l v a F i l h o ∗ Co−o r i e n t a d o r : P r o f . R e n a t o M a r i z de Moraes ∗ A l u n o : F r e d e r i c o Cox ∗ =============================================== ∗ ∗ ∗ . : : A n a l i s e Nodal de E n e r g i a em : : . ∗ . :: Redes de S e n s o r e s sem F i o : : . ∗ ∗ ∗/ # include " Global . h" c o n f i g u r a t i o n P r o d u c e r I n t e r c e p t A p p C {} implementation { c o m p o n e n t s MainC , LedsC , ActiveMessageC , P r o d u c e r I n t e r c e p t C ; c o m p o n e n t s new T i m e r M i l l i C ( ) a s F l a s h T i m e r ; c o m p o n e n t s new T i m e r M i l l i C ( ) a s P r o d u c e r T i m e r ; components C o l l e c t i o n C ; c o m p o n e n t s new C o l l e c t i o n S e n d e r C ( TEMP_PHOTO_ID ) ; c o m p o n e n t s new PhotoC ( ) ; c o m p o n e n t s new TempC ( ) ; /∗ ∗ Wiring ∗/ P r o d u c e r I n t e r c e p t C . Boot −>MainC . Boot ; P r o d u c e r I n t e r c e p t C . Leds −>LedsC . Leds ; P r o d u c e r I n t e r c e p t C . R a d i o C o n t r o l −>A c t i v e M e s s a g e C . S p l i t C o n t r o l ; P r o d u c e r I n t e r c e p t C . P r o d u c e r T i m e r −>P r o d u c e r T i m e r . Timer ; P r o d u c e r I n t e r c e p t C . F l a s h T i m e r −>F l a s h T i m e r . Timer ; P r o d u c e r I n t e r c e p t C . F o t o S e n s o r −>PhotoC . Read ; P r o d u c e r I n t e r c e p t C . TempSensor −>TempC . Read ; /∗ ∗ W i r i n g do P r o t o c o l o C o l l e c t i o n ∗/ P r o d u c e r I n t e r c e p t C . C o l l e c t i o n C o n t r o l −> C o l l e c t i o n C . S t d C o n t r o l ; P r o d u c e r I n t e r c e p t C . Send−> C o l l e c t i o n S e n d e r C . Send ; P r o d u c e r I n t e r c e p t C . I n t e r c e p t −> C o l l e c t i o n C . I n t e r c e p t [ TEMP_PHOTO_ID ] ; } Código 11 .3: ProducerInterceptC.nc 1 /∗ 2 ∗ =============================================== 3 ∗ U n i v e r s i d a d e de Pernambuco − UPE 4 ∗ D e p a r t a m e n t o de S i s t e m a s e Computacao − DSC 5 ∗ P r o g r a m a de Academico em E n g e n h a r i a da Computacao 6 ∗ O r i e n t a d o r : P r o f . Abel G u i l h e r m i n o da S i l v a F i l h o 7 ∗ Co−o r i e n t a d o r : P r o f . R e n a t o M a r i z de Moraes 8 ∗ A l u n o : F r e d e r i c o Cox 9 ∗ =============================================== 10 ∗ 11 ∗ 119 12 ∗ . : : A n a l i s e Nodal de E n e r g i a em : : . 13 ∗ . :: Redes de S e n s o r e s sem F i o : : . 14 ∗ 15 ∗ 16 ∗ / 17 # i n c l u d e " G l o b a l . h " 18 module P r o d u c e r I n t e r c e p t C { 19 uses { 20 i n t e r f a c e Boot ; 21 i n t e r f a c e Leds ; 22 i n t e r f a c e Timer < T M i l l i > a s F l a s h T i m e r ; 23 i n t e r f a c e Timer < T M i l l i > a s P r o d u c e r T i m e r ; 24 /∗ 25 ∗ I n t e r f a c e s do P r o t o c o l o C o l l e c t i o n 26 ∗/ 27 i n t e r f a c e S p l i t C o n t r o l as RadioControl ; 28 i n t e r f a c e StdControl as C o l l e c t i o n C o n t r o l ; 29 i n t e r f a c e Send ; 30 interface Intercept ; 31 /∗ 32 ∗ I n t e r f a c e s da p l a c a mda100cb 33 ∗/ 34 i n t e r f a c e Read< u i n t 1 6 _ t > a s F o t o S e n s o r ; 35 i n t e r f a c e Read< u i n t 1 6 _ t > a s TempSensor ; 36 } 37 } 38 i m p l e m e n t a t i o n { 39 40 uint8_t subState = 0; 41 b o o l ledOn = TRUE ; 42 message_t sndBuffer ; 43 RadioMsg_t ∗ r a d i o P o i n t e r ; 44 uint16_t temperatura = 0; 45 uint16_t foto = 0; 46 47 s t a t i c void updateRoute ( nx_uint16_t ∗ route ) ; 48 49 e v e n t v o i d Boot . b o o t e d ( ) { 50 c a l l RadioControl . s t a r t ( ) ; 51 c a l l TempSensor . r e a d ( ) ; 52 c a l l FotoSensor . read ( ) ; 53 } 54 event void RadioControl . startDone ( e r r o r _ t e r r o r ) { 55 i f ( e r r o r ! =SUCCESS ) { 56 c a l l RadioControl . s t a r t ( ) ; 57 } else { 58 call CollectionControl . start () ; 59 c a l l ProducerTimer . s t a r t P e r i o d i c (10000) ; 60 c a l l Leds . led0On ( ) ; 61 c a l l FlashTimer . startOneShot (100) ; 62 } 63 } 64 65 e v e n t v o i d R a d i o C o n t r o l . s t o p D o n e ( e r r o r _ t e r r o r ) {} 66 e v e n t v o i d Send . sendDone ( m e s s a g e _ t ∗msg , e r r o r _ t e r r o r ) {} 67 68 event void ProducerTimer . f i r e d ( ) { 69 switch ( subState ) { 120 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 case 2 : r a d i o P o i n t e r = ( RadioMsg_t ∗ ) ( c a l l Send . g e t P a y l o a d (& s n d B u f f e r , s i z e o f ( RadioMsg_t ) ) ) ; r a d i o P o i n t e r −>o r i g e m _ i d = TOS_NODE_ID ; r a d i o P o i n t e r −> s a l t o s = 0 ; r a d i o P o i n t e r −> r o t a [ 0 ] = TOS_NODE_ID ; r a d i o P o i n t e r −>temp = t e m p e r a t u r a ; r a d i o P o i n t e r −> f o t o = f o t o ; c a l l Send . s e n d (& s n d B u f f e r , s i z e o f ( RadioMsg_t ) ) ; subState = 0; break ; case 1 : c a l l FotoSensor . read ( ) ; subState = 2; break ; default: c a l l TempSensor . r e a d ( ) ; subState = 1; break ; } } event void FlashTimer . f i r e d ( ) { i f ( ledOn ) { c a l l Leds . led0On ( ) ; c a l l FlashTimer . startOneShot (100) ; } else { c a l l Leds . l e d 0 O f f ( ) ; c a l l FlashTimer . startOneShot (1000) ; } ledOn = ledOn ^ TRUE ; } e v e n t void F oto Sens or . readDone ( e r r o r _ t r e s u l t , u i n t 1 6 _ t v a l ) { i f ( r e s u l t ==SUCCESS ) { foto = val ; } } e v e n t v o i d TempSensor . r e a d D o n e ( e r r o r _ t r e s u l t , u i n t 1 6 _ t v a l ) { i f ( r e s u l t ==SUCCESS ) { temperatura = val ; } } e v e n t b o o l I n t e r c e p t . f o r w a r d ( m e s s a g e _ t ∗msg , v o i d ∗ p a y l o a d , u i n t 8 _ t len ) { RadioMsg_t ∗ RadioFw = ( RadioMsg_t ∗ ) p a y l o a d ; RadioFw−> s a l t o s ++; u p d a t e R o u t e ( RadioFw−> r o t a ) ; r e t u r n TRUE ; } s t a t i c void updateRoute ( nx_uint16_t ∗ route ) { uint8_t i ; f o r ( i = 0 ; i < 5 ; i ++) { i f ( ∗ r o u t e ==0) { ∗ r o u t e = TOS_NODE_ID ; break ; 121 126 } 127 r o u t e ++; 128 } 129 } 130 } Código 11 .4: ConsumerAppC.nc 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 /∗ ∗ =============================================== ∗ U n i v e r s i d a d e de Pernambuco − UPE ∗ D e p a r t a m e n t o de S i s t e m a s e Computacao − DSC ∗ P r o g r a m a de Academico em E n g e n h a r i a da Computacao ∗ O r i e n t a d o r : P r o f . Abel G u i l h e r m i n o da S i l v a F i l h o ∗ Co−o r i e n t a d o r : P r o f . R e n a t o M a r i z de Moraes ∗ A l u n o : F r e d e r i c o Cox ∗ =============================================== ∗ ∗ ∗ . : : A n a l i s e Nodal de E n e r g i a em : : . ∗ . :: Redes de S e n s o r e s sem F i o : : . ∗ ∗ ∗/ # include " Global . h" # include " p r i n t f . h" c o n f i g u r a t i o n ConsumerAppC {} implementation { c o m p o n e n t s MainC , LedsC , ActiveMessageC , ConsumerC , P r i n t f C ; components C o l l e c t i o n C ; /∗ ∗ Wiring ∗/ ConsumerC . Boot −>MainC . Boot ; ConsumerC . R a d i o C o n t r o l −>A c t i v e M e s s a g e C . S p l i t C o n t r o l ; ConsumerC . P r i n t f C o n t r o l −> P r i n t f C . P r i n t f C o n t r o l ; ConsumerC . P r i n t f F l u s h −> P r i n t f C . P r i n t f F l u s h ; /∗ ∗ W i r i n g do P r o t o c o l o C o l l e c t i o n ∗/ ConsumerC . C o l l e c t i o n C o n t r o l −> C o l l e c t i o n C . S t d C o n t r o l ; ConsumerC . R o o t C o n t r o l −> C o l l e c t i o n C . R o o t C o n t r o l ; ConsumerC . R e c e i v e −> C o l l e c t i o n C . R e c e i v e [ TEMP_PHOTO_ID ] ; } Código 11 .5: ConsumerC.nc 1 /∗ 2 ∗ =============================================== 3 ∗ U n i v e r s i d a d e de Pernambuco − UPE 4 ∗ D e p a r t a m e n t o de S i s t e m a s e Computacao − DSC 5 ∗ P r o g r a m a de Academico em E n g e n h a r i a da Computacao 6 ∗ O r i e n t a d o r : P r o f . Abel G u i l h e r m i n o da S i l v a F i l h o 7 ∗ Co−o r i e n t a d o r : P r o f . R e n a t o M a r i z de Moraes 8 ∗ A l u n o : F r e d e r i c o Cox 9 ∗ =============================================== 10 ∗ 11 ∗ 122 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 ∗ . : : A n a l i s e Nodal de E n e r g i a em : : . ∗ . :: Redes de S e n s o r e s sem F i o : : . ∗ ∗ ∗/ # include " Global . h" # include " p r i n t f . h" module ConsumerC { uses { i n t e r f a c e Boot ; interface PrintfFlush ; i n t e r f a c e S p l i t C o n t r o l as P r i n t f C o n t r o l ; /∗ ∗ I n t e r f a c e s do P r o t o c o l o C o l l e c t i o n ∗/ i n t e r f a c e S p l i t C o n t r o l as RadioControl ; i n t e r f a c e StdControl as C o l l e c t i o n C o n t r o l ; i n t e r f a c e RootControl ; i n t e r f a c e Receive ; } } implementation { s t a t i c void updateRoute ( nx_uint16_t ∗ route ) ; e v e n t v o i d Boot . b o o t e d ( ) { c a l l RadioControl . s t a r t ( ) ; } event void RadioControl . startDone ( e r r o r _ t e r r o r ) { i f ( e r r o r ! =SUCCESS ) { c a l l RadioControl . s t a r t ( ) ; } else { c a l l RootControl . setRoot ( ) ; call CollectionControl . start () ; call PrintfControl . start () ; } } e v e n t m e s s a g e _ t ∗ R e c e i v e . r e c e i v e ( m e s s a g e _ t ∗msg , v o i d ∗ p a y l o a d , uint8_t len ) { RadioMsg_t ∗ RadioRx = ( RadioMsg_t ∗ ) p a y l o a d ; RadioRx −> s a l t o s ++; u p d a t e R o u t e ( RadioRx −> r o t a ) ; p r i n t f ( " s r c [%d ] h o p s [%d ] r o u t e [%d ][% d ][% d ][% d ][% d ] temp [%04X] p h o t [%04X ]" , RadioRx −>o r i g e m _ i d , RadioRx −> s a l t o s , RadioRx −> r o t a [ 0 ] , RadioRx −> r o t a [ 1 ] , RadioRx −> r o t a [ 2 ] , RadioRx −> r o t a [ 3 ] , RadioRx −> r o t a [ 4 ] , RadioRx −>temp , RadioRx −> f o t o ) ; call PrintfFlush . flush () ; r e t u r n msg ; } e v e n t v o i d R a d i o C o n t r o l . s t o p D o n e ( e r r o r _ t e r r o r ) {} e v e n t v o i d P r i n t f F l u s h . f l u s h D o n e ( e r r o r _ t e r r o r ) {} 123 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 } event void P r i n t f C o n t r o l . startDone ( e r r o r _ t e r r o r ) { i f ( e r r o r ! =SUCCESS ) { call PrintfControl . start () ; } } e v e n t v o i d P r i n t f C o n t r o l . s t o p D o n e ( e r r o r _ t e r r o r ) {} s t a t i c void updateRoute ( nx_uint16_t ∗ route ) { uint8_t i ; f o r ( i = 0 ; i < 5 ; i ++) { i f ( ∗ r o u t e ==0) { ∗ r o u t e = TOS_NODE_ID ; break ; } r o u t e ++; } } Apêndice VI Código fonte da experiência prática - Tymo Código 12 .1: Makefile 1 ############################################################################## 2 3 4 5 6 7 8 # U n i v e r s i d a d e de Pernambuco − UPE # D e p a r t a m e n t o de S i s t e m a s e Computacao − DSC # P r o g r a m a de Academico em E n g e n h a r i a da Computacao # O r i e n t a d o r : P r o f . Abel G u i l h e r m i n o da S i l v a F i l h o # Co−o r i e n t a d o r : P r o f . R e n a t o M a r i z de Moraes # A l u n o : F r e d e r i c o Cox ############################################################################## 9 # Makefile 10 ############################################################################## 11 12 13 14 15 16 17 # # $ A u t h o r : F r e d Cox $ # $ R e v : 70 $ # $ D a t e : 2008−12−19 16 : 2 0 : 5 1 −0200 ( Sex , 19 Dez 2 0 0 8 ) $ # $ I d : T i n y O S _ P l u g i n _ M a k e f i l e 70 2008−12−19 18 : 2 0 : 5 1 Z F r e d Cox $ # ############################################################################## 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 # V a r i a v e i s de a m b i e n t e COMPONENT=GatewayAppC CFLAGS += −I $ ( TOSDIR ) / −I $ ( TOSDIR ) / −I $ ( TOSDIR ) / −I $ ( TOSDIR ) / −I . TFLAGS += −I ( TOSDIR ) / t y p e s lib lib lib lib / / / / net net net net \ / tymo \ / tymo / dymo \ / tymo / mh \ DOCDIR= html −doc ############################################# # D e f i n i c o e s para o r a d i o − Canal e P o t e n c i a ############################################# 125 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 # PA_LEVEL [dBm] C u r r e n t C o n s u m p t i o n [mA] # 31 0 17.4 # 27 −1 16.5 # 23 −3 15.2 # 19 −5 13.9 # 15 −7 12.5 # 11 −10 11.2 # 7 −15 9.9 # 3 −25 8.5 ############################################# PFLAGS += −DCC2420_DEF_RFPOWER=3 ############################################# # IEEE 8 0 2 . 1 5 . 4 e s p e c i f i c a 16 c a n a i s # n u m e r a d o s de 11 a 26 ############################################# PFLAGS += −DCC2420_DEF_CHANNEL=26 ############################################# # I n c l u e a b i b l i o t e c a p r i n t f NOVA CFLAGS += −I $ ( TOSDIR ) / l i b / p r i n t f / 2 _0_2 ############################################# # Aumenta o p a y l o a d do p r i n t f ############################################# CFLAGS +=−DTOSH_DATA_LENGTH=160 ############################################# # I n c l u e S u p o r t e a p l a c a MDA100 CFLAGS += −I $ ( TOSDIR ) / s e n s o r b o a r d s / mda100 / CFLAGS += −I $ ( TOSDIR ) / s e n s o r b o a r d s / mda100 / cb ############################################# i f d e f APP_MAKERULES i n c l u d e $ (APP_MAKERULES) else i n c l u d e $ (MAKERULES) endif ############################################# Código 12 .2: Global.h 1 /∗ 2 ∗ =============================================== 3 ∗ U n i v e r s i d a d e de Pernambuco − UPE 4 ∗ D e p a r t a m e n t o de S i s t e m a s e Computacao − DSC 5 ∗ P r o g r a m a de Academico em E n g e n h a r i a da Computacao 6 ∗ O r i e n t a d o r : P r o f . Abel G u i l h e r m i n o da S i l v a F i l h o 7 ∗ Co−o r i e n t a d o r : P r o f . R e n a t o M a r i z de Moraes 8 ∗ A l u n o : F r e d e r i c o Cox 9 ∗ =============================================== 10 ∗ 11 ∗ 12 ∗ . : : A n a l i s e Nodal de E n e r g i a em : : . 13 ∗ . :: Redes de S e n s o r e s sem F i o : : . 14 ∗ 15 ∗ 16 ∗ / 17 18 # i f n d e f GLOBAL_H 126 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 # d e f i n e GLOBAL_H /∗ ∗ E n d e r e c o do g a t e w a y ou e s t a c a o b a s e ∗/ enum { DESTINO = 36 }; /∗ ∗ E s t r u t u r a da mensagem do r a d i o ∗/ t y p e d e f n x _ s t r u c t RadioMsg { n x _ u i n t 1 6 _ t origem ; nx_uint16_t perdas ; nx_uint16_t saltos ; n x _ u i n t 1 6 _ t temp ; nx_uint16_t foto ; nx_uint16_t tensao ; nx_uint16_t corrente ; nx_uint16_t contador ; } RadioMsg_t ; # e n d i f / ∗ GLOBAL_H ∗ / Código 12 .3: GatewayAppC.nc 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 /∗ ∗ =============================================== ∗ U n i v e r s i d a d e de Pernambuco − UPE ∗ D e p a r t a m e n t o de S i s t e m a s e Computacao − DSC ∗ P r o g r a m a de Academico em E n g e n h a r i a da Computacao ∗ O r i e n t a d o r : P r o f . Abel G u i l h e r m i n o da S i l v a F i l h o ∗ Co−o r i e n t a d o r : P r o f . R e n a t o M a r i z de Moraes ∗ A l u n o : F r e d e r i c o Cox ∗ =============================================== ∗ ∗ ∗ . : : A n a l i s e Nodal de E n e r g i a em : : . ∗ . :: Redes de S e n s o r e s sem F i o : : . ∗ ∗ ∗/ c o n f i g u r a t i o n GatewayAppC { } implementation { c o m p o n e n t s MainC , LedsC , P r i n t f C , GatewayC , DymoNetworkC ; c o m p o n e n t s new T i m e r M i l l i C ( ) a s F l a s h T i m e r ; GatewayC . Boot −>MainC . Boot ; GatewayC . P r i n t f C o n t r o l −> P r i n t f C . P r i n t f C o n t r o l ; GatewayC . P r i n t f F l u s h −> P r i n t f C . P r i n t f F l u s h ; GatewayC . F l a s h T i m e r −>F l a s h T i m e r ; GatewayC . Leds −>LedsC . Leds ; /∗ ∗ W i r i n g do Tymo ∗/ 127 33 34 35 36 37 38 39 } GatewayC . R a d i o C o n t r o l −>DymoNetworkC . S p l i t C o n t r o l ; GatewayC . MHPacket−>DymoNetworkC . MHPacket ; GatewayC . MHSend−>DymoNetworkC . MHSend [ 1 ] ; GatewayC . R e c e i v e −>DymoNetworkC . R e c e i v e [ 1 ] ; GatewayC . I n t e r c e p t −>DymoNetworkC . I n t e r c e p t [ 1 ] ; Código 12 .4: GatewayC.nc 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 /∗ ∗ =============================================== ∗ U n i v e r s i d a d e de Pernambuco − UPE ∗ D e p a r t a m e n t o de S i s t e m a s e Computacao − DSC ∗ P r o g r a m a de Academico em E n g e n h a r i a da Computacao ∗ O r i e n t a d o r : P r o f . Abel G u i l h e r m i n o da S i l v a F i l h o ∗ Co−o r i e n t a d o r : P r o f . R e n a t o M a r i z de Moraes ∗ A l u n o : F r e d e r i c o Cox ∗ =============================================== ∗ ∗ ∗ . : : A n a l i s e Nodal de E n e r g i a em : : . ∗ . :: Redes de S e n s o r e s sem F i o : : . ∗ ∗ ∗/ # include " p r i n t f . h" # include " Global . h" # i n c l u d e " I2C . h " /∗ ∗ P r o t o c o l o de c o m u n i c a c a o I2C ∗ ∗ ∗ $C# −> S o l i c i t a Consumo ∗ ∗ ∗/ module GatewayC { uses { i n t e r f a c e Boot ; i n t e r f a c e S p l i t C o n t r o l as P r i n t f C o n t r o l ; interface PrintfFlush ; i n t e r f a c e Timer < T M i l l i > a s F l a s h T i m e r ; i n t e r f a c e Leds ; /∗ ∗ I n t e r f a c e s n e c e s s a r i a s do Tymo ∗/ i n t e r f a c e S p l i t C o n t r o l as RadioControl ; i n t e r f a c e AMPacket a s MHPacket ; i n t e r f a c e AMSend a s MHSend ; i n t e r f a c e Receive ; interface Intercept ; } } implementation { 128 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 b o o l ledOn = TRUE ; message_t sndBuffer ; RadioMsg_t ∗ r a d i o P o i n t e r ; e v e n t v o i d Boot . b o o t e d ( ) { c a l l RadioControl . s t a r t ( ) ; } event void RadioControl . startDone ( e r r o r _ t e r r o r ) { i f ( e r r o r ! =SUCCESS ) { c a l l RadioControl . s t a r t ( ) ; } else { call PrintfControl . start () ; } } event void P r i n t f C o n t r o l . startDone ( e r r o r _ t e r r o r ) { i f ( e r r o r ! =SUCCESS ) { call PrintfControl . start () ; } else { c a l l Leds . led0On ( ) ; c a l l FlashTimer . startOneShot (10) ; p r i n t f ( " S e r v i c o s i n i c i a l i z a d o s com s u c e s s o . . . " ) ; call PrintfFlush . flush () ; } } e v e n t v o i d P r i n t f C o n t r o l . s t o p D o n e ( e r r o r _ t e r r o r ) {} e v e n t v o i d P r i n t f F l u s h . f l u s h D o n e ( e r r o r _ t e r r o r ) {} event void FlashTimer . f i r e d ( ) { i f ( ledOn ) { c a l l Leds . led0On ( ) ; c a l l FlashTimer . startOneShot (10) ; } else { c a l l Leds . l e d 0 O f f ( ) ; c a l l FlashTimer . startOneShot (1000) ; } ledOn = ledOn ^ TRUE ; } e v e n t v o i d R a d i o C o n t r o l . s t o p D o n e ( e r r o r _ t e r r o r ) {} e v e n t v o i d MHSend . sendDone ( m e s s a g e _ t ∗msg , e r r o r _ t e r r o r ) {} e v e n t m e s s a g e _ t ∗ R e c e i v e . r e c e i v e ( m e s s a g e _ t ∗msg , v o i d ∗ p a y l o a d , uint8_t len ) { RadioMsg_t ∗ RadioMsg = ( RadioMsg_t ∗ ) p a y l o a d ; i f ( c a l l MHPacket . d e s t i n a t i o n ( msg ) ==DESTINO ) { RadioMsg−> s a l t o s ++; p r i n t f ( "%u;%u;%u;%u;%u;%u;%u;%u \ r \ n " , RadioMsg−>origem , RadioMsg−> s a l t o s , RadioMsg−>p e r d a s , 129 106 107 108 109 110 111 112 113 114 115 116 117 RadioMsg−>temp , RadioMsg−>f o t o , RadioMsg−>t e n s a o , RadioMsg−> c o r r e n t e , RadioMsg−> c o n t a d o r ); call PrintfFlush . flush () ; } r e t u r n msg ; } 118 119 120 121 122 123 124 } e v e n t b o o l I n t e r c e p t . f o r w a r d ( m e s s a g e _ t ∗msg , v o i d ∗ p a y l o a d , u i n t 8 _ t len ) { RadioMsg_t ∗ RadioFw = ( RadioMsg_t ∗ ) p a y l o a d ; RadioFw−> s a l t o s ++; r e t u r n TRUE ; } Código 12 .5: NoColetorAppC.nc 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 /∗ ∗ =============================================== ∗ U n i v e r s i d a d e de Pernambuco − UPE ∗ D e p a r t a m e n t o de S i s t e m a s e Computacao − DSC ∗ P r o g r a m a de Academico em E n g e n h a r i a da Computacao ∗ O r i e n t a d o r : P r o f . Abel G u i l h e r m i n o da S i l v a F i l h o ∗ Co−o r i e n t a d o r : P r o f . R e n a t o M a r i z de Moraes ∗ A l u n o : F r e d e r i c o Cox ∗ =============================================== ∗ ∗ ∗ . : : A n a l i s e Nodal de E n e r g i a em : : . ∗ . :: Redes de S e n s o r e s sem F i o : : . ∗ ∗ ∗/ c o n f i g u r a t i o n NoColetorAppC { } implementation { c o m p o n e n t s MainC , LedsC , P r i n t f C , NoColetorC , MicaBusC , DymoNetworkC ; c o m p o n e n t s new T i m e r M i l l i C ( ) a s F l a s h T i m e r ; c o m p o n e n t s new T i m e r M i l l i C ( ) a s I2CTimer ; c o m p o n e n t s new T i m e r M i l l i C ( ) a s RxTimer ; c o m p o n e n t s new Atm128I2CMasterC ( ) ; c o m p o n e n t s new TempC ( ) ; c o m p o n e n t s new PhotoC ( ) ; N o C o l e t o r C . Boot −>MainC . Boot ; N o C o l e t o r C . P r i n t f C o n t r o l −> P r i n t f C . P r i n t f C o n t r o l ; N o C o l e t o r C . P r i n t f F l u s h −> P r i n t f C . P r i n t f F l u s h ; N o C o l e t o r C . I2CTimer −>I2CTimer ; N o C o l e t o r C . RxTimer−>RxTimer ; N o C o l e t o r C . F l a s h T i m e r −>F l a s h T i m e r ; N o C o l e t o r C . Leds −>LedsC . Leds ; N o C o l e t o r C . TempSensor −>TempC ; 130 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 } N o C o l e t o r C . F o t o S e n s o r −>PhotoC ; /∗ ∗ I2C W i r i n g ∗/ N o C o l e t o r C . R e s o u r c e −>Atm128I2CMasterC ; N o C o l e t o r C . I 2 C P a c k e t −>Atm128I2CMasterC ; N o C o l e t o r C . wakeUpPIC−>MicaBusC . PW2 ; /∗ ∗ W i r i n g do Tymo ∗/ N o C o l e t o r C . R a d i o C o n t r o l −>DymoNetworkC . S p l i t C o n t r o l ; N o C o l e t o r C . MHPacket−>DymoNetworkC . MHPacket ; N o C o l e t o r C . MHSend−>DymoNetworkC . MHSend [ 1 ] ; N o C o l e t o r C . R e c e i v e −>DymoNetworkC . R e c e i v e [ 1 ] ; N o C o l e t o r C . I n t e r c e p t −>DymoNetworkC . I n t e r c e p t [ 1 ] ; Código 12 .6: NoColetorC.nc 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 /∗ ∗ =============================================== ∗ U n i v e r s i d a d e de Pernambuco − UPE ∗ D e p a r t a m e n t o de S i s t e m a s e Computacao − DSC ∗ P r o g r a m a de Academico em E n g e n h a r i a da Computacao ∗ O r i e n t a d o r : P r o f . Abel G u i l h e r m i n o da S i l v a F i l h o ∗ Co−o r i e n t a d o r : P r o f . R e n a t o M a r i z de Moraes ∗ A l u n o : F r e d e r i c o Cox ∗ =============================================== ∗ ∗ ∗ . : : A n a l i s e Nodal de E n e r g i a em : : . ∗ . :: Redes de S e n s o r e s sem F i o : : . ∗ ∗ ∗/ # include " p r i n t f . h" # include " Global . h" # i n c l u d e " I2C . h " /∗ ∗ P r o t o c o l o de c o m u n i c a c a o I2C ∗ ∗ ∗ $C# −> S o l i c i t a Consumo ∗ ∗ ∗/ module N o C o l e t o r C { uses { i n t e r f a c e Boot ; i n t e r f a c e S p l i t C o n t r o l as P r i n t f C o n t r o l ; interface PrintfFlush ; 131 36 /∗ 37 ∗ Timers 38 ∗/ 39 i n t e r f a c e Timer < T M i l l i > a s I2CTimer ; 40 i n t e r f a c e Timer < T M i l l i > a s RxTimer ; 41 i n t e r f a c e Timer < T M i l l i > a s F l a s h T i m e r ; 42 43 /∗ 44 ∗ P r o t o c o l o I2C 45 ∗/ 46 i n t e r f a c e I2CPacket ; 47 i n t e r f a c e Resource ; 48 49 /∗ 50 ∗ I n t e r r u p c a o e x t e r n a INT0 do PIC 51 ∗/ 52 i n t e r f a c e G e n e r a l I O a s wakeUpPIC ; 53 i n t e r f a c e Leds ; 54 55 /∗ 56 ∗ Sensores 57 ∗/ 58 i n t e r f a c e Read< u i n t 1 6 _ t > a s F o t o S e n s o r ; 59 i n t e r f a c e Read< u i n t 1 6 _ t > a s TempSensor ; 60 61 /∗ 62 ∗ I n t e r f a c e s n e c e s s a r i a s do Tymo 63 ∗/ 64 i n t e r f a c e S p l i t C o n t r o l as RadioControl ; 65 i n t e r f a c e AMPacket a s MHPacket ; 66 i n t e r f a c e AMSend a s MHSend ; 67 i n t e r f a c e Receive ; 68 interface Intercept ; 69 } 70 } 71 i m p l e m e n t a t i o n { 72 73 uint8_t txData [ 8 ] ; 74 u i n t 8 _ t rxData [ 1 6 ] ; 75 76 b o o l ledOn = TRUE ; 77 78 u i n t 1 6 _ t tempSensor = 0; 79 uint16_t fotoSensor = 0; 80 81 message_t sndBuffer ; 82 RadioMsg_t ∗ r a d i o P o i n t e r ; 83 84 uint16_t contador = 0; 85 86 uint16_t perdas = 0; 87 88 enum { 89 SLAVE_ADDR = 0 x60 90 }; 91 92 93 task void printRx ( ) ; 132 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 task void sendPacket ( ) ; e v e n t v o i d Boot . b o o t e d ( ) { c a l l RadioControl . s t a r t ( ) ; } event void RadioControl . startDone ( e r r o r _ t e r r o r ) { i f ( e r r o r ! =SUCCESS ) { c a l l RadioControl . s t a r t ( ) ; } else { call PrintfControl . start () ; } } event void P r i n t f C o n t r o l . startDone ( e r r o r _ t e r r o r ) { i f ( e r r o r ! =SUCCESS ) { call PrintfControl . start () ; } else { c a l l wakeUpPIC . makeOutput ( ) ; c a l l wakeUpPIC . c l r ( ) ; c a l l Leds . led0On ( ) ; c a l l I2CTimer . s t a r t P e r i o d i c ( 1 0 0 0 0 ) ; c a l l FlashTimer . startOneShot (10) ; c a l l TempSensor . r e a d ( ) ; c a l l FotoSensor . read ( ) ; p r i n t f ( " S e r v i c o s i n i c i a l i z a d o s com s u c e s s o . . . " ) ; call PrintfFlush . flush () ; } } e v e n t v o i d P r i n t f C o n t r o l . s t o p D o n e ( e r r o r _ t e r r o r ) {} e v e n t v o i d P r i n t f F l u s h . f l u s h D o n e ( e r r o r _ t e r r o r ) {} e v e n t v o i d I2CTimer . f i r e d ( ) { c a l l TempSensor . r e a d ( ) ; c a l l FotoSensor . read ( ) ; c a l l wakeUpPIC . s e t ( ) ; c a l l Resource . r e q u e s t ( ) ; c o n t a d o r ++; } event void Resource . granted ( ) { c a l l Leds . led0On ( ) ; memcpy ( t x D a t a , " $C# " , s t r l e n ( " $C# " ) ) ; c a l l I 2 C P a c k e t . w r i t e ( I2C_START | I2C_STOP , SLAVE_ADDR, s i z e o f ( r x D a t a ) , &t x D a t a [ 0 ] ) ; p r i n t f ( " S o l i c i t a n d o I2C . . . " ) ; call PrintfFlush . flush () ; } async e v e n t void I2CPacket . readDone ( e r r o r _ t e r r o r , u i n t 1 6 _ t addr , uint8_t length , uint8_t ∗ data ) { i f ( e r r o r ==SUCCESS ) { post printRx () ; post sendPacket ( ) ; } c a l l Resource . r e l e a s e ( ) ; c a l l wakeUpPIC . c l r ( ) ; 133 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 } async e v e n t void I2CPacket . writeDone ( e r r o r _ t e r r o r , u i n t 1 6 _ t addr , uint8_t length , uint8_t ∗ data ) { i f ( e r r o r ==SUCCESS ) { c a l l RxTimer . s t a r t O n e S h o t ( 1 0 0 ) ; } else { c a l l Resource . r e l e a s e ( ) ; c a l l wakeUpPIC . c l r ( ) ; } } task void sendPacket ( ) { r a d i o P o i n t e r = ( RadioMsg_t ∗ ) c a l l MHSend . g e t P a y l o a d (& s n d B u f f e r , s i z e o f ( RadioMsg_t ) ) ; r a d i o P o i n t e r −>o r i g e m = TOS_NODE_ID ; r a d i o P o i n t e r −> s a l t o s = 0 ; r a d i o P o i n t e r −> f o t o = fotoSensor ; r a d i o P o i n t e r −>temp = tempSensor ; r a d i o P o i n t e r −> p e r d a s = p e r d a s ; r a d i o P o i n t e r −> t e n s a o = r x D a t a [ 2 ] ; r a d i o P o i n t e r −> t e n s a o = r a d i o P o i n t e r −> t e n s a o < <8; r a d i o P o i n t e r −> t e n s a o = r a d i o P o i n t e r −> t e n s a o | r x D a t a [ 3 ] ; r a d i o P o i n t e r −> c o r r e n t e = r x D a t a [ 4 ] ; r a d i o P o i n t e r −> c o r r e n t e = r a d i o P o i n t e r −> c o r r e n t e < <8; r a d i o P o i n t e r −> c o r r e n t e = r a d i o P o i n t e r −> c o r r e n t e | r x D a t a [ 5 ] ; r a d i o P o i n t e r −> c o n t a d o r = c o n t a d o r ; c a l l MHSend . s e n d ( DESTINO , &s n d B u f f e r , s i z e o f ( RadioMsg_t ) ) ; } task void printRx ( ) { p r i n t f ( " RX: %02X %02X %02X %02X %02X %02X %02X \ r \ n " , r x D a t a [ 0 ] , rxData [ 1 ] , rxData [ 2 ] , rxData [ 3 ] , rxData [ 4 ] , rxData [ 5 ] , rxData [ 6 ] ) ; call PrintfFlush . flush () ; } event void FlashTimer . f i r e d ( ) { i f ( ledOn ) { c a l l Leds . led0On ( ) ; c a l l FlashTimer . startOneShot (10) ; } else { c a l l Leds . l e d 0 O f f ( ) ; c a l l FlashTimer . startOneShot (1000) ; } ledOn = ledOn ^ TRUE ; } event void RadioControl . stopDone ( e r r o r _ t e r r o r ) { } e v e n t v o i d MHSend . sendDone ( m e s s a g e _ t ∗msg , e r r o r _ t e r r o r ) { i f ( e r r o r ==SUCCESS ) { perdas = 0; 134 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 } } else { p e r d a s ++; } } e v e n t m e s s a g e _ t ∗ R e c e i v e . r e c e i v e ( m e s s a g e _ t ∗msg , v o i d ∗ p a y l o a d , uint8_t len ) { r e t u r n msg ; } e v e n t b o o l I n t e r c e p t . f o r w a r d ( m e s s a g e _ t ∗msg , v o i d ∗ p a y l o a d , u i n t 8 _ t len ) { RadioMsg_t ∗ RadioFw = ( RadioMsg_t ∗ ) p a y l o a d ; RadioFw−> s a l t o s ++; r e t u r n TRUE ; } e v e n t v o i d RxTimer . f i r e d ( ) { memset (& r x D a t a [ 0 ] , 0 x00 , s i z e o f ( r x D a t a ) ) ; c a l l I 2 C P a c k e t . r e a d ( I2C_START | I2C_STOP , SLAVE_ADDR, s i z e o f ( r x D a t a ) , &r x D a t a [ 0 ] ) ; } e v e n t void F oto Sens or . readDone ( e r r o r _ t r e s u l t , u i n t 1 6 _ t v a l ) { i f ( r e s u l t ==SUCCESS ) { fotoSensor = val ; } } e v e n t v o i d TempSensor . r e a d D o n e ( e r r o r _ t r e s u l t , u i n t 1 6 _ t v a l ) { i f ( r e s u l t ==SUCCESS ) { tempSensor = val ; } } Código 12 .7: volumes-at45db.xml 1 2 3