UNIVERSIDADE ESTADUAL DE FEIRA DE SANTANA – UEFS DE REDE SEM FIO DE SENSO… · Santana, como...

UNIVERSIDADE ESTADUAL DE FEIRA DE SANTANA – UEFS

Linton Thiago Costa Esteves

PROJETO DE REDE SEM FIO DE SENSORIAMENTO BASEADA NO

PROTOCOLO MiWi

FEIRA DE SANTANA

2011

Linton Thiago Costa Esteves

PROJETO DE REDE SEM FIO DE SENSORIAMENTO BASEADA NO

PROTOCOLO MiWi

Trabalho de Conclusão de Curso apresentado ao

Departamento de Tecnologia, Curso de Engenharia de

Computação da Universidade Estadual de Feira de

Santana, como requisito parcial para a obtenção do título

de Engenheiro de Computação.

Orientador: Prof. Dr. Anfranserai Morais Dias

Feira de Santana

2011

Dedico esse trabalho aos meus pais que sempre

me apoiaram quando precisei e que são um

grande exemplo de garra, caráter e respeito,

uma prova que o esforço e a disciplina são a

base para superar qualquer fronteira,

a minha irmã amada que me trouxe muitos

momentos bons,

a meus avós que sempre me apoiaram e

contribuíram com a minha formação e

a minha namorada que sempre esteve ao meu

lado, me compreendendo e apoiando nos

momentos mais difíceis, sempre trazendo alegria

e paz com o seu sorriso encantador.

AGRADECIMENTOS

Ao professor Doutor Paulo César Machado de Abreu Farias, pelo compromisso e

orientação durante o processo de construção desse trabalho.

Ao professor Doutor Anfranserai Morais Dias, que sempre se mostrou disposto a

ajudar.

Ao professor Doutor Germano Pinto Guedes pelo apoio e orientação;

A Victor Araújo Ferraz, pelo auxílio no processo de revisão da versão anterior do

projeto.

Aos meus colegas de graduação em Engenharia de Computação da UEFS.

RESUMO

Este projeto propôs o estudo da arquitetura de uma rede de sensores para monitoramento

remoto de parâmetros ambientais (temperatura, umidade, insolação, pressão). O sistema

possui um nó coordenador ligado a um computador pessoal via protocolo serial, que

monitora as unidades remotas através de comunicação por rádio. Visando aumentar a

autonomia dos módulos, foram incluídos dispositivos auxiliares de memória, que podem

ser de dois tipos: EEPROM, utilizada nas estações remotas, ou cartões SD, utilizado no

coordenador da rede. Nas estações, a coleta dos dados sensoriais é realizada a intervalos

constantes que podem ser configurados remotamente pelo usuário. A partir do software de

monitoramento instalado no computador pessoal, é possível realizar diversas operações de

monitoramento e configuração dos módulos da base e da estação remota. Esse software foi

desenvolvido com base em técnicas de projeto de interface para o usuário e apresenta uma

interface amigável e intuitiva, o que facilita o processo de adaptação e controle do sistema.

O projeto foi concebido objetivando fornecer uma alternativa configurável pelo usuário e

de baixo custo.

Palavras chave: Automação. Instrumentação. Microcontroladores. Redes de Sensores.

Sensoriamento remoto.

ABSTRACT

This project proposed to study the architecture of a sensor network for remote monitoring

of environmental parameters (temperature, humidity, solar radiation, pressure). The

system has a coordinating node connected to a central computer through a serial protocol

that monitors the remote units via radio communication. In order to increase the autonomy

of the modules were included extra memory devices to the system that may be of two

types: EEPROM, for use in remote stations, or SD cards, for use in the network

coordinator. In remote stations, the collection of sensor data is performed at constant

intervals that can be remotely configured by the user. From the monitoring software

installed on personal computer, it is possible to perform various monitoring and

configuration operations of the modules. This software was developed based on user

interface design techniques and it offers a friendly and intuitive interface which facilitates

the system adaptation process and control. The project was planned to provide an user´s

configurable and low cost alternative.

Keywords: Microcontrollers. Instrumentation. Sensor Network. Automation. Remote

Sensing.

LISTA DE FIGURAS

Figura 1 - Barramento de comunicação I2C. ............................................................................ 15

Figura 2 - Configuração de start e stop de uma comunicação I2C. .......................................... 16

Figura 3 - Tipo de barramento SPI por conexão independente. ............................................... 18

Figura 4 - Topologia estrela...................................................................................................... 22

Figura 5 - Topologia P2P.......................................................................................................... 22

Figura 6 - Ambiente de desenvolvimento com o MiMAC e MiApp (MiWi DE). ................... 24

Figura 7 - Formato do pacote do MiWi P2P. ........................................................................... 27

Figura 8 - Frame Control do pacote do MiWi P2P. ................................................................. 27

Figura 9 - Handshaking padrão do IEEE 802.15.4................................................................... 30

Figura 10 - Processo de handshaking do MiWi P2P. ............................................................... 30

Figura 11 - Módulo transmissor MRF24J40MA. ..................................................................... 31

Figura 12 - Interface do MRF24J40MA com um microcontrolador ........................................ 32

Figura 13 - Diagrama de blocos da arquitetura da primeira versão do módulo remoto ........... 34

Figura 14 - Lógica TTL de entrada e saída .............................................................................. 37

Figura 15 - Arquitetura da estação remota ............................................................................... 39

Figura 16 - Arquitetura da base ................................................................................................ 39

Figura 17 - Processo de configuração do hardware e do protocolo MiWi no coordenador. .... 41

Figura 18 - Processo de configuração do hardware e do protocolo MiWi na Estação. ............ 41

Figura 19 - Struct RECEIVED_MESSAGE. ........................................................................... 44

Figura 20 - Fluxograma da estação remota .............................................................................. 46

Figura 21 - Estrutura de uma amostra ...................................................................................... 47

Figura 22 - Processo de escrita: antes do início do processo (a); início do processo (b); fim

do processo (c) ....................................................................................................... 48

Figura 23 - Processo de leitura: antes do início da leitura (a); início da leitura (b); fim da

leitura (c) ............................................................................................................... 48

Figura 24 - Fluxograma da base ............................................................................................... 52

Figura 25 - Diagrama com as principais classes do software de gerenciamento. .................... 54

Figura 26 - Tela principal do software supervisório................................................................. 55

Figura 27 - Tela de configuração da comunicação serial ......................................................... 56

Figura 28 - Painel de Visualização da Rede ............................................................................. 57

Figura 29 - Abas “Estação” e “Base” da tela principal ............................................................ 58

Figura 30 - Tela de configuração do intervalo de aquisição ..................................................... 58

Figura 31 - Protótipo da estação e da base em matriz de contatos ........................................... 61

Figura 32 - Esquema de ligação da base ................................................................................... 63

Figura 33 - Projeto da placa da base ......................................................................................... 63

Figura 34 - Prótotipo da base .................................................................................................... 64

Figura 35 - Esquema de ligação da estação remota .................................................................. 65

Figura 36 - Projeto da placa da estação .................................................................................... 65

Figura 37 - Protótipo da estação remota ................................................................................... 66

Figura 38 - Interface da base com uma porta RS-232 .............................................................. 66

Figura 39 - Cenário do teste de consistência ............................................................................ 67

Figura 40 - Superposição amostras em 24 de março ................................................................ 68

Figura 41 - Histograma do erro absoluto em 24 de março ....................................................... 68

Figura 42 - Superposição amostras em 25 de março ................................................................ 69

Figura 43 - Histograma do erro absoluto em 25 de março ....................................................... 70

Figura 44 - Fluxo de dados durante o teste ............................................................................... 71

Figura 45 - Gráfico da porcentagem de retorno de pacotes sem verificar período de

aquisição ................................................................................................................ 72

Figura 46 - Gráfico da porcentagem de retorno de pacotes verificando período de

aquisição apenas na estação .................................................................................. 73

Figura 47 - Gráfico da porcentagem de retorno de pacotes verificando o período de

aquisição em ambos os módulos ........................................................................... 74

Figura 48 - Gráfico gerado com a porcentagem de pacotes enviados para a base que foram

identificados .......................................................................................................... 74

Figura 49 - Gráfico com a porcentagem do sucesso de retorno com variação da distância

entre os módulos .................................................................................................... 76

LISTA DE TABELAS

Tabela 1 - Possíveis configurações do clock no protocolo SPI. ............................................... 18

Tabela 2 - Principais comandos do HDBS. .............................................................................. 20

Tabela 3 - Especificações do Frame Control. .......................................................................... 28

Tabela 4 - Lista dos comandos de controle. ............................................................................. 49

Tabela 5 - Comandos de controle da base ................................................................................ 53

Tabela 6 - Lista dos componentes dos módulos ....................................................................... 61

SIGLAS

ACK – Acknowledgement

EEPROM - Electrically-Erasable Programmable Read-Only Memory

EUI - Extended Organization Unique Identifier

FAT - File Allocation Table

FFD - Full-Function Device

I2C - Inter-Integrated Circuit

ISO - International Standards Organization

MiMAC - Microchip Media Access Controller

MiWi - Microchip Wireless

MMC - MultiMediaCard

OSI - Open Systems Interconnection

PAN - Personal Area Network

QoS - Qualidade de Serviço

RFD - Reduced-Function Device

RS-232 - Recommended Standard 232

RTC - Real-Time Clock

RTOS – Real-Time Operating System

SD - Secure Digital

SPI - Serial Peripheral Interface

TAD - Tempo de Aquisição por Bit

USART - Universal Synchronous Asynchronous Receiver Transmitter

WDT - Watch Dog Timer

WPAN - Wireless Personal Area Network

SUMÁRIO

1 INTRODUÇÃO ........................................................................................................ 12

2 FUNDAMENTAÇÃO TEÓRICA .......................................................................... 14

2.1 Protocolo RS-232 .................................................................................................... 14

2.2 Protocolo Inter-Integrated Circuit .......................................................................... 15

2.3 Serial Peripheral Interface ..................................................................................... 17

2.4 Cartões de Memória e Módulo HDBS .................................................................... 19

2.5 Microchip Wireless (MiWi) .................................................................................... 20

2.5.1 Características Gerais do MiWi/IEEE 802.15.4 .................................................. 21

2.5.2 MiWi Development Environment (MiWi DE) ..................................................... 23

2.5.2.1 Microchip Media Access Controller ................................................................. 24

2.5.2.2 MiWi Application Programming Interface ....................................................... 25

2.5.3 Protocolo MiWiTM

P2P ........................................................................................ 25

2.5.3.1 Formato da Mensagem ...................................................................................... 26

2.5.3.2 Enviando e Recebendo uma Mensagem ........................................................... 28

2.5.3.3 Variação do Handshaking ................................................................................. 29

2.6 Módulo MRF24J40MA ........................................................................................... 31

3 DESENVOLVIMENTO .......................................................................................... 33

3.1 Histórico .................................................................................................................. 33

3.1.1 Primeira Fase ........................................................................................................ 33

3.1.2 Segunda Fase ........................................................................................................ 35

3.2 Projeto de Hardware ................................................................................................ 36

3.2.1 Arquitetura da Estação Remota ............................................................................ 38

3.2.2 Arquitetura da Base .............................................................................................. 39

3.3 Projeto de Software ................................................................................................. 40

3.3.1 Configurações Gerais dos Módulos e Funções do Protocolo MiWi .................... 40

3.3.2 Firmware da Estação Remota .............................................................................. 45

3.3.3 Firmware da Base ................................................................................................. 50

3.3.4 Programa do Computador Pessoal ....................................................................... 53

4 RESULTADOS ......................................................................................................... 60

4.1 Projeto e Confecção da Placa de Circuito Impresso ............................................... 60

4.2 Teste de Consistência dos Dados no Dia 24 de Março ........................................... 67

4.3 Teste de Consistência dos Dados no Dia 25 de Março ........................................... 69

4.4 Teste de Eficácia na Transmissão sem Algoritmo de Aquisição ............................ 70

4.5 Teste de eficácia na Transmissão com Algoritmo de Aquisição na Estação .......... 72

4.6 Teste de Eficácia na Transmissão com Algoritmo de Aquisição Total .................. 73

4.7 Teste do Alcance de Transmissão ........................................................................... 75

5 DISCUSSÕES ........................................................................................................... 77

6 CONSIDERAÇÕES FINAIS .................................................................................. 79

REFERÊNCIAS............................................................................................................ 81

12

1 INTRODUÇÃO

O avanço tecnológico atinge todos os setores da atividade humana, trazendo muitas

alterações na forma como as tarefas são realizadas pelo Homem. Essas modificações surgem

no sentido de facilitar o trabalho das pessoas, transformando tarefas complicadas em simples,

o que, consequentemente, aumenta a produtividade e a qualidade do trabalho.

Nesse contexto, o setor de sensoriamento remoto está em franco avanço, onde novas

tecnologias estão sempre surgindo. Dentre esses avanços, o que vem causando maior impacto

é a utilização de protocolos sem fio para controle e monitoramento das estações de aquisição.

Esse modelo possui uma grande mobilidade e versatilidade causada principalmente,

pela ausência de conexões físicas entre seus nós, o que torna mais fáceis e baratas tarefas

como o deslocamento das estações de aquisição e implantação inicial do sistema uma vez que

não há a necessidade de se preocupar com manuseio e acomodação de fiações elétricas.

A exigência de um modelo de implantação e manutenção simples e rápido muitas

vezes se torna um fator crucial na escolha de determinada tecnologia. Regiões de difícil

acesso, por exemplo, tendem a valorizar soluções que privilegiem esses fatores.

Por esses motivos, a escolha de uma rede de sensores sem fio é uma alternativa

interessante para sistemas que utilizem algum tipo de sensoriamento como em monitoramento

ambiental, aplicações militares, vigilância, automação de serviços públicos, monitoramento

hospitalar, dentre outros.

Assim, este projeto propôs o desenvolvimento de uma arquitetura de rede sensorial

para monitoramento remoto de parâmetros ambientais (temperatura, umidade, insolação,

pressão). A arquitetura é composta de dois tipos de unidades: Remota e Base.

