Gateway de aquisição de dados

Esta seção descreve o nó gateway para aquisição de dados das estações móveis. O nó móvel possui um recetor GPS e um sensor de monóxido de carbono. O sensor de CO é um Figaro TGS 5042.

3.5.1. Diagrama funcional

A figura 3.19 ilustra o diagrama funcional do nó gateway de aquisição de

dados. A mensagem recolhida de um cartão SD no formato

$DDMMYY,HHMMSS,LAT,LONG,VomV,BAT. A mensagem recolhida inicia-se

com os dados temporais. Os quais se encontram no formato

DDMMYYHHMMSS. Seguem-se os campos referentes às coordenadas geográficas recebidas pelo recetor GPS, as quais são latitude e longitude. Os restantes dados tratam-se do sinal de tensão do sensor de CO e o nível da bateria que alimenta o nó móvel.

Os dados da mensagem são guardados num buffer temporariamente. Esta pode ou não conter dados de GPS. O que depende do recetor GPS do nó móvel. Tal afeta a dimensão da mensagem. O microcontrolador realiza o tratamento de dados necessário atendendo a estes fatores. Os dados de saída são inseridos na trama de receção do protocolo Zigbee. Os quais são transmitidos por comunicação série. O payload da trama é transmitido no seguinte formato:

*ts=DDMMYYHHMMSS&LAT=DADOS&LONG=DADOS&CO=DADOS

Figura 3.19 Diagrama funcional módulo gateway de aquisição de dados.

O módulo leitor de cartões MicroSD está ilustrado na figura 3.20. A tabela 3.12 ilustra o pinout. O fabricante é a LC Tecnology [62]. O dispositivo opera numa tensão nominal de 3,3 V. O módulo comunica com o microcontrolador através do protocolo SPI. Este pode servir-se da biblioteca open source do Arduíno SD.h.

Figura 3.20 Módulo leitor de cartão MicroSD LC Tecnology [62]. Tabela 3.12 Pinout módulo leitor de cartão MicroSD [62].

Pino Função

VCC Alimentação 3,3 V GND GND Potência/Lógico

CS Chip Select SPI MOSI Master Out Slave In SPI MISO Master In Slave Out SPI

CLK Clock SPI

3.5.2. Arquitetura

A figura 3.21 ilustra a arquitetura do gateway de aquisição de dados. O

hardware deste sistema engloba o microcontrolador, o programador FTDI e o

leitor de cartão microSD. O programador FTDI utilizado nesta aplicação têm três funções. A primeira é o carregamento do código para o microcontrolador. A segunda é a comunicação série dos dados de saída da gateway. A última é o fornecimento de energia a este módulo, pois optou-se por não utilizar uma bateria dedicada, uma vez que o dispositivo apenas tem utilidade prática quando conectado a um computador.

Figura 3.21 Arquitetura interna do nó gateway de aquisição de dados.

3.5.3. Controlo embebido

A figura 3.22 apresenta o fluxograma que carateriza a execução do código principal. O controlo embebido é apresentado no Anexo J. As primeiras ações no programa envolvem a inicialização de variáveis e do cartão MicroSD. Após a fase de inicializações, o programa executado pelo microcontrolador procura um ficheiro com o nome FICHD.txt. Se não for encontrado o programa reporta que o ficheiro não existe e termina, caso contrário o ficheiro é aberto e lido. A leitura é ao nível do byte. À medida que os dados são lidos estes são armazenados num buffer temporariamente. Quando a leitura for concluída o programa encerra o ficheiro e termina. Caso contrário prossegue a sequência de ações a descrever nesta seção.

Os dados lidos do ficheiro estão estruturados em linhas no formato $DDMMYY,HHMMSS,LAT,LONG,VomV,BAT, como ilustrado na figura 3.19. Cada mensagem é finalizada pelo caráter terminador e então inicia-se uma nova mensagem. Dado o facto de a leitura ser ao nível do byte é necessário um método de distinção para as linhas. Para este fim definiu-se uma condição adicional no programa a qual consistia na deteção do carater terminador.

Assim que o byte terminador é detetado tal significa que se leu uma mensagem completa. Aí, o programa executa um algoritmo de decisão ilustrado na figura 3.23, o qual é importante para as tarefas de tratamento de dados posteriores. Após a execução dessas tarefas, o programa retorna ao código principal. Então, o índice do buffer é reiniciado ficando disponível para a leitura de uma nova mensagem. Os dados de saída são transmitidos no formato de protocolo Zigbee, servindo-se da comunicação UART. Segue-se um período de espera ativa de 100 ms e então é repetido o processo de leitura de uma nova mensagem.

