Upload
others
View
3
Download
0
Embed Size (px)
Citation preview
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.
Fonte: Próprio Autor
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.
Fonte: Próprio Autor
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
COMPUTER SOCIETY, 2003).
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
COMPUTER SOCIETY, 2003).
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
Fonte: Próprio Autor
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
Fonte: Próprio Autor
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
Fonte: Próprio Autor
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.
Fonte: Próprio Autor
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.
Fonte: Próprio Autor
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.
Fonte: Próprio Autor
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
Fonte: Próprio Autor
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
Fonte: Próprio Autor
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)
Fonte: Próprio Autor
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)
Fonte: Próprio Autor
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
Fonte: Próprio Autor
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
Fonte: Próprio Autor
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.
Fonte: Próprio Autor
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.
Fonte: Próprio Autor
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
Fonte: Próprio Autor
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
Fonte: Próprio Autor
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
Fonte: Próprio Autor
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
Fonte: Próprio Autor
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
Fonte: Próprio Autor
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
Fonte: Próprio Autor
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 Barra Pinos 2x1 1 Barra Pinos 1x5
1 Barra Pinos 2x5 1 Barra Pinos 2x5
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 Ω
Fonte: Próprio Autor
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
Fonte: Próprio Autor
Figura 33 - Projeto da placa da base
Fonte: Próprio Autor
64
Figura 34 - Prótotipo da base
Fonte: Próprio Autor
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
Fonte: Próprio Autor
Figura 36 - Projeto da placa da estação
Fonte: Próprio Autor
66
Figura 37 - Protótipo da estação remota
Fonte: Próprio Autor
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
Fonte: Próprio Autor
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
Fonte: Próprio Autor
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
Fonte: Próprio Autor
Figura 41 - Histograma do erro absoluto em 24 de março
Fonte: Próprio Autor
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
Fonte: Próprio Autor
70
Figura 43 - Histograma do erro absoluto em 25 de março
Fonte: Próprio Autor
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
Fonte: Próprio Autor
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
Fonte: Próprio Autor
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
Fonte: Próprio Autor
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
Fonte: Próprio Autor
Figura 48 - Gráfico gerado com a porcentagem de pacotes enviados para a base que foram identificados
Fonte: Próprio Autor
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
Fonte: Próprio Autor
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¶m=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>.
Acesso em: 11 set. 2011.
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>.
Acesso em: 11 set. 2011.
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/ >.
Acesso em: 11 set. 2011.