A unidade remota se conecta aos sensores calibrados coletando amostras a intervalos

constantes, cujo valor pode ser alterado remotamente através de um comando enviado pela

base, os dados são armazenados em uma memória Electrically-Erasable Programmable

Read-Only Memory (EEPROM) externa, juntamente com um rótulo temporal obtido de um

Real-Time Clock (RTC). Quando solicitado, os dados são enviados via rádio para a base, onde

são armazenados em um cartão de memória e transmitidos via o protocolo Universal

Synchronous Asynchronous Receiver Transmitter (USART) para uma interface externa com

um computador pessoal. Ao receber uma mensagem com uma amostra, o computador

automaticamente a identifica, exibe seu valor em um gráfico e a armazena em um arquivo.

13

A base, por outro, lado funciona como uma central de coleta e gerenciamento das

estações. Ela envia comandos de verificação, configuração e coleta de dados para as estações

remotas, seja de forma automática ou através de solicitações provenientes do computador ao

qual está conectada.

No capitulo 2 é apresentada uma fundamentação teórica onde são discutidas as

tecnologias utilizadas no desenvolvimento da aplicação, juntamente com uma descrição de

alguns dos componentes utilizados no projeto.

O capitulo 3 aborda o desenvolvimento do projeto, onde são apresentadas as etapas

necessárias para a sua conclusão como a definição das arquiteturas dos módulos, concepção

dos firmwares da base e estação e do software de monitoramento a ser instalado em um

computador pessoal.

Sequencialmente, no capitulo 4, são abordados os resultados obtidos no projeto, como

o processo de confecção da placa de circuito impresso e os testes realizados.

Por fim, no capitulo 5, é feita uma discussão acerca dos resultados obtidos, seguida da

conclusão no capitulo 6 e das referências utilizadas.

14

2 FUNDAMENTAÇÃO TEÓRICA

Nesta sessão será feita uma descrição das tecnologias utilizadas no desenvolvimento

do projeto, abrangendo as características tanto dos componentes e periféricos utilizados

quanto dos protocolos de comunicação empregados.

2.1 Protocolo RS-232

O protocolo RS-232 foi criado pela Electronic Industries Association (EIA) para a

comunicação entre um terminal de dados e um comunicador de dados. O pacote é constituído

de 10 ou 11 bits sendo 8 bits para a mensagem, 1 bit de inicio (start bit), 1 bit de parada (stop

bit) e 1 bit de paridade, sendo o último opcional (MIYADAIRA, 2009).

Durante o estado inativo, o canal de transmissão é mantido em nível lógico ‘1’; ao

iniciar o processo de transmissão, primeiramente o canal é colocado em nível ‘0’, indicando

ao receptor que uma mensagem será enviada. O receptor então começa a contar o clock para

receber os dados. Sequencialmente, é enviado um byte iniciado pelo bit menos significativo

seguido pelo bit de paridade e de um Stop bit (MIYADAIRA, 2009).

O bit de paridade é responsável pela verificação de erro na mensagem, podendo ser

utilizada uma paridade par ou ímpar. Na paridade par seu valor é igual a ‘0’ para número par

de bits ‘1’ na mensagem e ‘1’ para um número ímpar de bits ‘1’ (MIYADAIRA, 2009).

O padrão não segue os níveis de tensão CMOS/TTL, apresentando os seguintes

valores:

• 0: tensão entre +3V e +25V

• 1: tensão entre -3V e -25V

• Indefinido: -3V a +3V

Como o microcontrolador opera em um nível de tensão diferente do padrão RS-232, é

necessária a existência de um circuito que realize a tradução entre os dois níveis viabilizando

a comunicação. No projeto, o circuito integrado responsável por realizar essa tradução é o

MAX232 (TEXAS INSTRUMENTS, 2008). Ele funciona como um amplificador/redutor,

15

amplificando o sinal do PIC para o padrão RS-232 e reduzindo o sinal recebido pelo

computador para o nível utilizado pelo PIC.

2.2 Protocolo Inter-Integrated Circuit

O protocolo Inter-Integrated Circuit (I2C) foi desenvolvido pela Philips objetivando

simplificar a comunicação entre dispositivos eletrônicos. Ele é um protocolo síncrono do tipo

mestre-escravo (master-slave) (SANCHEZ; CANTON, 2007).

Esse protocolo se utiliza de um barramento composto por duas linhas, uma para envio

do sinal de clock (Serial Clock Line - SCL) e outra para tráfego dos dados a serem

transmitidos (Serial Data Line - SDA). Sua linha de transmissão de dados é bidirecional

enquanto a de clock é unidirecional, sendo essa última transmitida por um único mestre de

cada vez (SANCHEZ; CANTON, 2007).

O barramento apresenta uma topologia multi-mestre, o que permite a existência de

vários mestres em um mesmo barramento, no entanto, no momento em que um dos

dispositivos assume o papel de mestre, todos os outros devem entrar em modo escravo,

evitando interferências no processo de transmissão. Por necessitar de uma arquitetura mais

complexa, o mestre normalmente é um microcontrolador ou microprocessador

(MIYADAIRA, 2009).

Figura 1 - Barramento de comunicação I

2C.

Fonte: Próprio Autor

Como em um mesmo barramento podem coexistir vários dispositivos, é necessário um

sistema de endereçamento que possa identificar a origem e destino das mensagens. Para tanto,

o I2C prevê que cada dispositivo conectado deve possuir um endereço único, podendo ser de 7

ou 10 bits (SANCHEZ; CANTON, 2007).

16

A comunicação é iniciada (start bit) quando a linha de dado passa do nível lógico ‘1’

para ‘0’, enquanto a linha de clock está em 1. O término de uma transmissão (stop bit) ocorre

quando a linha de dado passa do nível ‘0’ para o nível ‘1’ enquanto a linha de clock está em

nível ‘1’ (MIYADAIRA, 2009), como pode ser visto na Figura 2.

Figura 2 - Configuração de start e stop de uma comunicação I

2C.


Após o envio do start bit, caso o dispositivo possua um endereçamento de 7 bits, o

mestre envia 1 byte pela linha SDA contendo os 7 bits do endereço da memória e um bit para

informar o tipo da operação que será realizada (bit R/W), sendo ‘1’ para leitura e ‘0’ escrita.

Para um endereçamento de 10 bits, são enviados dois bytes, os 5 bits mais significativos do

primeiro byte são constantes e servem para informar que o endereçamento é de 10 bits, os 3

bits restantes representam os bits mais significativos do endereço do dispositivo, já o segundo

byte, apresenta 1 bit para identificar o tipo de operação e os 7 bits restantes do endereçamento

(SANCHEZ; CANTON, 2007; MIYADAIRA, 2009).

Após o envio da mensagem contendo o endereço do dispositivo, aquele que apresenta

o endereço especificado responde ao mestre com um sinal de acknowledgement, forçando a

linha de dados para o nível ‘0’ antes do nono pulso de clock. Se, por algum motivo, não

existir um dispositivo com o endereço enviado ou o dispositivo endereçado não conseguiu

identificar a mensagem, nenhum sinal é enviado ao mestre, tornando possível identificar que

ocorreu algum erro na transmissão. Ao identificar esse erro o mestre envia um stop bit

(MIYADAIRA, 2009).

Os passos seguintes dependerão de qual valor foi atribuído ao bit R/W:

Caso 1 (operação de leitura), o mestre envia 8 pulsos de clock e realiza a leitura

simultânea de 8 bits no barramento DAS. Ao receber o oitavo bit o mestre

responde com um ACK, informando o sucesso da operação de leitura;

17

Caso 0 (operação de escrita) o mestre envia 8 pulsos de clock juntamente com

os 8 bits que se deseja enviar. Ao receber todos os bits o escravo responde ao

mestre através de um ACK na linha de dados. Após a leitura/escrita da

quantidade de dados desejada a comunicação é encerrada com um stop bit.

Um fato simples, mas essencial, é a necessidade da utilização dos resistores de pull-up

(Figura 1). Como os dispositivos conectados ao barramento operam apenas baixando a tensão

do mesmo, esses resistores são essenciais para fixar a tensão em nível alto, evitando que as

duas linhas fiquem flutuando, além de possibilitar identificar de forma eficaz que o

barramento está livre (MIYADAIRA, 2009).

Atualmente muitas famílias de microcontroladores já são fabricados com uma

arquitetura que implementa via hardware o protocolo I2C. Para algumas exceções que não

possuem essa solução via hardware, já existem bibliotecas disponíveis que implementam o

protocolo via software.

2.3 Serial Peripheral Interface

A interface Serial Peripheral Interface (SPI) surgiu como uma solução simples e

eficiente para a conexão de periféricos. Ela opera de forma síncrona no modo full-duplex

suportando um único mestre e diversos escravos conectados ao barramento. Sua velocidade

máxima de transmissão pode alcançar até 70 MHz, a depender dos dispositivos conectados

(IBRAHIM, 2008; MIYADAIRA, 2009).

Diferente do protocolo I2C em que cada dispositivo conectado possui um endereço

específico, nesse padrão, a seleção do dispositivo que o mestre deseja comunicar é realizada

pelo pino de seleção SS/CS (Figura 3). Como o protocolo não padroniza essa seleção, ela

pode ser realizada tanto em nível lógico alto como em baixo, a depender do dispositivo. Vale

ressaltar que o protocolo possibilita dois tipos de conexão, a conexão independente (Figura 3),

e a conexão em cascata (IBRAHIM, 2008; MIYADAIRA, 2009).

18

Figura 3 - Tipo de barramento SPI por conexão independente.


O barramento é formado por 3 linhas:

1. SCK – utilizada pelo mestre para envio do pulso de clock;

2. MOSI – master output, slave input;

3. MISO – master input, slave output.

Quanto ao sinal de clock, o protocolo suporta quatro formas distintas, resultantes da

combinação da polaridade e da fase do clock, como pode ser visto na Tabela 1 (IBRAHIM,

2008; MIYADAIRA, 2009).

Tabela 1 - Possíveis configurações do clock no protocolo SPI.

Modo Polaridade Fase Característica

0 0 0 Polaridade do clock ‘0’, pulso gerado no inicio do período.

1 0 1 Polaridade do clock ‘0’, pulso gerado no final do período.

2 1 0 Polaridade do clock ‘1’, pulso gerado no inicio do período.

0 1 1 Polaridade do clock ‘1’, pulso gerado no final do período.

Fonte: IBRAHIM, 2008.

Normalmente, os dados são transferidos em pacotes de oito bits, podendo variar a

depender da aplicação. Assim que o dispositivo é selecionado pela linha SS a comunicação é

iniciada. Como a comunicação é full-duplex, ao mesmo tempo em que o mestre envia um

comando o escravo também pode enviar. Para finalizar a conexão, o mestre para o sinal de

clock e desabilita o dispositivo (IBRAHIM, 2008; MIYADAIRA, 2009).

19

2.4 Cartões de Memória e Módulo HDBS

Os cartões de memória são dispositivos de armazenamento que utilizam a tecnologia

flash, para armazenamento dos dados. Suas características principais são permitir a

leitura/escrita dos dados por uma grande quantidade de vezes de forma rápida e sem a

necessidade constante de alimentação para manter o armazenamento. Ele é muito utilizado

como unidade de armazenamento em diversos equipamentos eletrônicos como as câmeras

digitais, celulares, videogames e computadores pessoais. Atualmente, a maioria dos

computadores já vem com um leitor de cartão de memória acoplado, o que torna a sua

utilização ainda mais atrativa.

Com o objetivo de atender a demanda crescente por alternativas de armazenamento de

dados, a Tato Equipamentos Eletrônicos desenvolveu o módulo HDBS. Ele é utilizado para

leitura e escrita de cartões de memória nos padrões Secure Digital (SD) e MultiMediaCard

(MMC). Esse módulo possui um microcontrolador embarcado e pode implementar um

sistema de partição dos tipos FAT16 ou FAT32, permitindo que os dados armazenados nos

cartões possam ser lidos também por um computador pessoal (TATO EQUIPAMENTOS

ELETRÔNICOS, 2008).

O HDBS disponibiliza o controle por comandos pré-definidos. Esses comandos

abrangem diversos modos de abertura de arquivos, operações de leitura ou escrita,

manipulação de diretórios, inicialização da interface, gerenciamento dos sistemas de arquivos,

dentre outros. É importante salientar que a quantidade de comandos existentes é suficiente

para o manuseio adequado dos cartões.

Para realizar uma operação, o usuário envia a string do comando correspondente

através de uma comunicação serial , em grupos de 8 bits, seguido do comando “\r\n” o que

identifica o fim da mensagem. Na Tabela 2 é possível visualizar uma lista dos principais

comandos utilizados no projeto (TATO EQUIPAMENTOS ELETRÔNICOS, 2008).

20

Tabela 2 - Principais comandos do HDBS.

Comando Funcionalidade Exemplo

HDRESET Reinicia o módulo printf("hdreset\r\n");

HDINIT Inicia o módulo printf("hdinit\r\n");

FS Inicia o sistema de

arquivos

printf("fs\r\n");

FOA <filename>,