O algoritmo de decisão destina-se a efetuar a distinção de mensagens que podem eventualmente conter coordenadas GPS. Isto tem afetação no comprimento em bytes da mensagem, podendo assumir duas dimensões à partida conhecidas. Assim, a decisão a tomar depende do comprimento do

Figura 3.22 Fluxograma código principal.

A figura 3.24 apresenta os algoritmos de tratamento de dados. À esquerda, o caso da mensagem com dados de GPS. À direita, a situação sem coordenadas geográficas. O processo inicial é idêntico, este trata-se da leitura dos dados temporais, que são lidos do buffer no formato DDMMYYHHMMSS e inseridos na trama Zigbee.

Figura 3.24 Algoritmos para o tratamento de dados considerando a tomada de decisão.

O que difere é a eventual existência de coordenadas GPS, por sua vez, influencia a posição dos dados de interesse para o cálculo das concentrações de CO. Se houverem coordenadas geográficas, estas são lidas das posições do

buffer e inseridas na trama Zigbee. Caso contrário, os campos da trama Zigbee

destinados aos dados de GPS, são preenchidos com o caráter 0 em ASCII. Por fim, é realizado o tratamento de dados de CO, o qual se apresenta na figura 3.25.

O algoritmo de tratamento dos dados de CO considera ambos os casos acima descritos. Novamente, a dimensão do buffer é crucial para determinar as posições que guardam os dados de interesse, estes são, os dados do sinal de tensão lido do sensor de CO. Foi necessário converter estes dados para o formato inteiro, posteriormente, são determinadas as concentrações de CO. Então, estes dados são inseridos na trama Zigbee, em seguida, o programa retorna ao código principal. A tabela 3.13 ilustra o formato da trama do protocolo Zigbee. Três particularidades de relevância. A primeira o identificador de API, o qual foi configurado no formato 0x90 que carateriza a trama Zigbee no formato de receção. Segundo, o identificador de 64 bits do nó. Terceiro, o primeiro carater do payload, este permite reconhecer o formato da mensagem.

Tabela 3.13 Constituição da trama de receção Zigbee.

Constituição da trama Zigbee

Byte de início 0x7E

Comprimento da mensagem 67 bytes: 0x00 0x43

Identificador de API Formato trama receção: 0x90 Identificador de 64 bits da

gateway

0x3C,0x2B,0x4A,0x45,0x08,0x0A,0x05,0x01

Endereço Coordenador 16 bits 0xFF 0xFE

Campo número de saltos 0x00

Tipo de mensagem Mensagem broadcast: 0x00

Contéudo da mensagem *ts=DDMMYYHHMMSS&LAT=DADOS&LONG=DADOS&CO=DADOS

Byte de checksum 0x00

3.5.4. Inserção dos dados na base

Tirou-se proveito da base de dados criada anteriormente para o nó local. Deste modo, os dados são apresentados na página Web da rede de sensores na base “CO Sensor local”. A figura 3.26 apresenta parte do script do código “Msg_parser.java”.

private String[][] msgInterpreter(msgXBee m){

switch(m.get_apiId()){ // Escolhe o interpretador consoante o XBee API ID

case 0x90: // Mensagem de dados

switch(m.get_msgType()){ //Escolhe o interpretador consoante o carater que identifica o formato dos dados

// Mensagem do tipo: "*ts=170203145001&Sensor1=valor1&Sensor2=valor2" ...

case '*':

return msgCare_data.msgInterpreter(m.get_data());

}

Figura 3.26 Segmento de código que ilustra o processo de interpretação da mensagem Zigbee no código fonte “Msg_parser.java”.

É necessário conectar o nó gateway a um computador, para tal, utiliza-se o programador FTDI. Através do código “Msg_collector.java”, os dados são recolhidos e armazenados temporariamente num buffer. No código “MyQSL.java”, para o campo url atribuiu-se o endereço IPv4 do computador ao qual o nó gateway foi conectado, isto permitiria o acesso ao servidor através do referido computador. O código “Msg_parser.java” é responsável por inserir os dados na base, tal é feito através da identificação do formato da mensagem. Neste caso, o primeiro caráter do payload a identificar pelo interpretador Java deverá ser “*”. No caso afirmativo, a mensagem Zigbee é reconhecida como válida e inserida no servidor de base de dados.