[<file#r>]

Abre um arquivo printf("\r\nfoa nomeArquivo.txt,

1\r\n");

WL <file#>, <text> Escreve uma linha no

arquivo

printf("wl 1, %d\r\n", informação);

CLOSE <file#> Fecha um arquivo printf("\r\nclose 1\r\n");

Fonte: TATO EQUIPAMENTOS ELETRÔNICOS, 2008.

2.5 Microchip Wireless (MiWi)

Atualmente, existe no mercado uma forte demanda por aplicações de monitoramento

ou controle sem fio que apresentem uma arquitetura simples, baixo custo de desenvolvimento

e baixo consumo, sem deixar de lado uma boa consistência no processo de envio e recepção

de pacotes.

Dentre os protocolos existentes nesse segmento destaca-se o Microchip Wireless

(MiWi) (MICROCHIP TECHNOLOGY INC., 2010b). Ele é baseado nas especificações do

padrão IEEE 802.15.4 que definem as camadas físicas e MAC, fornecendo uma base para o

desenvolvimento de protocolos sem fio (IEEE COMPUTER SOCIETY, 2003).

Como as características e funcionalidade gerais do MiWi em sua maioria são

semelhantes as do IEEE 802.15.4, na seção 2.5.1 serão abordadas funcionalidades

compartilhadas pelo padrão IEEE 802.15.4 e pelo protocolo MiWi. Na seção 2.5.2, será

apresentado o framework desenvolvido pela Microchip para construção de projetos sem fio, o

MiWi Development Environment (MICROCHIP TECHNOLOGY INC., 2010b). Por fim, na

seção 2.5.3, serão abordadas características específicas do MiWi P2P (YANG, 2010),

variação do MiWi utilizada no projeto.

21

2.5.1 Características Gerais do MiWi/IEEE 802.15.4

Normalmente, os módulos para transmissão de dados sem fio possuem dois estados de

funcionamento: ativo e dormindo. No modo ativo o dispositivo se encontra em pleno

funcionamento apresentando um elevado consumo energético, sendo apenas nesse estado que

uma comunicação é possível. Já no modo dormir, grande parte dos periféricos e

funcionalidades são desabilitadas permitindo uma redução significativa no consumo (IEEE

COMPUTER SOCIETY, 2003).

Com essa base, o modelo IEEE 802.15.4 propõe um protocolo de comunicação com

um baixo ciclo de trabalho, mantendo o sistema a maior parte do tempo em modo dormir, o

que diminui o consumo (IEEE COMPUTER SOCIETY, 2003).

O modelo suporta apenas comunicação digital de dados, não suportando serviços

analógicos, o que permite a adoção de um algoritmo de modulação eficiente produzindo uma

redução do consumo energético (IEEE COMPUTER SOCIETY, 2003).

Além disso, possui um eficaz controle de erros assegurando uma transferência de

dados confiável e uma boa qualidade de serviço (QoS). Em cada pacote transmitido é

realizado um cálculo sobre os bits transmitidos, gerando um valor de paridade o qual é

transmitido juntamente com o cabeçalho da mensagem. Ao chegar ao destino, a mesma

operação é realizada e o valor obtido é comparado com o valor de paridade da mensagem.

Caso os dois valores sejam iguais é possível afirmar que os dados foram recebidos

corretamente (IEEE COMPUTER SOCIETY, 2003).

Dentro de uma rede Wireless Personal Area Network (WPAN) existem basicamente

dois tipos de dispositivos: o Reduced-Function Device (RFD) e o Full-Function Device

(FFD). Os FFD são mais complexos e podem operar em dois modos, coordenador ou

dispositivo final. Eles podem se comunicar com outros FFD ou com RFD. Toda rede WPAN

tem que ter obrigatoriamente um FFD funcionando como um Personal Area Network (PAN)

Coordinator. Já os RFD são mais simples por serem construídos com recursos minimizados e

podem se comunicar apenas com FFD (ver figuras 4 e 5). Quando uma rede é criada o PAN

coordinator deve ser iniciado primeiro, seguido dos outros FFD e dos RFD (IEEE


Esse padrão possibilita a utilização de duas topologias de rede: star (estrela) (Figura 4)

e peer-to-peer (ponto a ponto ou P2P) (Figura 5). Basicamente, a topologia estrela possui um

22

único dispositivo coordenador no centro que gerencia as transferências da rede fornecendo as

rotas, iniciando e terminando uma comunicação (IEEE COMPUTER SOCIETY, 2003). A

topologia P2P, assim como a estrela possui um dispositivo controlador, no entanto, os outros

dispositivos podem comunicar entre si, não sendo necessário que toda comunicação seja

intermediada pelo coordenador. Essa característica permite a construção de redes mais

complexas (IEEE COMPUTER SOCIETY, 2003).

Figura 4 - Topologia estrela.

Fonte: YANG, 2010.

Figura 5 - Topologia P2P.

Fonte: YANG, 2010.

O IEEE 802.15.4 define dois tipos de controle de transmissão: beacon e non-beacon.

Em uma rede beacon cada dispositivo possui um intervalo de tempo determinado pelo

coordenador para realizar uma comunicação e assim transmitir dados. Esse processo

aperfeiçoa a economia de energia de todos os dispositivos da rede, pois os rádios são ligados

apenas durante os períodos de transmissão, ficando, então, desligados a maior parte do tempo

(IEEE COMPUTER SOCIETY, 2003).

23

Já em uma rede non-beacon os dispositivos podem transmitir a qualquer momento, o

que aumenta o consumo de energia do PAN coordinator, mas ainda assim possibilita que os

RFD diminuam o seu consumo por não necessitar de uma sincronização frequente (IEEE


Existem dois tipos de endereços nessa especificação: Extended Address, composto de

oito bytes e único, e o Short Address, composto de dois bytes cujo valor é atribuído ao

dispositivo quando ele se conecta a rede.

2.5.2 MiWi Development Environment (MiWi DE)

Visando facilitar e incentivar o uso do MiWi, a Microchip criou o MiWi Development

Environment (MICROCHIP TECHNOLOGY INC., 2010b), um framework que possibilita a

construção de projetos com arquitetura MiWi de forma simples e eficaz.

Com o MiWi DE é possível que alterações antes complexas, como mudança de

protocolo ou de módulo de rádio frequência utilizado, sejam bem menos custosas, tornando

possível a construção de projetos mais flexíveis.

A simplicidade na realização dessas tarefas se dá principalmente pela utilização de

dois frameworks: o MiMAC (YANG, 2009b) e o MiApp (YANG, 2009a). Eles possibilitam

a abstração e generalização de muitas das funcionalidades necessárias nesses tipos de redes.

O MiWi DE é subdividido em três camadas: camada de aplicação, camada de

protocolo e camada de configuração do transmissor (Figura 6).

O papel do MiMAC e do MiApp é justamente fazer a ligações entre essas camadas. A

camada de aplicação utiliza o MiApp para se comunicar com a camada de protocolo enquanto

a camada de protocolo se comunica com os módulos RF através do MiMAC (Figura 6).

24

Figura 6 - Ambiente de desenvolvimento com o MiMAC e MiApp (MiWi DE).

Fonte: YANG, 2009a.

2.5.2.1 Microchip Media Access Controller

A Microchip desenvolveu o Microchip Media Acess Controller (MiMAC) com o

intuito de padronizar a camada MAC para protocolos de comunicação que utilizam

transmissores sem fio de curto alcance e baixo consumo de energia. O MiMAC propõe uma

pilha protocolar simples e de fácil uso, quando comparado aos outros protocolos sem fio

existentes voltados para redes Wireless Personal Area Network (WPAN), o que facilita a sua

implementação e utilização. Consequentemente, essas características reduzem o custo de

implantação do mesmo (YANG, 2009b).

Devido a possibilidade de ser aplicado a todos os transmissores fabricados pela

Microchip, é possível ao usuário final a mudança de transmissor em qualquer estágio de

desenvolvimento, sem que isso cause grandes custos ao projeto. Esse processo pode ser

realizado com a mudança de um parâmetro de configuração no firmware (YANG, 2009b).

25

2.5.2.2 MiWi Application Programming Interface

O MiWi Application Programming Interface (MiApp) é o responsável por fazer a

ligação entre a camada de aplicação e a camada do protocolo sem fio utilizado. Ele é dividido

em duas partes: arquivos de configurações e conjunto de funções.

Nos arquivos de configurações é possível ao usuário configurar o hardware utilizado

no projeto, definindo as especificações de cada porta, o tipo de dispositivo RF adotado bem

como a seleção do protocolo que será utilizado na aplicação (YANG, 2009a).

Já o conjunto de funções possibilita ao usuário realizar diversas operações como envio

e recepção de dados sem fio, inicialização do módulo RF, operações de handshaking além de

outras funcionalidades especiais (YANG, 2009a).

A partir do conjunto de configurações presentes nos arquivos de configurações o

MiApp possibilita a realização de operações específicas, aumentando assim a flexibilidade do

projeto, uma vez que, para a mudança de protocolo ou de algum hardware, não são

necessárias grandes mudanças no código da aplicação apenas nos arquivos de configuração

(YANG, 2009a).

Com esse framework, o processo de configuração e operação de protocolos sem fio se

torna uma tarefa muito mais simples, pois, nesse ponto, não é necessário ao desenvolvedor se

preocupar com detalhes mais específicos de cada processo, diminuindo, assim, o tempo

necessário para a construção de projetos sem fio.

Para maiores detalhes sobre o framework favor consultar o documento 1284 da

Microchip (YANG, 2009a), o qual contém o conjunto de funções e configurações possíveis

do MiApp.

2.5.3 Protocolo MiWiTM

P2P

O protocolo MiWi P2P (YANG, 2010) é fundamentado nas especificações do IEEE

802.15.4. No entanto, ele apresenta uma camada MAC diferente do padrão, que simplifica o

processo de handshaking, diminuindo as operações de conexão.

Suas principais características são:

26

Suporte a diversas famílias de microcontroladores fabricados pela Microchip

como os PIC18, PIC24, dsPIC32 e dsPIC33;

Compiladores C18, C32 e C40;

Funciona como uma máquina de estados, o que o torna independente de um

Real-Time Operating System (RTOS);

Possibilita a utilização do estado sleep ao final de uma comunicação;

Permite a utilização da função de detecção de energia, para operar com o sinal

que apresenta o menor ruído e a troca de canal;

Topologias P2P e estrela;

Suporta apenas redes do tipo non-beacon.

Com relação ao tipo de endereçamento. as regras são as mesmas do IEEE 802.15.4,

existindo o short address e o extended address. No entanto, o short address é utilizado apenas

para mensagens broadcasts. Além disso, o extended address ou Extended Organization

Unique Identifier (EUI) pode variar de 2 a 8 bytes, a depender das necessidades da aplicação

(YANG, 2010).

2.5.3.1 Formato da Mensagem

O formato do pacote enviado pelo protocolo MiWi P2P (Figura 7) é subdividido em 8

campos:

1. Frame Control;

2. Sequence Number;

3. Destination PAN ID;

4. Destination address;

5. Source PAN ID;

6. Source Address;

7. Pay Load; e

8. Frame Check Sequence.

27

Figura 7 - Formato do pacote do MiWi P2P.

Fonte: YANG, 2010.

O Frame Control é composto por 2 bytes onde são armazenadas informações de

controle do pacote (Figura 8). A Tabela 3 apresenta as suas funcionalidades e os possíveis

valores dos seus campos.

Figura 8 - Frame Control do pacote do MiWi P2P.

Fonte: YANG, 2010.

O Sequence Number é formado por um byte, cujo valor é incrementado a cada pacote

enviado. Ele é utilizado pelo pacote de ACK para identificar o pacote.

O Source e Destination PAN Identifier definem o PAN Identifier de origem e de

destino respectivamente. Como a versão atual do protocolo MiWi P2P possibilita apenas

mensagens em uma mesma rede, o Source PAN Identifier não é utilizado e o Destination

PAN Identifier é definido com o valor 0xFFFF (broadcast PAN Identifier) (YANG, 2010).

O campo de endereço de destino (Destination Address) pode ser do tipo short ou

extended address. Seu tipo deve ser compatível com o configurado no Destination Address

Mode. O short address é utilizado apenas para mensagens broadcast e apresenta por padrão o

valor 0xFFFF. O Source Address pode ser apenas do tipo extended address e armazena o

endereço do dispositivo que enviou o pacote (YANG, 2010).

28

Tabela 3 - Especificações do Frame Control.

Nome do campo Bits Valores Funcionalidade

Frame Type 3 001 – Data Frame

010 - Acknowledgement

011 – Command Frame

Define o tipo do pacote

Security Enable 1 1 – segurança habilitada

0 – segurança desabilitada

Identifica se a mensagem é

criptografada

Frame pending 1 1 – existe pacote adicional

0 – não há pacote adicional

Indica se um pacote

adicional é esperado após

um ACK.

Acknowledgement

Request

1 1 – requisição de ACK

0 – não necessita ACK

Indica a necessidade de um

acknowledgement

Intra PAN 1 1 – Source PAN ID é omitido

0 – Source PAN ID é exibido

Determina se a mensagem

apresentará o Source PAN

ID.

Destination

Address Mode

2 10 – Short address

11 – Extended address

Tipo de endereço do

dispositivo destino

Source Address

Mode

2 11 - Só pode ser do tipo

extended address no

protocolo MiWi P2P

Tipo de endereço da fonte

Fonte: YANG, 2010.

2.5.3.2 Enviando e Recebendo uma Mensagem

O protocolo MiWi P2P suporta apenas dois modos de envio de uma mensagem:

broadcast ou unicast.

Mensagem do tipo broadcast tem como destino final todos os dispositivos ao alcance

daquele que estiver enviando. O padrão IEEE 802.15.4 tem por definição um short address

específico que identifica mensagens do tipo broadcast. Como não existe um endereço com

essa mesma funcionalidade do tipo extended address, todas as mensagens de broadcast

utilizam um short address. Além disso, essas mensagens não necessitam de um ACK

(YANG, 2010).

As mensagens unicast tem apenas um único destino, por isso, é necessário informar na

mensagem o endereço do destino, sendo então obrigatória a utilização de um extended

address. Diferente das mensagens broadcast, todas as mensagens unicast são seguidas de um

Acknowledgement, identificando o sucesso da transmissão.

Uma funcionalidade bastante interessante no envio de mensagens unicast é a

utilização de indirect message. Quando o dispositivo de destino está com o seu rádio

29

desligado ele fica incapaz de receber ou transmitir uma mensagem, tornando inviável uma

comunicação durante esse período. O indirect message permite que, mesmo nesse tipo de

situação, uma mensagem possa ser enviada. Ao detectar que o rádio do destino está desligado,

o emissor automaticamente armazena aquela informação em memória até que o dispositivo

“acorde” e torne-se apto para receber o pacote (YANG, 2010).

No entanto, seria muito custoso armazenar para sempre mensagens nessas situações, o

que poderia causar uma sobrecarga na memória. Uma forma de evitar essa situação foi a

criação do indirect message time-out. Ele armazena o tempo máximo que as mensagens

podem ficar em espera até que o dispositivo “acorde”. Caso o tempo nele estipulado seja

“estourado”, a mensagem é então descartada (YANG, 2010).

O padrão define que apenas aquele dispositivo de destino da mensagem será

notificado. Quando ele estiver com o rádio em estado “dormindo” e quiser mudar para o

estado “ativo” é necessário que, após essa operação, seja enviada uma mensagem de data

request para informar aos outros que seu rádio está novamente ativo e que estará apto a

realizar uma comunicação (YANG, 2010).

2.5.3.3 Variação do Handshaking

A maior diferença do protocolo MiWi P2P para as especificações do IEEE 802.15.4

está no processo de handshaking.

Para a realização do handshaking seguindo as especificações do IEEE, é necessário

seguir cinco procedimentos, conforme apresentado na Figura 9(YANG, 2010):

1. O dispositivo que deseja se comunicar envia uma beacon request;

2. Todos os dispositivos capazes de realizar uma comunicação respondem com

uma mensagem beacon;

3. O dispositivo inicial coleta todas as respostas e seleciona uma para estabelecer

a conexão enviando uma requisição de associação;

4. Após um período de tempo o dispositivo inicial envia uma requisição de dados

para solicitar a resposta da requisição de associação;

5. O outro dispositivo envia a resposta de associação.

30

Figura 9 - Handshaking padrão do IEEE 802.15.4.

Fonte: YANG, 2010.

Com esses passos, cada dispositivo pode estabelecer apenas uma conexão, o que

inviabiliza a ideia de múltiplas conexões proposta em uma conexão P2P.

O processo de handshaking desenvolvido pelo IEEE, por apresentar um

funcionamento robusto, necessita de uma arquitetura mais trabalhada, o que inviabiliza sua

utilização em aplicações que dispõem de poucos recursos.

Visando resolver essas duas barreiras, o MiWi P2P desenvolveu um processo de

handshaking mais simples com apenas dois passos (YANG, 2010):

1. O dispositivo inicial envia uma requisição de conexão P2P;

2. Qualquer dispositivo ao alcance responde com um comando P2P connection

responde finalizando a conexão.

Figura 10 - Processo de handshaking do MiWi P2P.

Fonte: YANG, 2010.

Com esse modelo, torna-se possível a realização de conexões múltiplas permitindo a

construção de uma rede P2P. No entanto, essa funcionalidade será possível apenas para FFD

que estabelecerão múltiplas conexões com outros FFD ou RFD. Enquanto isso, no RFD

31

existirá apenas uma única conexão que será estabelecida com o dispositivo que primeiro

enviar o comando de P2P Connection Request (YANG, 2010).

2.6 Módulo MRF24J40MA

O MRF24J40MA (Figura 11) é um módulo de emissão e recepção de sinais via rádio,

desenvolvido pela Microchip para atender a demanda das aplicações que utilizam o padrão

IEEE 802.15.4. Ele implementa em hardware as camadas físicas e MAC do modelo OSI,

sendo a última baseada no padrão IEEE 802.15.4, o que facilita a interação com os protocolos

ZigBee®, MiWi™, MiWi™ P2P, dentre outros (MICROCHIP TECHNOLOGY INC.,

2008b).

Figura 11 - Módulo transmissor MRF24J40MA.

Fonte: MICROCHIP TECHNOLOGY INC., 2008b.

Algumas de suas características gerais são:

Faixa de operação entre 2,4V e 3,6V

Compatível com as famílias de microcontroladores PIC16F, PIC18F,

PIC24F/H, dsPIC33 e PIC32;

Alcance do rádio de até 400 metros (em local aberto);

Cristal interno;

Módulo de segurança implementado em hardware;

Baixo consumo:

o Modo RX: 19 mA;

o Modo TX: 23 mA;

o Modo Sleep: 2 μA.

32

Sua interface externa com um microcontrolador é realizada por um barramento SPI de

quatro vias, e mais 3 pinos: interrupção, wake e reset (Figura 12) (MICROCHIP

TECHNOLOGY INC., 2008b).

Figura 12 - Interface do MRF24J40MA com um microcontrolador

Fonte: MICROCHIP TECHNOLOGY INC., 2008b.

33

3 DESENVOLVIMENTO

Como dito anteriormente, o objetivo principal do projeto é construir uma rede de

sensores sem fio para aquisição de dados remotamente. A rede é composta de dois tipos de

módulos: a estação remota e a base.

A estação remota opera como um ponto de coleta de informações, onde os sensores

estão acoplados. Suas principais tarefas são a coleta dos dados provenientes dos sensores, seu

armazenamento juntamente com os respectivos rótulos temporais e envio via rádio dessas

informações para a estação base.

Já a estação base trabalha como coordenador da rede e concentrador de informações.

Ela solicita constantemente que as estações remotas enviem os dados coletados,

armazenando-os em memória e/ou os enviando para um computador pessoal ao qual está

conectada.

Nos subtópicos a seguir, serão apresentados com detalhes o histórico de

desenvolvimento do projeto, o projeto em hardware da base e da estação e, por fim, os

softwares construídos.

3.1 Histórico

A concepção do projeto nos moldes atuais foi possível graças à realização de diversas

tarefas e à superação de algumas barreiras. Esse processo pode ser subdividido em duas fases:

a primeira realizada pelo aluno Victor Ferraz (FERRAZ, 2008) e a segunda concebida pelo

aluno Linton Thiago. Ambas as fases serão explicadas respectivamente nas seções 3.1.1 e

3.1.2 dessa monografia.

3.1.1 Primeira Fase

Na primeira fase, um dos principais desafios foi a identificação dos componentes

necessários ao sistema. Optou-se por utilizar um microcontrolador PIC18F4550 como

34

dispositivo controlador das estações remotas e da base. Essa escolha foi orientada

principalmente pelas características de desempenho, facilidade de desenvolvimento e baixo

custo destes dispositivos (MICROCHIP TECHNOLOGY INC., 2010d; FERRAZ, 2008).

Nessa etapa verificou-se a necessidade de expansão da memória, já que as estações

devem ter um bom período de autonomia. Nesse momento, foram incluídas memórias

EEPROM extras através de um 24FC512 (MICROCHIP TECHNOLOGY INC., 2010c;

FERRAZ, 2008).

Devido a aplicação, os dados coletados devem ser rotulados com data e hora. Para

isso, utilizou-se um RTC como fornecedor dessas informações. Dentre os circuitos

pesquisados, escolheu-se o DS1302 (FERRAZ, 2008).

Apesar da existência de uma grande variedade de formas de comunicação que

poderiam ser utilizadas no projeto para a comunicação entre a base local e a estação remota,

um fator decisivo na escolha foi a facilidade de operação. Pensando nisso, a equipe optou por

utilizar uma comunicação via rádio frequência entre a base e a estação utilizando o circuito

integrado TRF2.4G (LAIPAC TECHNOLOGY INC., 2008). Já a comunicação da base local

com o computador central foi inicialmente estabelecida via uma interface serial

Recommended Standard 232 (RS-232) (FERRAZ, 2008).

Dessa forma, esse primeiro protótipo da estação seria composto por um

microcontrolador como unidade central controladora e nele estariam ligados o RTC, a

memória EEPROM, o TRF2.4G e os sensores, como pode ser visualizado na figura 13.

Figura 13 - Diagrama de blocos da arquitetura da primeira versão do módulo remoto

Fonte: FERRAZ, 2008.

35

Já a base apresentava uma arquitetura mais simples, contendo apenas o

microcontrolador, o módulo para transmissão via rádio e uma comunicação serial com o

computador. Como não existia um sistema de armazenamento próprio da base, era necessária

uma conexão constante com um computador pessoal para coleta dos dados recebidos.

3.1.2 Segunda Fase

Na segunda fase, a primeira tarefa realizada foi a migração do compilador utilizado,

do CCS C Compiler (CCS, 2010) para o C18 (MICROCHIP TECHNOLOGY INC., 2010a).

Uma das principais razões para essa alteração foi a necessidade de um compilador que

apresentasse uma documentação mais detalhada e, consequentemente, um melhor suporte.

Nesse quesito, a Microchip, fabricante do C18, apresenta uma proposta muito mais atraente

que a fornecida pela CCS, por oferecer uma série de exemplos, frameworks e notas de

aplicações, o que facilita o processo de estudo de novas tecnologias e, consequentemente,

proporciona um aumento na eficiência do desenvolvimento das aplicações.

No entanto, essa alteração invalidou o código do projeto construído no CCS até então,

uma vez que, com a utilização de um compilador diferente, as funções, estrutura do projeto e

parâmetros utilizados não seriam mais os mesmos.

Visando aumentar a capacidade de armazenamento de dados, o módulo HDBS foi

acoplado ao sistema possibilitando, assim, a escrita em cartões de memória do tipo SD/MMC.

Apesar de já existir uma alternativa para a transmissão dos dados via rádio, a equipe

optou pela substituição do protocolo existente por um que apresentasse uma maior robustez e

que já estivesse mais consolidado no mercado, o que possibilitaria a construção de redes mais

complexas de uma forma mais simples e eficiente.

Após um levantamento dos protocolos existentes no mercado, optou-se pela utilização

do protocolo MiWi, cujas características principais (versatilidade, baixo consumo e

confiabilidade na transmissão dos dados) condiziam com a proposta do projeto.

O MiWi é um protocolo desenvolvido pela Microchip que surgiu a partir das

especificações do IEEE 802.15.4. Atualmente, existem duas versões desse protocolo, o MiWi

P2P e o MiWi Mesh. A rede P2P, por apresentar uma topologia mais simples que as redes

mesh, viabiliza a construção do protocolo em microcontroladores com recursos mais

36

limitados, sendo esse o principal motivo da sua utilização no projeto (MICROCHIP

TECHNOLOGY INC., 2010b).

Por ser um protocolo sem fio mais complexo que o utilizado anteriormente, o MiWi

P2P produz um firmware que ocupa uma quantidade de memória maior. E, apesar do MiWi

DE possibilitar uma minimização da quantidade de memória ocupada no microcontrolador, tal

prática se torna inviável de ser utilizada com o PIC18F4550. Como o firmware gerado com

apenas o protocolo ocupa aproximadamente 20 kbytes de sua memória, restariam 12 Kbytes

para a inserção das outras funcionalidades do módulo, o que é insuficiente.

Sendo assim, foi necessária a migração de microcontrolador, de um PIC18F4550, com

32 kbytes de memória, para um PIC18F4620 (MICROCHIP TECHNOLOGY INC., 2008a)

com 64 kbytes. Com essa mudança, passou a existir memória suficiente para a incorporação

de todas as funcionalidades pretendidas, além de possibilitar a inserção de funcionalidades

futuras, caso necessário.

Com a escolha do protocolo de comunicação sem fio, a próxima etapa foi selecionar

um módulo RF que suportasse o MiWi e apresentasse características compatíveis com as

necessidades do projeto. Dentre os módulos pesquisados, o que mais se destacou foi o

MRF24J40MA (MICROCHIP TECHNOLOGY INC., 2008b). Esse módulo possui uma vasta

documentação e já está em uma versão bastante estável, o que levou a equipe a acreditar que

sua utilização traria benefícios para o projeto, fornecendo uma alternativa confiável para a

transmissão/recepção de informações.

3.2 Projeto de Hardware

Como dito anteriormente, a rede construída é composta de dois módulos: a estação

remota e a base. Esses módulos, apesar de apresentarem funcionalidades distintas, possuem

algumas características em comum:

1. Envio e recepção de dados via rádio;

2. Análise do tempo; e

3. Interface de comunicação com um computador pessoal.

Para atender ao primeiro requisito, em ambos os módulos foi inserido um transmissor

via rádio frequência, o MRF24J40MA (MICROCHIP TECHNOLOGY INC., 2008b). No

37

entanto, esse transmissor apresenta uma tensão de operação de 3,3V, inferior a faixa de

operação do HDBS que é de 5V . Sendo assim, na base foi necessária a utilização de dois

reguladores de tensão: um LM7805 para regular em 5V a alimentação do HDBS, e um

LM1117 para ajustar em 3,3V a alimentação dos demais componentes do módulo. Por não

possuir essa necessidade, na estação remota não foi necessária a utilização de dois

reguladores, bastando apenas o LM1117.

Tal prática foi possível devido ao HDBS apresentar lógica TTL, o que torna viável a

identificação de sinais com níveis menores do que 3,3V, como pode ser observado na

figura14. Caso a tensão de operação do rádio transmissor fosse inferior a 2V, tal prática não

seria possível.

Figura 14 - Lógica TTL de entrada e saída


Tanto a base, como a estação, necessitam constantemente de informações temporais,

uma vez que, boa parte de suas ações são realizadas a partir de intervalos de tempos pré-

determinados. Pensando nisso, em ambos os módulos foram inseridos um DS1302.

A interface com um computador pessoal, na segunda fase, inicialmente foi obtida

através do protocolo de comunicação USB. No entanto, com a mudança de microcontrolador

do PIC18F4550 para o PIC18F4620 essa funcionalidade teve que ser removida uma vez que,

diferente do PIC18F4550, o PIC18F4620 não possui suporte a USB. Por outro lado, no

mercado existem diversos módulos que possibilitam a conversão de sinal para o USB, como o

Future Tecnology Devices International (FTDI) (FUTURE TECNOLOGY DEVICES

INTERNATIONAL LTDA., 2011) e o cabo serial/USB desenvolvido pela Tato (TATO

EQUIPAMENTOS ELETRÔNICOS, 2011).

38

Dessa forma, objetivando fornecer uma alternativa flexível, no projeto da placa

desenvolvida foram colocados 3 pinos para interface externa. Eles são ligados aos pinos RX e

TX do microcontrolador e à referência do módulo. Com essa interface, é possível ao usuário

realizar uma comunicação no padrão RS-232 com o computador através do MAX232

(TEXAS INSTRUMENTS, 2008) ou uma comunicação USB através do FTDI ou cabo

serial/USB.

Nos subtópicos a seguir serão apresentadas as arquiteturas específicas da estação

remota e da base.

3.2.1 Arquitetura da Estação Remota

Pela necessidade constante de coletar e armazenar os dados dos sensores, a memória

interna do microcontrolador não seria suficiente para receber esses dados por um grande

período de tempo, o que tornaria o tempo de autonomia das estações relativamente pequeno.

Pensando nisso, foi necessário inserir nesse módulo um dispositivo que fornecesse uma

memória extra, aumentando assim o período de autonomia das estações. O circuito integrado

utilizado com esse fim foi um 24FC512 cuja interface de comunicação para leitura e escrita de

dados é a I2C.

O microcontrolador utilizado dispõe dos periféricos I2C, SPI e USART utilizados no

projeto. No entanto, os pinos para a comunicação I2C são os mesmos para a SPI. Como no

projeto os dois tipos de comunicação são utilizadas foi necessário definir qual dos

componentes se beneficiaria pela utilização do protocolo embutido no microcontrolador.

Sendo assim, a equipe optou por ceder essas portas para o módulo RF, visto que ele realiza

uma quantidade maior de operações. Por esse motivo, o protocolo I2C para interface com a

memória EEPROM foi construído em software e o 24FC512 conectado aos pinos RB2 e RB3

do microcontrolador.

A figura 15 apresenta a arquitetura construída para a estação remota.

39

Figura 15 - Arquitetura da estação remota


3.2.2 Arquitetura da Base

Por ser a concentradora de informações, a base necessita de uma quantidade de

memória maior que a requisitada pelas estações. Dentre as possibilidades pesquisadas, a

solução mais adequada, pela sua versatilidade e grande capacidade de armazenamento, foi o

emprego de cartões de memória SD/MMC. Seu uso foi viabilizado através do módulo HDBS

que permite a gravação nesses tipos de cartões via USART. Na figura 16 é possível visualizar

a arquitetura da base.

Figura 16 - Arquitetura da base


40

3.3 Projeto de Software

Nesse projeto, foi necessária a construção de três softwares diferentes: o firmware da

estação remota, o firmware da base e um programa para gerenciamento através de um

computador pessoal.

A programação da estação remota, assim como a da base, foi feita em linguagem C,

através da plataforma MPLAB IDE v8.63 usando o compilador C18 . Vale ressaltar, que, em

ambos módulos, o projeto foi desenvolvido a partir do “Simple Example - PIC18 - C18”

disponibilizado juntamente com o framework MiWi DE (MICROCHIP TECHNOLOGY

INC., 2010b), o que facilitou o processo de aprendizagem e desenvolvimento do protocolo.

O software do computador pessoal foi construído em JAVA na plataforma NetBeans

6.7.1. Nesse projeto foram utilizadas as bibliotecas javax.comm , para realizar a comunicação

serial com o módulo base, e a jfreechart, para construção do gráfico na interface principal.

3.3.1 Configurações Gerais dos Módulos e Funções do Protocolo MiWi

Como ambos os módulos possuem uma arquitetura semelhante, existem algumas

configurações que são compartilhadas. Dentre elas podemos destacar as funções de

configuração do hardware do microcontrolador e do protocolo MiWi. As figuras 17 e 18

ilustram o fluxograma desse processo de configuração dos módulos da base e da estação,

respectivamente.

41

Início

BoardInit() ConsoleInit() ConfigurarHardwareModulo()

MiApp_ProtocolInit

(FALSE);

MiApp_SetChannel

(myChannel)

MiApp_ConnectionMode

(ENABLE_ALL_CONN)

i=MiApp_EstablishConnection

(0xFF,

CONN_MODE_DIRECT)

MiApp_StartConnection(

START_CONN_DIRECT,

10, 0)

i == 0xFF sim

Fim Configuração

não

Figura 17 - Processo de configuração do hardware e do protocolo MiWi no coordenador.


Início

BoardInit() ConsoleInit() ConfigurarHardwareModulo()

MiApp_ProtocolInit

(FALSE);

MiApp_ConnectionMode

(ENABLE_ALL_CONN)sim

i=MiApp_EstablishConnectio

n(0xFF,

CONN_MODE_DIRECT)

i == 0xFF

sim naoFim Configuração

MiApp_SetChannel

(myChannel)

não

Fim do programa

Figura 18 - Processo de configuração do hardware e do protocolo MiWi na Estação.


42

A primeira função executada após a inicialização dos módulos é a “BoardInit()” que é

a encarregada de configurar as portas de entrada e saída do microcontrolador, comunicação

SPI com o módulo RF e o Watch Dog Timer (WDT). Logo após sua execução a função

“ConsoleInit()” é acionada, e as configurações da comunicação USART são selecionadas:

1. Baud Rate – 9600;

2. Bits de dados – 8;

3. Sem paridade;

4. Bit de parada – 1; e

5. Sem controle de fluxo.

Em seguida é iniciado o processo de configuração do protocolo MiWi. Um fator

decisivo para o cumprimento de forma eficiente desse processo, foi a utilização das rotinas

presentes no MiApp (YANG, 2009a). Esse framework disponibiliza diversas funções que

facilitam o processo de configuração e manipulação do protocolo.

A primeira executada entre elas é a “BOOL MiApp_ProtocolInit(BOOL

bNetworkFreezer)”, responsável por inicializar a pilha do protocolo. Essa função possui um

único parâmetro de entrada que define se configurações prévias serão carregadas (TRUE) ou

se a pilha será iniciada do zero (FALSE) (YANG, 2009a). Nesse projeto, a função foi

chamada com o parâmetro FALSE.

Logo após, é feita uma chamada à função “BOOL MiApp_SetChannel(BYTE

Channel)”, que configura o canal de comunicação a ser utilizado (YANG, 2009a). Como no

projeto não foi utilizado a funcionalidade de detecção automática de canal, seu valor foi

configurado para o canal 25, que é o canal padrão do MiWi DE. Caso durante o processo de

configuração do canal ocorra um erro, uma mensagem é exibida e a execução do programa

interrompida. Caso a seleção do canal tenha sido realizada com sucesso, é feita uma chamada

à função “void MiApp_ConnectionMode(BYTE Mode)” (YANG, 2009a) que configura o

modo de conexão a ser utilizado. Essa função pode receber quatro tipos de parâmetros:

ENABLE_ALL_CONN

o Habilita qualquer tentativa de conexão;

ENABLE_PREV_CONN

o Habilita apenas conexões que já existiram;

ENABLE_ACTIVE_SCAN_RSP

o Configura o módulo para responder a qualquer active scan recebido;

DISABLE_ALL_CONN

43

o Desabilita todas as requisições de conexão.

No projeto, por apresentar uma alternativa mais simples, o parâmetro escolhido foi o

ENABLE_ALL_CONN.

A próxima função executada é a “BYTE EstablishConnection(BYTE

ActiveScanIndex, BYTE Mode)”. Ela recebe como parâmetros de entrada o índice na tabela

resultante do active scan para o nó que se deve estabelecer uma conexão, se seu valor for

“0xFF” ela tentará estabelecer uma conexão com qualquer dispositivo. O parâmetro “mode”

especifica o modo de conexão: “MODE_DIRECT”, usado quando o dispositivo destino está

no alcance do rádio, ou “MODE_INDIRECT”, para estabelecer a conexão indiretamente

através de outros nós. Após ser chamada, essa função retorna um byte indicando o índice da

nova conexão na tabela de conexões, quando seu valor é 0xFF significa que não foi possível

estabelecer uma conexão (YANG, 2009a).

No projeto, como a rede foi construída com apenas um nó, foram utilizados os

parâmetros 0xFF e “MODE_DIRECT” (YANG, 2009a). No entanto, existe uma pequena

diferença entre a chamada dessa função entre o coordenador e a estação remota. No

coordenador, ela é chamada apenas uma vez, e caso o valor de retorno seja 0xFF a função

“StartConnection()” é acionada (Figura 17). Já na estação, enquanto o valor de retorno não

for diferente de 0xFF ela é chamada constantemente (Figura 18). Em ambos os módulos,

quando se tem uma chamada bem sucedida da função “EstablishConnection()”, o processo de

configuração dos módulos é finalizado.

A função “BOOL StartConnection(BYTE Mode, BYTE ScanDuration, DWORD

ChannelMap)”, acionada pela base, recebe três parâmetros de entrada (YANG, 2009a):

Mode

o Identifica o modo de iniciar a PAN;

ScanDuration

o Define o tempo máximo de execução da avaliação do canal;

ChannelMap

o Identifica os canais a serem escaneados no processo.

Na base, o campo “Mode” é definido como “START_CONN_DIRECT”, para que a

conexão seja estabelecida sem a detecção de ruído. O campo “ScanDuration” foi colocado

em 10, o que equivale a um tempo de 1 segundo de acordo com a equação: ScanTime(us) =

960 * (2ScanDuration

+1), encontrada no AN1284 (YANG, 2009a). Como o “Mode” foi

44

configurado como “START_CONN_DIRECT”, o parâmetro “ChannelMap” é

automaticamente descartado (YANG, 2009a).

Com a realização dessas funções, o processo de configuração do hardware e do

protocolo MiWi nos módulos está finalizado. A partir desse ponto, ambos os módulos entram

em um laço para execução de suas rotinas especificas. No entanto, as operações de envio e

recepção de dados via rádio realizadas durante esse laço não mudam entre os módulos. Sendo

assim, não existe motivo para essas operações serem abordadas de forma separada.

A cada iteração do laço principal do programa, é acionada a função

“MiApp_MessageAvailable()”. Essa função retorna verdadeiro sempre que for recebida uma

nova mensagem de um dos nós da rede.

Toda vez que uma nova mensagem é recebida, o MiApp automaticamente organiza o

seu conteúdo em um struct do tipo “RECEIVED_MESSAGE” (Figura 19). Nessa estrutura,

estão contidas informações importantes como os bytes de configuração da mensagem, o

endereço de origem e o payload da mensagem. Por padrão, o MiApp já cria a variável

“rxMessage” do tipo “RECEIVED_MESSAGE”.

Figura 19 - Struct RECEIVED_MESSAGE.


45

Dessa forma, após a detecção de uma nova mensagem, é possível acessar a todas as

informações recebidas através da variável “rxMessage”. Caso se deseje acessar, por exemplo,

o conteúdo do primeiro byte recebido, basta apenas fazer a seguinte chamada:

“rxMessage.PayLoad[0]”.

Após a recepção da mensagem e realização das operações adequadas com os dados

coletados, a mensagem recebida é então descartada ao se chamar a função

“MiApp_DiscardMessage()”.

Por outro lado, o processo de envio de dados pode ser realizado de duas formas:

broadcast - a mensagem é enviada para todos os nós da rede, ou unicast - a mensagem é

enviada apenas para um dispositivo. Como nesse projeto foi definida a utilização de

mensagens do tipo broadcast, apenas esse tipo será abordado aqui.

Para cada byte que se deseja enviar através do protocolo, a função “void

MiApp_WriteData(BYTE OneByteTxData)” é acionada. Sendo assim, caso o usuário

necessite enviar “n” bytes, essa função deve ser chamada “n” vezes, contanto que o valor de

“n” não ultrapasse o tamanho máximo configurado do buffer TX, no projeto esse valor foi

configurado para enviar até 100 bytes por vez.

Com toda a informação que se deseja enviar carregada no buffer TX a função “BOOL

MiApp_BroadcastMessage(BOOL SecEn)” é acionada. Seu parâmetro de entrada indica se o

payload da mensagem deve ou não ser criptografado. Caso a operação tenha sido realizada

com sucesso essa função retornará “verdadeiro”. Como não foi utilizado criptografia dos

dados no projeto, “SecEn” é configurado como FALSE.

3.3.2 Firmware da Estação Remota

Ao ligar o módulo da estação remota, inicialmente são realizadas as rotinas de

configuração do hardware do microcontrolador, inicialização do módulo RF e criação de uma

conexão com a base.

Após essas operações de configuração, a estação remota entra em um laço onde são

executadas suas funcionalidades específicas. Na figura 20, é possível visualizar um

fluxograma das operações realizadas por esse módulo e dos caminhos tomados, a depender do

evento ocorrido.

46

Figura 20 - Fluxograma da estação remota


47

O primeiro procedimento realizado nesse laço é verificar se é hora de coletar um dado

do sensor. Buscando oferecer uma solução flexível e que possa atender a um maior número de

usuários, o projeto prevê a alteração do intervalo de aquisição remotamente. Para tanto foram

criadas duas variáveis, uma para armazenar o horário da última aquisição e outra para

armazenar o intervalo de aquisição dos dados. A partir desses dois valores é possível calcular

o horário da próxima aquisição através da seguinte equação:

Hora da última aquisição + Intervalo = Hora da próxima aquisição

Seguindo esse raciocínio, um módulo que coletou um dado do sensor às 14h 25min e

30s com um intervalo de aquisição de 45 segundos fará a próxima aquisição às 14h 26min e

15s.

Ao atingir o horário da próxima aquisição, o nível de tensão presente no sensor é

captado e seu valor armazenado na memória, juntamente com o seu respectivo rótulo

temporal, em um total de 8 bytes por amostra (Figura 21).

Figura 21 - Estrutura de uma amostra


Objetivando aperfeiçoar o processo de leitura e escrita dos dados na memória

EEPROM, foram construídas rotinas específicas para essas operações. O ponto chave para o

seu funcionamento, é a utilização de um ponteiro que aponta para a última posição da última

amostra armazenada.

No início de toda operação de escrita, o ponteiro estará sempre indicando a posição

final da última amostra (Figura 22 a). Ao iniciar o processo de escrita, esse valor é acrescido

de 1 (Figura 22 b) e o ponteiro passa a indicar o local onde deve ser iniciada a gravação do

próximo dado. A cada valor inserido, a posição do ponteiro é incrementada e, no fim do

processo, ele estará apontando para o último dado inserido (Figura 22 c), fechando o ciclo de

gravação.

48

Figura 22 - Processo de escrita: antes do início do processo (a); início do processo (b); fim do processo (c)


O processo de leitura, assim como o de escrita, parte da premissa que inicialmente o

ponteiro de endereço está apontando para a posição final da última amostra armazenada

(Figura 23 a). Como a leitura é realizada de forma sequencial, o valor do ponteiro deve ser

subtraído de 7 para apontar para o início da amostra a ser lida (Figura 23 b). A partir desse

ponto, a leitura é realizada sequencialmente byte a byte até se atingir o final da amostra.

Nesse momento, o valor do ponteiro é subtraído de 8, fazendo com que o mesmo aponte para

a próxima amostra (Figura 23 c), “apagando” a amostra lida. Uma leitura sequencial pode ser

realizada com a repetição desses passos.

Figura 23 - Processo de leitura: antes do início da leitura (a); início da leitura (b); fim da leitura (c)


49

Como explicado anteriormente, as portas do microcontrolador que possibilitam a

utilização da comunicação I2C via hardware não puderam ser utilizadas para comunicação

com o 24FC512, pois foram cedidas ao módulo RF. Dessa forma, a utilização desse protocolo

só foi possível via software. Felizmente, a microchip disponibiliza uma biblioteca para esse

tipo de situação, a sw_i2c.h, que é instalada juntamente com o compilador C18 no

computador (MICROCHIP TECHNOLOGY INC., 2010a). Sendo assim, as funções de leitura

e escrita de dados nas memórias foram construídas através dessa biblioteca, com base nos

passos contidos no datasheet do 24FC512 (MICROCHIP TECHNOLOGY INC., 2010c).

Após executar a função de aquisição de dados, o próximo passo é verificar se o

módulo recebeu uma mensagem do coordenador. Caso positivo, a mesma é analisada e

processada; caso contrário, o programa é redirecionado para o passo anterior, fechando um

ciclo de operação.

Toda mensagem enviada entre os módulos é composta por um byte de controle que

identifica o tipo de operação a ser realizada. Para o módulo que está recebendo a mensagem,

esse byte é armazenado na posição 0 do vetor PayLoad contido no struct rxMessage. Da

mesma forma, o módulo que deseja enviar a solicitação deve inserir o comando de controle na

posição 0 do buffer TX. Ao identificar a chegada de uma nova mensagem, o valor contido em

rxMessage.PayLoad[0] é analisado e a operação correspondente acionada. Na versão atual do

firmware, as operações de controle suportadas são as contidas na Tabela 4.

Tabela 4 - Lista dos comandos de controle.

Controle Comando Descrição

10 Ajustar hora Possibilita a base atualizar o horário da estação

remotamente.

20 Solicitação de dados Esse comando indica que base está solicitando que

as amostras contidas na memória EEPROM da

estação sejam enviados

30 Verificar estado A base está apenas verificando se a estação está

operando corretamente

40 Atualizar intervalo Atualiza o intervalo de aquisição de dados

remotamente

50 Verificar hora A base está solicitando que a estação envie o horário

contido no RTC naquele momento

60 Reservado -

70 Apagar memória Reiniciar o ponteiro de endereçamento da memória

para a posição inicial

80 Verificar memória Verifica a quantidade da memória utilizada até

aquele momento

90 Verificar intervalo Verifica o intervalo de aquisição utilizado na

estação


50

O código de controle 60 é reservado à estação, sendo utilizado para informar à base

que a memória EEPROM está ficando cheia. Essa é a única situação em que uma troca de

mensagens é iniciada por uma estação remota.

Em muitos casos, apenas a presença do comando de controle na mensagem é

suficiente para se processar uma solicitação. No entanto, existem casos que é necessário a

existência de mais informações além do comando de controle para que a solicitação desejada

possa ser processada, essas informações são armazenadas entre a posição 1 e 99 dos vetores

PayLoad, no módulo receptor, e TX, no emissor. A exemplo tem-se o comando ajustar hora,

que é enviado pela base juntamente com a hora que se deseja configurar na estação. Esse

procedimento ocorre tanto no envio das solicitações a partir da base quanto nas respostas a

essas solicitações por parte da estação.

Nessa versão do firmware, apenas a porta AN2 foi utilizada para coleta de dados dos

sensores, o que limita a quantidade de sensores a serem conectados a apenas um. Vale

ressaltar que a tensão de referência utilizada é a própria tensão de alimentação do módulo, o

que possibilita a aquisição de sinais entre 0 e 3,3 V. Se o sensor adotado apresentar uma faixa

de operação não compatível, o sinal do mesmo deve ser condicionado às especificações do

sistema, sob a pena de causar incompatibilidade nas aquisições.

3.3.3 Firmware da Base

Assim como na estação remota, na base, inicialmente, são realizadas as rotinas de

configuração do microcontrolador e periféricos, seguidas da criação de uma conexão com as

estações. Só após a realização desses passos, as tarefas específicas desse módulo são

efetuadas. Na figura 24 é possível visualizar o fluxo de execução dessas tarefas.

As funcionalidades da base que interagem com a estação podem ser divididas em três

tipos: verificação, configuração e solicitação de dados.

As funcionalidades de verificação servem para monitorar as estações remotas. Com

elas é possível ver, por exemplo, o horário marcado no RTC, a quantidade de memória

disponível e o intervalo de aquisição utilizado.

51

Já as funcionalidades de configuração permitem à base configurar remotamente os

parâmetros das estações, como a hora e intervalo de aquisição, além de permitir apagar o

conteúdo da memória EEPROM.

Por fim, tem-se a funcionalidade de solicitação de dados, que possibilita ao

coordenador acessar os dados coletados e armazenados na memória EEPROM das estações.

Essas tarefas, a depender do seu tipo, podem ser iniciadas de forma automática ou a

partir de comandos enviados pelo computador pessoal. As operações de configuração e

verificação são realizadas apenas quando o usuário, através do computador pessoal, as

solicita. Por outro lado, as solicitações de dados podem ser realizadas tanto de forma

automática quanto através de comandos do usuário.

A solicitação de dados automática é realizada a intervalos periódicos cuja

configuração é semelhante à utilizada na estação, o que permite a adoção de intervalos

flexíveis. Esse intervalo pode ser configurado pelo usuário através da comunicação do

módulo com o computador pessoal.

Dessa forma, seguindo o fluxograma de operações (Figura 24), a base verifica

constantemente se existe algum comando proveniente da estação ou do computador pessoal.

Caso exista uma mensagem da estação, o byte de configuração é analisado e a mensagem

então processada.

Normalmente, as mensagens provenientes da estação são respostas a comandos

enviados pela base. Nessas situações, a base apenas recebe o comando e o repassa para o

computador pessoal - as exceções ocorrem apenas nas mensagens 20 e 60. Na mensagem 20,

a base, além de receber os dados e enviar para o computador pessoal, armazena as amostras

em um cartão de memória. Já na mensagem 60, o único caso em que uma conversa é iniciada

pela estação, o coordenador da rede responde com uma solicitação de dados, evitando assim a

sobrecarga da memória.

52

Início

configurarMicrocontrolador()

configurarTransmissor()

estabelecerConexão()

configurarPeriféricos()

PC enviou

dados?

Hora do

backup?

Receber

Comando

do PC

Comando == 10

Comando == 20

Comando == 30

Comando == 40

Comando == 50

Comando == 70

Comando == 80

enviarVerificarMemoria()

enviarVerificarEstacao()

enviarSolicitacaoDados()

enviarHora()

enviarAtualizarIntervalo()

enviarApagarMemoria()

enviarVerificarHora()

Existe

mensagem da

estação?

Sim

Não

Comando == 10

Comando == 20

Comando == 30

Comando == 40

Comando == 50

Comando == 70

Comando == 80

receberDados()

enviarPC()

receberDados()

armazenarCartão()

enviarPC()

receberDados()

enviarPC()

receberDados()

enviarPC()

receberDados()

enviarPC()

receberDados()

enviarPC()

receberDados()

enviarPC()

Comando == 60enviarSolicitacaoDados()

Sim

Sim

Sim

Sim

Sim

Sim

Sim

Sim

Sim

Sim

Sim

Sim

Sim

Sim

Sim

Sim

Sim

Não

Não

Não

Não

Não

Não

Não

Não

Não

Não

Não

Não

Não

Não

Comando == 90receberDados()

enviarPC()

SimComando == 90 enviarVerificarIntervalo()

Sim

Comando == 110 ajustarintervaloBase()

Sim

Comando == 120 removerCartão()Sim

Comando == 130 verificarBase()Sim

Comando ==

100ajustarHoraBase()

Sim

Cartão ok?

Sim

Não

Figura 24 - Fluxograma da base


Além dos comandos de controle das estações remotas, existem comandos específicos

para manipulação da base a partir do computador pessoal. Esses comandos podem ser

visualizados na Tabela 5.

53

Tabela 5 - Comandos de controle da base

Controle Comando Descrição

100 Ajustar hora base Possibilita a base alterar o horário contido no RTC.

110 Ajustar Intervalo da

Base

Altera o intervalo de solicitação utilizado.

120 Remover Cartão Informa a base que o cartão de memória será

removido.

130 Verificar Base Verifica a hora e o intervalo de solicitação da base.


Dentre os comandos listados, o único que necessita de uma atenção especial por ser

um pouco mais complexo é o de remover o cartão de memória. Como a base está

constantemente solicitando dados das estações e os armazenando em um cartão de memória, a

remoção do cartão do módulo HDBS de forma arbitrária poderia causar uma perda das

informações coletadas. Dessa forma, o comando remover cartão funciona como um indicador

ao programa que o cartão de memória foi removido e que a operação de solicitação deve ser

suspensa, até que o mesmo seja inserido novamente no módulo.

3.3.4 Programa do Computador Pessoal

Visando facilitar o processo de manuseio e configuração da rede, foi construído um

software supervisório a ser instalado no computador conectado ao coordenador da rede.

Através de uma interface amigável ele possibilita que o usuário realize diversas operações de

controle dos módulos remotos. Ele é composto basicamente de 11 classes (Figura 25), que

trabalham em conjunto para a realização de todas as atividades pretendidas.

54

Figura 25 - Diagrama com as principais classes do software de gerenciamento.


Quando o programa é iniciado, a primeira classe executada é o

“FrameGerenciaModulo” (Figura 26), uma classe do tipo Frame. Nela estão contidas três

abas, “Principal”, “Estação” e “Base”, onde foram distribuídos botões de acesso às

funcionalidades do sistema, além de dois painéis, um para exibição gráfica das amostras

55

coletadas das estações e outro para visualização das mensagens provenientes da comunicação

serial com a base.

Na aba principal estão localizados os botões de acesso a funcionalidades gerais do

software:

1. Configurar Serial;

2. Testes;

3. Limpar Tela;

4. Gerar Gráfico;

5. Exibir Rede; e

6. Sair.

Figura 26 - Tela principal do software supervisório


56

A operação de configuração da comunicação serial com a base é feita através do botão

“Configurar Serial” que ao ser pressionado exibe o “FrameConfigurarSerial” (Figura 27).

Após a escolha da porta e das configurações da comunicação serial, a conexão pode ser

estabelecida ao se clicar no botão “Conectar” desse mesmo Frame. Nesse momento, uma

rotina da classe “ConfigurarSerial” é executada e a conexão é então criada. Como a base pode

a qualquer momento estar enviando uma mensagem, um evento do tipo “SerialPortEvent” é

criado, permitindo que o processo de detecção de novas mensagens possa ocorrer de forma

paralela à execução do programa. Ao detectar uma mensagem, a mesma é exibida no painel

de entrada da tela principal.

Como dito anteriormente, todas as amostras coletadas das estações são armazenadas

em um cartão de memória através do módulo HDBS, que se comunica com a base através de

uma comunicação USART. Devido a linha TX do microcontrolador ser compartilhada entre o

HDBS e o computador, sempre que o PIC envia uma mensagem por esse canal ele estará

enviando para os dois. Como o cabeçalho dessa mensagem é padronizado, foi possível

construir uma rotina no software do computador que detecta a sua presença nos dados

recebidos e a separa. Sempre que essa situação ocorre, as informações da amostra (rótulo

temporal e tensão amostrada) são armazenadas em um arquivo e exibidas no gráfico da tela

principal (Figura 26).

Figura 27 - Tela de configuração da comunicação serial


O botão “Testes” da tela principal executa a rotina de testes de comunicação entre a

base e a estação (essa rotina será melhor explicada na seção 4 dessa monografia). O comando

“Limpar Tela”, reinicia o gráfico dos dados recebidos e o Frame de entrada da comunicação

57

serial. O botão “Gerar Gráfico” realiza uma leitura do arquivo contendo as amostras

recebidas e gera um gráfico a partir desses dados.

Já o botão “Exibir Rede”, inicializa o “FrameMontagem”, interface de visualização da

rede (Figura 28), possibilitando uma manipulação mais dinâmica dos módulos. Nessa tela é

possível realizar o mapeamento dos nós presentes na rede através do botão “Mapear”, além de

permitir a inclusão e movimentação de forma manual de módulos na tela.

Ao inserir um módulo, é possível lhe enviar um comando ao clicar com o botão direito

do mouse sobre o seu símbolo e escolher a opção desejada (Figura 28). A depender do tipo,

base ou estação, os comandos que irão aparecer serão diferentes, tais comandos apresentam as

mesmas funcionalidades dos botões presentes nas abas “Estação” e “Base”, que serão

explicados com detalhes a seguir.

Figura 28 - Painel de Visualização da Rede


Na aba “Base” (Figura 29) se encontram os botões de acesso às rotinas de

manipulação do módulo base, o coordenador da rede. Quando um botão é pressionado, são

acessadas as funções da classe “ControleCoordenador”, onde os passos necessários para a

realização de cada tarefa são implementados. Dentre elas, há o comando “Atualizar Hora”

que ajusta a hora do módulo de acordo com a hora do computador.

58

Figura 29 - Abas “Estação” e “Base” da tela principal


Ao pressionar o botão “Atualizar Intervalo”, uma tela para configuração do intervalo

de aquisição é exibida (Figura 30), o “FrameTempo”. Tem-se também o botão “Verificar”

que solicita que a base informe a sua hora atual e o intervalo de aquisição utilizado no

momento. Por fim, há o botão “Remover Cartão”, que envia à base o comando de remoção do

cartão de memória.

Figura 30 - Tela de configuração do intervalo de aquisição


Já na aba “Estação” (Figura 29), se encontram os botões para acesso às rotinas

presentes na classe “ControleEstacao”. Nessa aba, o botão “Verificar” faz a solicitação de três

59

informações da estação: quantidade de memória utilizada no momento, horário da estação e

seu intervalo de aquisição.

O botão “Apagar Memória” envia o comando 70 para a base, que o identifica e

encaminha a solicitação para a estação. O botão “Solicitar Dados” envia o comando

correspondente a seu nome; ao receber as amostras, elas são exibidas no gráfico da tela

principal e armazenadas em um arquivo.

Já os botões “Atualizar Intervalo” e “Atualizar Hora” apresentam funcionalidades

semelhantes aos seus similares contidos na aba “Base”. A diferença é que, nesse caso, o

destino final das solicitações são as estações remotas.

60

4 RESULTADOS

Com o fim da etapa de desenvolvimento, foi necessário construir algumas rotinas de

testes que pudessem comprovar a eficiência dos protótipos construídos. Nessa seção serão

apresentadas as etapas necessárias para a realização desses testes, bem como os resultados

obtidos.

4.1 Projeto e Confecção da Placa de Circuito Impresso

Após a definição das arquiteturas utilizadas na base e na estação, um protótipo de cada

módulo foi construído em uma matriz de contatos para desenvolvimento dos firmwares dos

módulos (Figura 31).

No entanto, a utilização dos protótipos em matriz de contatos não apresentava as

características adequadas para a realização dos testes do sistema. Por terem sido construídos

em uma mesma placa, a realização de testes com diferentes distâncias se tornou inviável.

Assim, seria necessário a reconstrução de um dos módulos em outra placa. Além disso, não se

tem certeza da qualidade do material condutor utilizado na matriz de contatos e de quanto esse

fator poderia influenciar no resultado dos testes.

Dessa forma, constatou-se que esse era o momento adequado para a construção do

projeto em uma placa de circuito impresso.

61

Figura 31 - Protótipo da estação e da base em matriz de contatos


Primeiro, foi realizado um levantamento detalhado de todos os componentes a serem

utilizados nos módulos, tendo como resultado a Tabela 6.

Tabela 6 - Lista dos componentes dos módulos

Base Estação

Qt. Nome Qt. Nome

1 1K Ω <Resistência<10K Ω 1 1k Ω < Resistência <10k Ω

3 1K Ω >Resistência >220 Ω 3 1k Ω >Resistência >220 Ω

1 Barra Pinos 1x2 1 24FC512

1 Barra Pinos 1x5 1 Barra Pinos 1x2



1 Botão Liga/Desliga 1 Barra Pinos 2x7

1 Botão Reset 1 Botão Liga/Desliga

5 Capacitor Cerâmico 1 Botão Reset

1 Capacitor Eletrolítico 10 uF 6 Capacitor Cerâmico

62

Tabela 6 - Lista dos componentes dos módulos (Continuação)

2 Capacitor Eletrolítico 100 uF 1 Capacitor Eletrolítico 10 uF

1 Conector Bateria 1 Capacitor Eletrolítico 10 uF

1 Conector Jack 1 Conector Bateria

1 Cristal 4 MHz 1 Conector Jack

1 Cristal 32768 KHz 1 Cristal 4 MHz

1 DS1302 1 Cristal 32768 KHz

1 HDBS 1 DS1302

3 Led 3 Led

1 LM1117 1 LM1117

1 LM7805 1 MRF24J40MA

1 MRF24J40MA 1 PIC18F4620

1 PIC18F4620 2 Resistência 10 K Ω


Com a lista dos componentes em mãos, partiu-se para a construção dos esquemas de

ligação e projetos das placas dos módulos da base e da estação remota. Ambas as etapas

foram concebidas através da ferramenta Eagle. Por fim, os projetos criados foram impressos

no laboratório de hardware e as placas geradas foram soldadas aos seus respectivos

componentes.

Nas figuras 32, 33 e 34 pode-se visualizar respectivamente o esquema de ligação,

projeto da placa e protótipo resultante do módulo da base. Os principais componentes desse

módulo foram numerados para um melhor entendimento por parte do leitor:

1. Conectores de alimentação do módulo;

2. Botão liga/desliga;

3. LM7805;

4. Pinos para conexão serial;

5. Módulo para escrita nos cartões de memória;

6. LM1117;

7. DS1302;

8. Pinos para testes nas portas RB7 e RB6;

9. Pinos para gravação ICSP do microcontrolador;

10. Microcontrolador PIC18F4620;

11. Módulo de rádio frequência; e

12. Botão de reset.

63

Figura 32 - Esquema de ligação da base


Figura 33 - Projeto da placa da base


64

Figura 34 - Prótotipo da base


Nas figuras 35, 36 e 37 são exibidos o esquema de ligação, projeto da placa e

protótipo final da estação remota, respectivamente. Os componentes destacados nas imagens

são:

1. PIC18F4620;

2. MRF24J40MA;

3. Pinos para conexão dos sensores nas portas RA2-RA5 e RE0-RE2, com

respectivas linhas de ground;

4. Botão de Reset;

5. Pinos para gravação ICSP;

6. Conectores de alimentação;

7. Botão Liga/Desliga do módulo;

8. Regulador de tensão LM1117;

9. Real Time Clock DS1302;

10. Memória EEPROM 24FC512;

11. Pinos para testes nas portas RB7 e RB6; e

12. Pinos para comunicação serial com o computador.

65

Figura 35 - Esquema de ligação da estação remota


Figura 36 - Projeto da placa da estação


66

Figura 37 - Protótipo da estação remota


A figura 38 possibilita visualizar como foi feita a interface do módulo base com o

computador pessoal através do MAX232.

Figura 38 - Interface da base com uma porta RS-232


67

4.2 Teste de Consistência dos Dados no Dia 24 de Março

Objetivando testar a precisão e consistência dos dados adquiridos pelo equipamento,

foi montado um aparato experimental para medir a mesma variável, usando simultaneamente

a estação desenvolvida e um sistema de aquisição de dados pré-existente, tornando então

possível realizar uma comparação entre os dados obtidos pelas duas medidas.

O sistema foi então conectado no dia 24 de março de 2010 a um radiômetro calibrado

(ZONEM, K., 2009) para a aquisição de dados de insolação. Esse mesmo radiômetro fornece

medidas a uma estação comercial de aquisição de dados já existente no local (Data

Logger)(SECOND WIND INC., 2008). Na figura 39 é possível visualizar o cenário de testes.

Após o período de aquisição, os dados dos dois sistemas foram comparados.

Figura 39 - Cenário do teste de consistência


O sistema proposto apresenta uma taxa de amostragem variável, permitindo ao usuário

selecionar qual a mais adequada a sua aplicação. Para o experimento foi utilizada uma

amostragem por minuto, mesmo período utilizado pelo Data Logger.

A partir dos dados coletados pela estação de aquisição remota e pelo Data Logger no

dia 24 de março o gráfico da figura 40 foi construído. Com base no mesmo, é observável um

aumento do nível de intensidade solar entre 7:00 e 13:39, com uma queda abrupta de

68

intensidade a partir de 13:40, devido provavelmente ao aumento da nebulosidade no local, se

mantendo a níveis baixos até o final do dia.

Com esse imagem é possível identificar visualmente a coerência entre os resultados

obtidos pelos dois sistemas. A figura 41 demonstra o histograma do erro absoluto entre as

duas formas de medidas. Nesse teste foi obtido um erro médio de 0,066354 e uma variância

de 0,006848.

Figura 40 - Superposição amostras em 24 de março


Figura 41 - Histograma do erro absoluto em 24 de março


69

4.3 Teste de Consistência dos Dados no Dia 25 de Março

Utilizando a mesma metodologia do teste da seção anterior, o sistema foi novamente

conectado para aquisição de dados no dia 25 de março de 2010. A superposição entre os

gráficos gerados dos dados coletados pela estação e pelo Data Logger são dispostos na figura

42. Analisando os gráficos, é observável um aumento de insolação entre aproximadamente

7:00 e 10:00 seguido de um período de baixa intensidade luminosa entre 10:00 e 13:30 onde,

a partir do qual, a intensidade sofre um aumento constante até às 14:00. Após esse horário

ocorre uma queda do nível de intensidade que se mantem até o final do dia.

Novamente, é possível constatar a coerência entre os dados obtidos pelos dois

sistemas. O erro real absoluto entre as duas medidas é constatado na figura 43. Nesse teste foi

obtido um erro médio de 0,050747 a uma variância de 0,005403.

.

Figura 42 - Superposição amostras em 25 de março


70

Figura 43 - Histograma do erro absoluto em 25 de março


4.4 Teste de Eficácia na Transmissão sem Algoritmo de Aquisição

Comprovada a eficiência do sistema em adquirir e armazenar os dados de forma

consistente, era necessário verificar também a eficácia na transmissão de dados via rádio.

Esse teste é iniciado quando o usuário seleciona o botão “Teste” da tela principal.

Nesse momento, o software do computador envia o comando de verificar estado da estação

para o coordenador da rede. Ao identificá-lo, o coordenador retorna com um ACK e logo em

seguida envia a solicitação para a estação remota. Já na estação remota, após a recepção da

mensagem, um ACK é enviado para a base. Após recebê-lo, a base envia novamente uma

mensagem para o computador informando o sucesso da comunicação. Na figura 44 é possível

observar o fluxo das operações com o passar do tempo.

71

Figura 44 - Fluxo de dados durante o teste


O teste consiste em variar o intervalo entre as solicitações repetindo o processo mil

vezes para cada período. Ao final de cada laço, os valores obtidos são armazenados em um

arquivo de testes para uma posterior visualização. Sua aplicação possibilita analisar dois

parâmetros:

1. Total de solicitações enviadas pelo computador que foram identificadas pela

base;

2. Total de solicitações identificadas pela base que foram enviadas à estação e

conseguiram percorrer todo o fluxo Computador->Base->Estação->Base->

Computador.

Com esses dados em mão foi possível calcular o intervalo mínimo de solicitação a ser

utilizado que atingisse taxas de 100% de sucesso.

As estações remotas assim como o coordenador da rede são configurados para realizar

operações a intervalos constantes. Apesar das operações entre os módulos serem diferentes, o

algoritmo que identifica quando as atividades devem ser feitas é o mesmo para ambos os

módulos. Visando verificar quanto a utilização desse algoritmo poderia influenciar no

desempenho da rede, foram realizados testes com e sem a sua utilização.

O primeiro teste utilizando essa abordagem foi feito sem o método de cálculo da hora

da aquisição, tanto na base quanto nas estações. Partindo-se de 180 milissegundos, a cada

1000 iterações subtraíram-se 5 milissegundos do período, tendo como resultado o gráfico

presente na figura 45.

72

Figura 45 - Gráfico da porcentagem de retorno de pacotes sem verificar período de aquisição


Como é possível observar na figura 45, a partir de 85 milissegundos tem-se

aproximadamente 100% de sucesso em todas as solicitações. No entanto, ocorre uma queda

significativa da taxa de sucesso para 66,6% em 80 milissegundos. Já no intervalo entre 45 e

70 milissegundos a taxa se mantem constante e é seguida novamente por uma queda a partir

dos 40 milissegundos.

4.5 Teste de Eficácia na Transmissão com Algoritmo de Aquisição na Estação

No próximo teste utilizando a técnica da seção 4.4, o algoritmo de cálculo do horário

de aquisição foi inserido. Nesse momento, utilizou-se um período de 640 milissegundos com

uma subtração de 10 milissegundos por iteração. Com esse novo teste, o gráfico presente na

figura 46 foi gerado.

A partir da figura 46, é possível observar que após 480 milissegundos ocorre uma taxa

de aproximadamente 100% de sucesso em todas as transmissões, ao mesmo tempo em que

apresenta um declínio constante da sua taxa para períodos inferiores até se chegar a 0% em

130 milissegundos.

73

Figura 46 - Gráfico da porcentagem de retorno de pacotes verificando período de aquisição apenas na

estação


4.6 Teste de Eficácia na Transmissão com Algoritmo de Aquisição Total

No terceiro teste utilizando a técnica na seção 4.4, foi inserido em ambos módulos o

método de cálculo da hora de aquisição. Onde se utilizou uma variação do intervalo de 0 a

650 milissegundos. O gráfico gerado pode ser visualizado na figura 47.

A partir do gráfico é possível identificar que são obtidas taxas de 100% de sucesso

apenas após o período de 480 milissegundos, e que abaixo desse valor a taxa de sucesso cai

continuamente até chegar em zero aos 90 milissegundos.

Uma peculiaridade desse último teste foi a variação da quantidade de mensagens

enviadas pela base que foram identificadas e retornadas pela estação (Figura 44). Nos testes

anteriores, essa taxa se manteve sempre constante em 100%, mas agora devido a interferência

do algoritmo de cálculo da hora de aquisição, seu valor sofreu alterações. O resultado das

medidas coletadas pode ser visto na figura 48.

Coincidentemente, assim como a quantidade de pacotes retornados das estações, taxas

de 100% de sucesso na recepção dos pacotes do computador pessoal são obtidas apenas após

500 milissegundos.

74

Figura 47 - Gráfico da porcentagem de retorno de pacotes verificando o período de aquisição em ambos os

módulos


Figura 48 - Gráfico gerado com a porcentagem de pacotes enviados para a base que foram identificados


75

Com base nos resultados obtidos nos testes, foi possível verificar a interferência da

inserção do algoritmo de cálculo da hora de aquisição no tempo de resposta dos módulos, com

uma queda de desempenho proporcional à inserção do algoritmo.

No teste com o algoritmo apenas na estação, taxas de 100% de sucesso foram obtidas

a partir de 480 milissegundos, um atraso de 395 milissegundos com relação ao teste sem

aquisição.

Já na base, o principal impacto é na identificação de 100% das mensagens do

computador, que passa de 35 milissegundos quando não se utiliza o algoritmo para 500

milissegundos com sua utilização.

Dessa forma, ao utilizar o sistema com a versão atual do algoritmo de cálculo do

período de aquisição, é necessário que o intervalo entre as solicitações sejam sempre

superiores a 500 milissegundos, garantindo assim 100% de sucesso nas transações.

4.7 Teste do Alcance de Transmissão

Após a obtenção do período mínimo de solicitação, era necessário identificar o alcance

de transmissão entre os módulos. Para tanto, foi utilizada a mesma técnica de troca de

mensagens do teste realizado na seção 4.4. No entanto, em vez de variar o intervalo entre as

solicitações, variou-se a distância entre os módulos. Esse teste foi realizado em frente ao

laboratório de Física da UEFS e, enquanto a base ficava fixa conectada a um computador

pessoal, o módulo da estação remota era deslocado 10 metros a cada iteração. O resultado

desse teste pode ser visualizado na figura 49.

76

Figura 49 - Gráfico com a porcentagem do sucesso de retorno com variação da distância entre os módulos


Analisando o gráfico da figura 49 é possível identificar que a uma distância de até 60

metros as taxas de sucesso são de aproximadamente 100% e que distâncias maiores que essa

apresentam taxas inferiores. Sendo assim, durante o período de instalação da rede deve-se

tomar cuidado para não ultrapassar a distância de 60 metros entre os módulos, garantindo um

bom funcionamento do sistema.

77

5 DISCUSSÕES

A ideia inicial do sistema foi a utilização do protocolo USB como interface de

comunicação entre a base e o computador pessoal. Para tanto, foi realizada uma série de

estudos a respeito desse protocolo, identificando como usá-lo na aplicação e qual tipo de

classe USB mais se adequaria ao projeto. Ao final desse estudo, foi possível construir um

protótipo funcional que implementava a comunicação USB de forma satisfatória. Da mesma

forma, na época, foi desenvolvida uma versão do software de monitoramento com suporte à

comunicação USB para controlar a base.

No entanto, essa etapa foi realizada antes do desenvolvimento do firmware contendo o

protocolo MiWi. Como o protocolo precisava de um microcontrolador com uma memória de

programa maior, foi necessária a substituição de microcontrolador e, consequentemente, a

remoção do suporte à comunicação USB, o que de certa forma prejudicou a versatilidade do

projeto. Por outro lado, visando amenizar esse impacto, em ambos os módulos foram

incluídos pinos para uma comunicação serial externa o que possibilita, além da utilização do

protocolo USART, o emprego da comunicação USB via módulos que permitam a conversão

do sinal USART para USB.

É possível observar nas medidas alguma discrepância, mesmo que pequena, entre os

dados obtidos pelo Data Logger e o sistema proposto. Este erro pode ser diminuído com um

melhor condicionamento do sinal de entrada.

O projeto foi concebido buscando fornecer um sistema com intervalo de aquisição

configurável pelo usuário, possibilitando um nível de independência e flexibilidade maior que

os módulos disponíveis no mercado, que normalmente possuem um intervalo de aquisição

fixo. No entanto, por apresentar um algoritmo mais complexo, essa técnica necessita de um

maior custo computacional. Para aplicações mais específicas que necessitem de um intervalo

entre solicitações menor, a utilização do sistema nos moldes atuais não é recomendada. Caso

esse tipo de aplicação seja realmente necessário, o algoritmo de cálculo do intervalo de

aquisição deve ser reformulado.

Como demostrado nos testes de eficácia na transmissão, o emprego do algoritmo do

cálculo do intervalo de aquisição aumenta o tempo mínimo de resposta dos módulos. Com sua

utilização plena, é necessário limitar o intervalo mínimo entre as solicitações em 500

78

milissegundos. Para o tipo de aplicação que o sistema foi desenvolvido, esse valor é

satisfatório, uma vez que a velocidade de comunicação não é uma prioridade.

Segundo as especificações do MRF24J40MA, o alcance máximo do rádio pode chegar

a até 400 metros. No entanto, como foi observado na seção 4.7 no teste gerado, o alcance de

transmissão com taxas de 100% de sucesso só foram alcançadas até 60 metros.

Provavelmente, é possível atingir distâncias maiores ao se utilizar alguns métodos disponíveis

no MiWi DE para melhoria na transmissão, como a detecção do canal automática e seleção do

canal com menos ruído.

A utilização do módulo HDBS para escrita dos dados no cartão de memória foi muito

útil para o projeto, uma vez que simplificou o processo de interface com os cartões de

memória, além de permitir a utilização de partições do tipo FAT32, o que possibilita a leitura

dos dados gravados no cartão diretamente pelo computador. No entanto, a ideia inicial da sua

utilização era realizar operações de leitura e escrita dos dados no cartão, permitindo ao

usuário visualizar as amostras inseridas através da comunicação do computador com o

módulo, o que não foi integralmente possível, uma vez que a operação de leitura dos dados

pelo microcontrolador não pôde ser implementada. Seu emprego só não foi descartado por ser

possível realizar a leitura dos dados diretamente pelo computador.

79

6 CONSIDERAÇÕES FINAIS

Até o momento, todos os testes realizados no sistema indicam êxito. Os resultados das

aquisições mostram concordância com os parâmetros esperados, apresentando uma precisão

satisfatória. Os testes do desempenho no envio de pacotes apresentaram um período mínimo

satisfatório. No entanto, é possível alcançar um melhor desempenho com uma análise mais

detalhada do algoritmo de cálculo da hora de aquisição e consequente desenvolvimento de

uma solução mais específica, uma vez que na versão atual foi priorizada a adoção de um

intervalo configurável.

Os testes do protocolo realizados, só foram feitos com a utilização de dois nós da rede,

um coordenador e uma estação. Assim, é interessante que futuramente sejam realizados testes

com mais de dois nós.

O protocolo de comunicação serial utilizado entre a base e computador apresentou-se

bastante favorável, mantendo uma boa confiabilidade nas comunicações e ao mesmo tempo

uma taxa de transferência satisfatória.

O software desenvolvido em JAVA atendeu completamente as necessidades do

projeto atual, tanto no monitoramento das estações, através de uma interface amigável, quanto

na manipulação das amostras recebidas, criando gráficos e gerando arquivos de texto que

podem ser utilizados com o objetivo de facilitar a interpretação e manuseio das mesmas por

parte do usuário.

Embora funcional, a utilização de cartões de memória da forma como está sendo feita

no momento não é a mais adequada. É necessário buscar uma alternativa que possibilite a

leitura dos dados do cartão via microcontrolador, que permita ao usuário acessar os seus

dados sem a necessidade constante de remoção do cartão do módulo.

A opção por um microcontrolador de uso geral mostrou-se acertada, pois beneficiou o

projeto com a vasta gama de referências de código e de ferramentas de desenvolvimento

estáveis. Além disso, por usar componentes eletrônicos típicos, o custo de fabricação das

unidades é relativamente baixo, possibilitando a replicação do sistema em uma malha de

estações de aquisição.

Apesar de ter sido desenvolvido para a aquisição de dados solarimétricos, o sistema

apresenta-se bem genérico sendo possível que o mesmo possa realizar a coleta de dados de

80

diferentes tipos como temperatura, pressão, umidade, etc., ou até vários tipos ao mesmo

tempo, sendo necessário apenas a conexão do sensor desejado e o condicionamento do sinal.

O protocolo sem fio utilizado prioriza o baixo consumo de energia, através da

permanência dos módulos remotos a maior parte do tempo em modo sleep. No entanto, nessa

versão do projeto, essa prática não foi utilizada, sendo priorizadas nesse momento as

operações de controle e configuração das estações remotamente. Sendo assim, é interessante

que futuramente o firmware dos módulos seja direcionado para a utilização dessa prática e

que assim possa aumentar a autonomia energética das estações. Além disso, existem outras

funcionalidades interessantes como a detecção de ruído, mensagem indireta e seleção

automática de canal, as quais podem ser empregadas para uma melhoria no desempenho da

rede.

O projeto mostrou-se bastante aceito, tendo artigos aprovados em três congressos: VIII

Escola do Centro Brasileiro de Pesquisas Físicas (CBPF), III Congresso Brasileiro de Energia

Solar (CBENS) e na 10º Escola Regional de Computação Bahia-Alagoas-Sergipe.

81

REFERÊNCIAS

CCS. CCS C Compiler, 2010. Disponível em: <http://www.ccsinfo.com/content.php?page=c

ompilers>. Acesso em: 11 set. 2011.

FERRAZ, V. A. Desenvolvimento de uma estação remota para aquisição de dados

solarimétricos com comunicação sem fio. Universidade Estadual de Feira de Santana. Feira

de Santana. 2008. Disponível em: http://www2.ecomp.uefs.br/trabalhos-de-conclusao-de-

curso. Acesso: em 11 set. 2011.

FUTURE TECNOLOGY DEVICES INTERNATIONAL LTDA. FTDI chip, 2011.

Disponível em: <http://www.ftdichip.com/>. Acesso em: 11 set. 2011.

IBRAHIM, D. Advanced PIC Microcontroller Projects in C. 1º. ed. Burlington: Elsevier

Ltd, 2008.

IEEE COMPUTER SOCIETY. IEEE 802.15.4. Wireless Medium Access Control (MAC)

and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area

Networks (WPANs), 2003. Disponível em: <http://140.116.72.245/~zak/ZigBee/Do

cs/IEEE802.15.4.pdf>. Acesso em: 11 set.2011.

LAIPAC TECHNOLOGY INC. TRF2.4G. Datasheet TRF2.4G, 2008. Disponível em:

<http://www.sparkfun.com/datasheets/RF/RF-24G.pdf>. Acesso em: 11 set. 2011.

MICROCHIP TECHNOLOGY INC. PIC18F4620. Datasheet do PIC18F4620, 2008a.

Disponível em: <http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=e

n010304>. Acesso em: 11 set. 2011.

MICROCHIP TECHNOLOGY INC. MRF24J40MA. MRF24J40MA Data Sheet, 2008b.

Disponível em: <http://www.microchip.com/wwwproducts/Devices.aspx?dDocName

=en535967>. Acesso em: 11 set. 2011.

MICROCHIP TECHNOLOGY INC. C18. Microchip MPLAB C18 C Compiler for PIC18

MCUs, 2010a. Disponível em: <http://www.microchip.com/stellent/idcplg?IdcService=S

S_GET_PAGE&nodeId=1406&dDocName=en010014>. Acesso em: 11 set. 2011.

82

MICROCHIP TECHNOLOGY INC. MiWi DE. MiWi™ Development Environment,

2010b. Disponível em: <http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PA

GE&nodeId=2664&param=en520414&redirects=miwi>. Acesso em: 11 set. 2011.

MICROCHIP TECHNOLOGY INC. 24FC512. Microchip 24FC512 512K I2C Serial

EEPROM, 2010c. Disponível em: <http://www.microchip.com/wwwproducts/Device

s.aspx?dDocName=en010802>. Acesso em: 11 set. 2011.

MICROCHIP TECHNOLOGY INC. MPLAB. MPLAB Integrated Development

Environment V.8.66, 2010d. Disponível em: <http://www.microchip.com/stellent/idcpl

g?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en019469&part=SW007002>.

Acesso em: 11 set. 2011.

MIYADAIRA, A. N. Microcontroladores PIC 18 Aprenda e Programe em Linguagem C.

1º Edição. ed. São Paulo: Érica Ltda., 2009.

SANCHEZ, J.; CANTON, M. P. Microcontroller Programming The Microchip PIC. 1º.

ed. Boca Raton: CRC Press, 2007.

SECOND WIND INC. NOMAD 2. Data Logger for Wind Resource Assessment, 2008.

Disponível em: <http://www.secondwind.com/Nomad/Nomad-2-Wind-Data-Logger.html>.


TATO EQUIPAMENTOS ELETRÔNICOS. HDBS. HDBS Manual de Funcionamento,

2008. Disponível em: <http://www.tato.ind.br/files/Manual%20HDBS.pdf>. Acesso em: 11

set. 2011.

TATO EQUIPAMENTOS ELETRÔNICOS. Descrição Cabo TTL/USB, 2011. Disponível

em: <http://www.tato.ind.br/detalhe_produto.php?codigo_chave=102 >. Acesso em: 11 set.

2011.

TEXAS INSTRUMENTS. MAX232. DataSheet MAX232, 2008. Disponível em:

<http://focus.ti.com/lit/ds/symlink/max232.pdf>. Acesso em: 11 set. 2011.

YANG, Y. MiAPP. Microchip Wireless (MiWi) Application Programming Interface

Miapp, 2009a. ISSN AN1284. Disponível em: <http://ww1.microchip.com/downloads/en/A

ppNotes/01284A.pdf>. Acesso em: 11 set. 2011.

83

YANG, Y. MiMAC. Microchip Wireless (MiWi™) Media Access Controller – MiMAC,

2009b. Disponível em: <http://ww1.microchip.com/downloads/en/AppNotes/01283a.pdf>.


YANG, Y. MiWi P2P. Microchip MiWi™ P2P Wireless Protocol, 2010. ISSN AN1204.

Disponível em: <http://ww1.microchip.com/downloads/en/AppNotes/01204B.pdf>. Acesso

em: 11 set. 2011.

ZONEM, K. CPM21 Data Sheet, 2009. Disponível em: <http://www.kippzonen.com/ >.


UNIVERSIDADE ESTADUAL DE FEIRA DE SANTANA – UEFS DE REDE SEM FIO DE SENSO… · Santana, como...

Documents

Transcript of UNIVERSIDADE ESTADUAL DE FEIRA DE SANTANA – UEFS DE REDE SEM FIO DE SENSO… · Santana, como...