Download pdf - Sistema de Telemetria Aplicado a uma Plataforma Naval - Aplicação para monitorização em tempo real dos fenómenos decorrentes do impacto de mísseis

Escola Naval

Departamento de Formação da Classe de Engenheiros

Navais Ramo de Armas e Electrónica

Sistema de Telemetria Aplicado a uma Plataforma Naval

Aplicação para monitorização em tempo real dos fenómenos

decorrentes do impacto de mísseis

Nuno Alexandre Antunes Martins Pessanha Santos

Mestrado em Ciências Militares Navais

Classe de Engenheiros Navais Ramo de Armas e Electrónica

2010




Versão Final

Escola Naval

Departamento de Formação da Classe de

Engenheiros Navais Ramo Armas e Electrónica




Nuno Alexandre Antunes Martins Pessanha Santos

Aspirante a Oficial da Classe de Engenheiros Navais

Ramo de Armas e Electrónica

Dissertação Apresentada para Obtenção do Grau de Mestre em

Ciências Militares Navais na especialidade de Engenheiro Naval no

Ramo de Armas e Electrónica

Professor Orientador: Prof. Doutor Victor Lobo

Professor Co-Orientador: Prof. Doutor Custódio Peixeiro

2010

Sistema de Telemetria aplicado a uma Plataforma Naval vii

AGRADECIMENTOS

A elaboração deste trabalho prolongou-se durante um longo período de tempo, onde

intervieram as mais diferentes pessoas. Estas tiveram diferentes, mas relevantes

contributos. A lista de colaboradores com intervenção neste trabalho é bastante vasta,

pelo que vou relembrar e agradecer-lhes neste espaço, destacando aqueles que foram

fundamentais e me marcaram de alguma forma. Não vou agradecer por ordem de

importância, porque para mim todos foram importantes - todas as peças de um puzzle

são essenciais para o poder terminar.

Do grupo inicial tenho a agradecer ao 2TEN ST-P Bastos Monsanto, que com os seus

largos conhecimentos de electrónica (e não só) me ensinou bastante. Por outro lado, do

2TEN ST-AEL Marques Vieira levo, principalmente, uma lição de vida e de trabalho, a

que devo grande parte da motivação que me levou a chegar até aqui, principalmente

devido à sua enorme experiência que me ensinou bastante. Um sentido muito obrigado a

estes dois camaradas e para o que precisarem cá estarei.

Ao ASPOF EN-AEL Gonçalves Capela, com o qual passei bastante tempo a trabalhar, o

que foi uma experiência enriquecedora.

Devo aqui também agradecer à oficina de máquinas da Escola Naval por todo o apoio

prestado, demonstrando sempre uma enorme prontidão nos trabalhos elaborados.

Queria também agradecer à CAF, nomeadamente, ao CTEN FZ Pinto Conde, STEN FZ

Cançado Tasanis e ao STEN FZ Neves Sobreiro, por todo o apoio que foi prestado para

a elaboração de testes durante o exercício efectuado e pelo acompanhamento prestado.

Ao Prof. Doutor Custódio Peixeiro, agradeço pela sua disponibilidade e acessibilidade,

possibilitando assim conhecer um pouco melhor o Mundo das antenas. Agradeço, ainda,

ao técnico Carlos Brito pela sua disponibilidade e auxílio na elaboração da antena

impressa desenhada.

Por fim, mas não menos importante, queria agradecer ao Prof. Doutor Victor Lobo por

todo o apoio demonstrado, pois abriu-me as portas e deu-me todas as ferramentas que

precisei para trabalhar, sendo também nele que está a origem do tema desta dissertação.

Aqui fica um sentido muito obrigado e votos de enorme sucesso pessoal e profissional.

Sistema de Telemetria aplicado a uma Plataforma Naval ix

RESUMO

No seu treino operacional a Marinha de Guerra Portuguesa efectua exercícios de disparo

de mísseis do tipo Seasparrow contra navios desmilitarizados. Neste tipo de actividades

detectou-se a necessidade de medir o comportamento estrutural das plataformas

atingidas, sendo os parâmetros de interesse a medir os seguintes: temperatura, pressão

e movimentação em torno dos três eixos axiais nos diversos compartimentos da

plataforma atingida. Contudo também é relevante a obtenção de imagens de vídeo do

impacto e consequente explosão.

Para responder a tal necessidade procurou-se desenvolver um sistema off-the-shelf, com

baixo custo que cumprisse as exigências do cenário em estudo. Devido ao carácter sui

generis do cenário em causa e a constrangimentos operacionais, não se pode recolher os

dados directamente da plataforma, pelo que se decidiu efectuar telemetria utilizando o

protocolo IEEE 802.3 e IEEE 802.11g para possibilitar o envio a longa distância – entre o

navio alvo e o navio de monitorização.

Após adquirir o equipamento necessário para efectuar um sistema de telemetria de baixo

custo, como o conceito não se encontrava muito desenvolvido pela Marinha de Guerra

Portuguesa, foram efectuados diversos testes aos equipamentos adquiridos. Esses testes

consistiram na medição da largura de banda obtida na ligação wireless utilizada, na

aferição do desempenho nos Dataloggers adquiridos, na utilização das cameras

adquiridas, na interligação dos diversos equipamentos, determinando a taxa de

transferência necessária para a sua utilização, e testou-se exaustivamente a ferramenta

Arduino Duemilinove, procurando avaliar se este seria uma alternativa de baixo custo

viável aos Dataloggers Dataq DI-710-EL adquiridos.

Foram, no entanto, adquiridos através dos testes descritos anteriormente e de toda a

revisão teórica dados que possibilitaram aferir se o sistema a desenvolver se enquadrava

no idealizado inicialmente. Assim percebeu-se que a tecnologia eleita cumpre os

requisitos para efectuar telemetria.

Palavras-Chave: Marinha Portuguesa, Escola Naval, Telemetria, Off-the-shelf, Sensores.

Sistema de Telemetria aplicado a uma Plataforma Naval xi

ABSTRACT

In its operational training the Portuguese Navy performs live firing exercises using

Seasparrow missiles against old decommissioned ships. From this kind of activity it was

detected the need to measure the structural behavior of the platforms during the impacts.

The physical parameters of interest are basically pressure, temperature and movement

around the three axial axes in the various compartments in the sinking platform. However

it is also important to obtain video footage of the impact and from the explosion.

To meet this need and fulfill the study scenario requirements a low cost off-the-shelf

system has been developed. Due to the sui generis character of the study scenario and

from operational constrains, it was impossible to collect data directly from the platform. So

it was therefore decided to make telemetry using the IEEE 802.3 and the IEEE 802.11g

protocols to transmit data over long distances – between the target ship and the

monitoring ship.

After the acquisition of the necessary equipment to make a low cost telemetry system

several tests have been made to the equipment, because the concept is not yet very

much developed in the Portuguese Navy. Those tests consisted in the measure of the

required bandwidth in the used wireless connection, in performance measurement in the

acquired data loggers, the use of the acquired cameras, in the interconnection of the

several equipments, measuring the required throughput in its use, and was tested

exhaustively the Arduino Duemilinove tool, in the attempt to assess whether it would be a

reliable and low cost alternative to the acquired Dataq DI-710-EL data logger.

Howevwe, from the described tests and the theorical approach used, it was possible to

show that the developed system is near the idealizaed initially. So it is shown that the

chosen technology fulfill all the requirements to make telemetry.

Keywords: Portuguese Navy, Naval Academy, Telemetry, Off-the-shelf, Sensors.

Sistema de Telemetria aplicado a uma Plataforma Naval xiii

ÍNDICE

AGRADECIMENTOS ....................................................................................................... vii

RESUMO .......................................................................................................................... ix

ABSTRACT ...................................................................................................................... xi

ÍNDICE ........................................................................................................................... xiii

LISTA DE FIGURAS ....................................................................................................... xxi

LISTA DE TABELAS .................................................................................................... xxxiii

LISTA DE GRÁFICOS ................................................................................................. xxxix

LISTA DE ABREVIATURAS ............................................................................................ xli

1. CAPÍTULO I INTRODUÇÃO ...................................................................................... 1

1.1 ENQUADRAMENTO .......................................................................................... 1

1.2. ORGANIZAÇÂO DA TESE ................................................................................. 6

1.2.1. METODOLOGIA UTILIZADA ....................................................................... 6

1.2.2. FASE EXPLORATIVA ................................................................................. 7

1.2.3. FASE ANALÍTICA .......................................................................................11

1.2.4. FASE CONCLUSIVA ..................................................................................15

1.3. CONTRIBUIÇÕES DA TESE .............................................................................16

2. CAPÍTULO II REDES DE SENSORES E AQUISIÇÃO DE DADOS ..........................17

2.1. INTRODUÇÃO ..................................................................................................17

2.2. REDES DE SENSORES....................................................................................18

2.2.1. CALIBRAÇÃO DE SENSORES ..................................................................21

2.2.2. TIPOS DE ERROS DE MEDIDA.................................................................22

2.2.3. APLICAÇÕES ACTUAIS DAS REDES DE SENSORES EM AMBIENTE

MILITAR ...................................................................................................................24

2.2.4. CONSTITUINTES DE UMA REDE DE SENSORES ...................................27

2.2.5. CARACTERÍSTICAS PRESENTES NAS REDES DE SENSORES ............27

Aplicação para a monitorização em tempo real dos fenómenos decorrentes do impacto de mísseis

xiv Sistema de Telemetria aplicado a uma Plataforma Naval

2.2.6. ALIMENTAÇÃO DE UMA REDE DE SENSORES ..................................... 29

2.3. RECOLHA DE DADOS ..................................................................................... 30

2.3.1. CONVERSÃO A/D ..................................................................................... 31

2.3.2. GAMA DE VALORES DE ENTRADA E RESOLUÇÃO ............................... 35

2.3.3. ERROS NUM CONVERSOR A/D............................................................... 36

2.3.4. TEOREMA DA AMOSTRAGEM ................................................................. 38

2.4. CONCLUSÕES OU SÍNTESE ........................................................................... 41

3. CAPÍTULO III TELEMETRIA E PROTOCOLOS DE REDE ...................................... 43

3.1. INTRODUÇÃO .................................................................................................. 43

3.2. TELEMETRIA.................................................................................................... 43

3.3. MODELO OSI VS MODELO TCP/IP ................................................................. 45

3.3.1. CAMADA DE APLICAÇÃO......................................................................... 46

3.3.2. CAMADA DE TRANSPORTE ..................................................................... 46

3.3.3. CAMADA DE REDE ................................................................................... 47

3.3.4. CAMADA DE LIGAÇÃO ............................................................................. 47

3.3.5. CAMADA FÍSICA ....................................................................................... 48

3.4. IEEE802.3 - ETHERNET ................................................................................... 48

3.4.1. LOGICAL LINK CONTROL (LLC)............................................................... 50

3.4.2. MEDIA ACCESS CONTROL (MAC) ........................................................... 50

3.5. A NORMA IEEE 802.11G .................................................................................. 51

3.5.1. EXISTÊNCIA DE 4 CAMADAS FÍSICAS DISTINTAS ................................ 54

3.5.2. O SUPORTE OBRIGATÓRIO DE UM SHORT PREAMBLE STYLE .......... 57

3.5.3. O ATRIBUTO DE REDE EXTENDED RATE PHYSICALS (ERP)............... 58

3.5.4. ASPECTOS DE INTEROPERABILIDADE .................................................. 59

3.5.5. O MECANISMO CTS-TO-SELF ................................................................. 59

3.5.6. O DÉBITO REAL - IEEE 802.11G .............................................................. 60

3.6. COMO ANALISAR A PERFORMANCE DE UMA REDE ................................... 61

Índice

Sistema de Telemetria aplicado a uma Plataforma Naval xv

3.6.1. INTERFERÊNCIAS EM REDES DE COMPUTADORES ............................63

3.7. SENSORES DE REDE ......................................................................................64

3.8. CONCLUSÕES OU SÍNTESE ...........................................................................66

4. CAPÍTULO IV IMPLEMENTAÇÃO DO SISTEMA ....................................................67

4.1. INTRODUÇÃO ..................................................................................................67

4.2. MATERIAL OFF-THE-SHELF UTILIZADO ........................................................67

4.2.1. ROUTER UTILIZADO .................................................................................68

4.2.2. SENSOR DE TEMPERATURA - TERMOPAR ............................................69

4.2.3. SENSOR DE PRESSÃO ............................................................................71

4.2.4. ACELERÓMETROS ...................................................................................72

4.2.5. DATALOGGER DATAQ DI-710-EL ............................................................74

4.3. FERRAMENTA DE DESENVOLVIMENTO ARDUINO ......................................76

4.3.1. ARDUINO – PRINCÍPIOS BÁSICOS ..........................................................77

4.3.2. ARDUINO COMO DATALOGGER .............................................................80

4.3.3. SHIELD ETHERNET ......................................................................................82

4.3.4. DATAQ VS ARDUINO ....................................................................................84

4.4. AGREGADO PLANAR 4X4 DESENHADO, FABRICADO E TESTADO .............84

4.5. ANÁLISE DE UM CASO DE ESTUDO ..............................................................89

4.6. CONCLUSÕES OU SÍNTESE ...........................................................................92

5. CAPÍTULO V TRABALHO DE CAMPO E RESULTADOS ........................................93

5.1. INTRODUÇÃO ..................................................................................................93

5.2. CARACTERIZAÇÃO DA CURVA DE CONVERSÃO A/D DE UM ARDUINO

DUEMILINOVE ............................................................................................................94

5.2.1. CONDIÇÕES E OBJECTIVOS DOS TESTES ............................................94

5.2.2. DESCRIÇÃO DOS TESTES EFECTUADOS ..............................................95

5.2.3. ESQUEMÁTICO UTILIZADO ......................................................................96

5.2.4. RESULTADOS OBTIDOS ..........................................................................96


xvi Sistema de Telemetria aplicado a uma Plataforma Naval

5.2.5. CONCLUSÕES ........................................................................................ 103

5.3. TESTES DE TELEMETRIA A MÍSSEIS MILAN ............................................... 103

5.3.1. CONDIÇÕES E OBJECTIVOS DOS TESTES ......................................... 105

5.3.2. DESCRIÇÃO DOS TESTES EFECTUADOS ........................................... 105

5.3.3. ESQUEMÁTICO UTILIZADO ................................................................... 105

5.3.4. RESULTADOS OBTIDOS E SUA INTERPRETAÇÃO ............................. 106

5.3.5. CONCLUSÕES ........................................................................................ 116

5.4. MATLAB E ARDUINO – CAPACIDADES DE AQUISIÇÃO ............................. 118




5.4.4. RESULTADOS OBTIDOS ........................................................................ 122

5.4.5. CONCLUSÕES ........................................................................................ 127

5.5. CÂMARA DE ALTA-VELOCIDADE ................................................................. 127




5.5.4. RESULTADOS OBTIDOS ........................................................................ 129

5.5.5. CONCLUSÕES ........................................................................................ 136

6. CAPÍTULO VI CONCLUSÕES E RECOMENDAÇÕES ......................................... 137

6.1. INTRODUÇÃO ............................................................................................ 137

6.2. HIPÓTESES E OBJECTIVOS CUMPRIDOS ............................................... 138

6.3. RECOMENDAÇÕES E SUGESTÕES ......................................................... 141

6.4. LIMITAÇÕES E PROBLEMAS ENCONTRADOS ........................................ 142

7. BIBLIOGRAFIA ...................................................................................................... 145

A APÊNDICE A JORNADAS DO MAR 2008 ............................................................. 151

A.1. ARTIGO SUBMETIDO .................................................................................... 151

Índice

Sistema de Telemetria aplicado a uma Plataforma Naval xvii

A.2. TELEMETRIA UTILIZANDO A NORMA IEEE 802.11G ................................... 152

A.3. APRESENTAÇÃO EFECTUADA JORNADAS DO MAR 2008 NA ESCOLA

NAVAL .................................................................................................................... 172

B APÊNDICE B AFCEA 2009 .................................................................................... 177

B.1. INTRODUÇÃO ................................................................................................ 177

B.2. TELEMETRY USING THE IEEE 802.11G STANDARD FOR MONITORING

TARGET SHIPS ..................................................................................................... 178

B.3. APRESENTAÇÃO EFECTUADA NA TECHNET INTERNATIONAL EM

BRUXELAS ............................................................................................................ 197

C APÊNDICE C ELABORAÇÃO E CONSTRUÇÃO DE UM AGREGADO PLANAR 4X4

200

C.1. INTRODUÇÃO ................................................................................................ 200

C.2. RELATÓRIO I ................................................................................................. 200

C.3. RELATÓRIO II ................................................................................................ 213

C.4. RELATÓRIO III ............................................................................................... 231

C.5. RELATÓRIO IV ............................................................................................... 241

C.6. ABORDAGEM PRÁTICA À ANTENA ELABORADA ....................................... 252

C.7. APRESENTAÇÃO EFECTUADA .................................................................... 267

C.8. ABSTRACT SUBMETIDO IEEE AP-S/URSI INTERNATIONAL SYMPOSIUM

2010 - TORONTO ................................................................................................... 272

C.9. APRESENTAÇÃO IEEE AP-S/URSI INTERNATIONAL SYMPOSIUM 2010 ... 274

D APÊNDICE D TRABALHO EFECTUADO NO ÂMBITO DO ARDUINO ................... 277

D.1. INTRODUÇÃO ................................................................................................ 277

D.2. TUTORIAL ARDUINO ..................................................................................... 278

D.3. APRESENTAÇÃO EFECTUADA .................................................................... 345

D.4. FICHA DE TRABALHO - ARDUINO ................................................................ 351

D.5. SOLUÇÕES FICHA DE TRABALHO - ARDUINO ........................................... 354

D.6. ARTIGO “INTRODUÇÃO AO ARDUINO” ........................................................ 360


xviii Sistema de Telemetria aplicado a uma Plataforma Naval

D.7. ARTIGO “ARDUINO E A AQUISIÇÃO DE DADOS” ........................................ 374

D.8. ARTIGO “CÁLCULO DA FFT RECORRENDO A UM ARDUINO” ................... 379

D.9. CÓDIGO QUE SERVIU DE BASE AO ARTIGO “ARDUINO E A AQUISIÇÃO DE

DADOS” ................................................................................................................. 387

E APÊNDICE E TELEMETRIA EM EXERCÍCIO DE DISPARO DE MÍSSEIS MILAN 392

E.1. RELATÓRIO ELABORADO ............................................................................ 392

E.2. CÓDIGO MATLAB UTILIZADO ....................................................................... 404

E.3. FOTOS DA ELABORAÇÃO E TESTE............................................................. 418

F APÊNDICE F POSTERS APRESENTADOS NA ESCOLA NAVAL FRANCESA .... 421

F.1. INTRODUÇÃO ................................................................................................ 421

F.2. TELEMETRY USING THE IEEE802.11G STANDARD, FOR MONITORING

TARGET SHIPS ..................................................................................................... 422

F.3. TELEMETRY THE EFFECTS OF MILAN MISSILES ....................................... 423

F.4. MICROSTRIP ARRAY ANTENNA FOR IEEE802.11G .................................... 424

G APÊNDICE G ESTIMAÇÃO DO COMPORTAMENTO DE UMA COMUNICAÇÃO

WIRELESS USANDO REDES NEURONAIS ................................................................ 425

G.1. INTRODUÇÃO ............................................................................................... 425

G.2. TRABALHO APRESENTADO ........................................................................ 425

G.3. ANEXOS ........................................................................................................ 437

H APÊNDICE H TESTES PRÁTICOS EFECTUADOS .............................................. 455

H.1. INTRODUÇÃO ................................................................................................ 455

H.2. TESTE À TAXA DE AMOSTRAGEM AO NÍVEL DO UTILIZADOR ................. 455

H.3. CÓDIGO DE AQUISIÇÃO UTILIZADO – MATLAB E ARDUINO - NA

DETERMINAÇÃO DOS VALORES OBTIDOS ANTERIORMENTE ........................ 459

H.3.1. CÁLCULO DO TEMPO DE AQUISIÇÃO SÉRIE E GUARDAR EM FICHEIRO

DE TEXTO E EXCEL EM MATLAB ........................................................................ 459

H.3.2. CÁLCULO DO TEMPO DE AQUISIÇÃO TCP/IP E GUARDAR EM FICHEIRO

DE TEXTO E EXCEL EM MATLAB ........................................................................ 460

Índice

Sistema de Telemetria aplicado a uma Plataforma Naval xix

H.3.3. CÁLCULO DO TEMPO DE AQUISIÇÃO SÉRIE UTILIZANDO A FUNÇÃO

“FREAD()”, E GUARDAR EM FICHEIRO DE TEXTO E EXCEL EM MATLAB ........ 461

H.3.4. CÁLCULO DO TEMPO DE AQUISIÇÃO TCP/IP UTILIZANDO A FUNÇÃO

“FREAD()”, E GUARDAR EM FICHEIRO DE TEXTO E EXCEL EM MATLAB ........ 462

H.3.5. CÓDIGO DO ARDUINO PARA CÁLCULO DO TEMPO DE AMOSTRAGEM

............................................................................................................................... 463

H.3.6. CÓDIGO DO ARDUINO PARA DETERMINAÇÃO DO TEMPO GASTO NA

INSTRUÇÃO – SERIAL.PRINT .............................................................................. 463


INSTRUÇÃO – SERIAL.PRINTLN .......................................................................... 464


INSTRUÇÃO – SERVER.PRINT ............................................................................ 465

H.3.9. AQUISIÇÃO POR MATLAB DOS VALORES ENVIADOS POR SÉRIE (1000

VALORES) E ARMAZENAMENTO EM FICHEIRO EXCEL PARA POSTERIOR

CÁLCULO DA MÉDIA............................................................................................. 466

H.3.10. CÓDIGO DO ARDUINO PARA UTILIZAR EM AQUISIÇÃO SÉRIE COM A

FUNÇÃO “FREAD()” ............................................................................................... 467

H.3.11. CÓDIGO DO ARDUINO PARA UTILIZAR EM AQUISIÇÃO TCP/IP COM A

FUNÇÃO “FREAD()” ............................................................................................... 467

H.4. TESTE AO COMPORTAMENTO DO CONVERSOR A/D ............................... 468

H.4.1. CÓDIGO DO ARDUINO PARA ENVIO DO VALOR DE UM PINO

ANALÓGICO .......................................................................................................... 468

H.4.2. GRÁFICOS DO ERRO ABSOLUTO OBTIDOS PARA DIFERENTES

VALORES DE PRESCALER .................................................................................. 469

H.5. GRÁFICOS OBTIDOS UTILIZANDO O SOFTWARE BITMETER ................... 471

H.5.1. TESTES MILAN ........................................................................................... 471

H.5.2. TESTES CÂMARA DE ALTA VELOCIDADE ................................................ 473

A ANEXO A CHARACTERIZATION AND CALIBRATION OF THE ADC ON AN AVR

478

Sistema de Telemetria aplicado a uma Plataforma Naval xxi

LISTA DE FIGURAS

Figura 1 – Esquema design do método científico .............................................................. 7

Figura 2 – Representação ideal do sistema final a desenvolver ........................................ 8

Figura 3 – Esquema design fase explorativa ...................................................................11

Figura 4 – Esquema design fase analítica .......................................................................15

Figura 5 – Esquema design fase conclusiva ....................................................................15

Figura 6 – Principio de funcionamento de um transdutor .................................................18

Figura 7 – Leitura e apresentação dos dados provenientes de um sensor num display ...20

Figura 8 – Leitura e conversão A/D dos dados provenientes de um sensor para

armazenamento ou display ..............................................................................................20

Figura 9 – Hierarquia de compreensão e utilidade ...........................................................20

Figura 10 – Introdução de uma modifying input na variação da curva de calibração de um

sensor ..............................................................................................................................21

Figura 11 – Exemplo da fusão de dados provenientes de 3 sensores .............................22

Figura 12 – Analogia de um alvo com a precisão das medidas efectuadas .....................23

Figura 13 – Representação de uma distribuição Gaussiana ............................................23

Figura 14 – Exemplo de um sistema de vigilância oceânica (ocean surveillance) ............25

Figura 15 – Os três Pilares constituintes de uma rede de sensores .................................27

Figura 16 – Exemplos de várias gerações de sensores ...................................................28

Figura 17 – Esquemático da situação operacional ...........................................................29

Figura 18 – Esquemático simplificado da rede de sensores a implementar .....................29

Figura 19 – Diagrama do esquema de um sistema de comunicações (Esquema geral) ..30

Figura 20 – Esquema de blocos de um conversor A/D (ADC) ..........................................32

Figura 21 – Representação de um quantizador uniforme de 3 bits ..................................33

Lista de Figuras

xxii Sistema de Telemetria aplicado a uma Plataforma Naval

Figura 22 – Representação do ruído de entrada de um conversor A/D ........................... 33

Figura 23 – Representação do comportamento ideal de um ADC, face à existência de

ruído de entrada .............................................................................................................. 34

Figura 24 – Representação do comportamento de um conversor A/D mal desenhado ... 34

Figura 25 – Sinal de entrada amostrado com uma taxa de amostragem 2 vezes a sua

frequência ....................................................................................................................... 35

Figura 26 – Sinal de entrada amostrado com uma taxa de amostragem 8 vezes a sua

frequência ....................................................................................................................... 36

Figura 27 – Exemplo de erros de Offset positivos (A) e negativos (B) ............................. 36

Figura 28 – Exemplo de erro em Ganho positivo (A) e negativo (B) ................................ 37

Figura 29 – Exemplo de erros DNL (A) e exemplo de erro INL (B) .................................. 38

Figura 30 – Exemplo de um sinal limitado na sua banda ................................................. 38

Figura 31 – Transformada de Fourier de um sinal amostrado respeitando o teorema da

amostragem .................................................................................................................... 39

Figura 32 – Exemplo de aliasing ..................................................................................... 39

Figura 33 – Exemplo de aliasing numa função do tipo seno ............................................ 40

Figura 34 – Exemplo de filtro passa-baixo (antialiasing filter) aplicado para evitar a

ocorrência de aliasing ..................................................................................................... 40

Figura 35 – Diagrama de blocos para um sistema de telemetria ..................................... 44

Figura 36 – Recriação do esboço original efectuado por Metcalfe do standard de internet

10 Base 5 ........................................................................................................................ 48

Figura 37 – Modelo de referência TCP/IP - Exemplo de Implementação ......................... 48

Figura 38 – Dois exemplos de utilização da norma IEEE 802.3 ....................................... 49

Figura 39 – Relação do modelo OSI com a norma IEEE 802.3 ....................................... 49

Figura 40 – Representação de uma ligação full-duplex ................................................... 50

Figura 41 – Representação de uma ligação half-duplex .................................................. 50

Figura 42 – O espectro de frequências utilizado pela norma IEEE 802.11 ...................... 52

Figura 43 – Frequency Hopping Spread Spectrum (FHSS) ............................................. 52

Lista de Figuras

Sistema de Telemetria aplicado a uma Plataforma Naval xxiii

Figura 44 – Representação do funcionamento do Direct Sequence Spread Spectrum

(DSSS) ............................................................................................................................53

Figura 45 – Uso da técnica CCK para a transmissão do Preâmbulo/Cabeçalho

(Preamble/Header) e para os dados constituintes da comunicação (Payload) ................54

Figura 46 – Uso da técnica OFDM para a transmissão do Preâmbulo/Cabeçalho

(Preamble/Header) e para os dados constituintes da comunicação (Payload) ................55

Figura 47 – Uso da técnica DSSS/PBCC para a transmissão híbrida do

Preâmbulo/Cabeçalho (Preamble/Header) e para os dados constituintes da comunicação

(Payload) .........................................................................................................................55

Figura 48 – Uso da técnica DSSS - OFDM para a transmissão híbrida do

Preâmbulo/Cabeçalho (Preamble/Header) e para os dados constituintes da comunicação

(Payload) .........................................................................................................................55

Figura 49 – Elementos obrigatórios e opcionais da norma IEEE 802.11g ........................55

Figura 50 – Representação das múltiplas portadoras utilizando a técnica de OFDM (A) .56

Figura 51 – Representação das múltiplas portadoras utilizando a técnica de OFDM (B) .56

Figura 52 – Representação da portadora na técnica CCK ...............................................57

Figura 53 – (a) RTS/CTS e (b) CTS-to-self ......................................................................60

Figura 54 – Topologia de rede básica a utilizar ................................................................64

Figura 55 – Sensor com componente para comunicar em rede .......................................65

Figura 56 – Imagem de um router Linksys WRT54GS (versão 7) ....................................69

Figura 57 – Representação do princípio de Seebeck .......................................................69

Figura 58 – Representação do princípio de Seebeck .......................................................70

Figura 59 – Termopar adquirido modelo JQSS-IM15E-300 .............................................70

Figura 60 – Representação da constituição do sensor de temperatura adquirido ............72

Figura 61 – Representação da construção do elemento principal de um sensor capacitivo

........................................................................................................................................73

Figura 62 – Modelo simplificado de um acelerómetro capacitivo .....................................73

Figura 63 – Representação do PGA presente no Datalogger Dataq DI-710-EL ...............74

Figura 64 – Representação do PGA presente no Datalogger Dataq DI-710-EL ...............75

Lista de Figuras

xxiv Sistema de Telemetria aplicado a uma Plataforma Naval

Figura 65 – Datalogger Dataq DI-710-EL ........................................................................ 75

Figura 66 – Representação de um Arduino Duemilinove ................................................. 77

Figura 67 – Representação dos constituintes principais de um Arduino Duemilinove ...... 79

Figura 68 – Representação do funcionamento do Prescaler do microcontrolador

ATmega168 ..................................................................................................................... 81

Figura 69 – Shield Ethernet ............................................................................................. 82

Figura 70 – Chip Ethernet Wiznet 5100 ........................................................................... 83

Figura 71 – Representação do agregado planar 4x4 desenvolvido ................................. 85

Figura 72 – Representação das medições efectuadas em camera anecóica .................. 86

Figura 73 – Agregado de elementos quadrados impressos de 4x4 ................................. 86

Figura 74 – Medição experimental do S11 utilizando um VNA .......................................... 87

Figura 75 – Representação para motivos de estudo do piso de um navio ....................... 89

Figura 76 – Aparato experimental utilizado nos testes de caracterização do conversor A/D

........................................................................................................................................ 96

Figura 77 – Forma de onda utilizada para determinar o erro absoluto ............................. 99

Figura 78 – Forma de onda utilizada para determinar o erro absoluto ............................. 99

Figura 79 – Alvo utilizado durante o exercício de disparo de mísseis MILAN (visto de trás)

...................................................................................................................................... 103

Figura 80 – Alvo utilizado durante o exercício de disparo de mísseis MILAN (visto de lado)

...................................................................................................................................... 104

Figura 81 – Esquema do alvo e disposição dos sensores utilizada ............................... 104

Figura 82 – Míssil MILAN .............................................................................................. 104

Figura 83 – Aparato experimenta MILAN para apenas um equipamento ....................... 106

Figura 84 – Aparato experimental MILAN para mais do que um equipamento .............. 106

Figura 85 – Leitura de 1 Arduino e 1 Datalogger utilizando o software BitMeter ............ 115

Figura 86 – Leitura de 1 Arduino e 1 Datalogger utilizando o software BitMeter ............ 115

Figura 87 – Esquemático utilizado para os testes ao tempo de conversão A/D e tempo de

envio por série ............................................................................................................... 121

Lista de Figuras

Sistema de Telemetria aplicado a uma Plataforma Naval xxv

Figura 88 – Esquemático utilizado para os testes ao tempo de envio por Ethernet ........ 121

Figura 89 – Representação esquemática das dimensões óptimas do vídeo .................. 128

Figura 90 – Aparato experimental utilizado para testes à camera de alta-velocidade .... 129

Figura 91 – A equipa inicial GEBA constituída por 4 elementos ..................................... 151

Figura 92 – Esquema geral de ligações ......................................................................... 153

Figura 93 – Zona de Fresnel .......................................................................................... 155

Figura 94 – Sinal na placa Intel Pro ............................................................................... 157

Figura 95 – Sinal na placa Intel PRO medido pelo NetStumbler .................................... 157

Figura 96 – Configuração de firmware do router ............................................................ 158

Figura 97 - Configuração de firmware do router ............................................................. 158

Figura 98 – Diagrama de irradiação das antenas Ferimex utilizadas ............................. 160

Figura 99 – Nível médio de sinal router ......................................................................... 162

Figura 100 – Nível de ruído router ................................................................................. 162

Figura 101 – Nível médio de sinal amplificador (com ATT= 6dB) ................................... 163

Figura 102 – SWR da antena 1 ...................................................................................... 163

Figura 103 – SWR da antena 2 ...................................................................................... 163

Figura 104 – Esquema de teste da resposta de antenas ............................................... 164

Figura 105 – Esquema para medição da largura de banda ............................................ 167

Figura 106 – Entrega do prémio em Bruxelas durante a conferência Technet International

...................................................................................................................................... 177

Figura 107 – Durante a 1ª parte da apresentação ......................................................... 177

Figura 108 – Durante a refeição com o Comodoro inglês Robert Howell ....................... 177

Figura 109 – Rectangular Planar Plot simulação 1 ........................................................ 202

Figura 110 – 3D Pattern Plot (A) simulação 1 ................................................................ 203

Figura 111 – 3D Pattern Plot (B) simulação 1 ................................................................ 203



Lista de Figuras

xxvi Sistema de Telemetria aplicado a uma Plataforma Naval











Figura 124 – Adaptador de ..................................................................................... 214

Figura 125 – Esquema da simulação 1 ......................................................................... 216

Figura 126 – Diagrama do parâmetro S ........................................................................ 217

Figura 127 – Diagrama do parâmetro Z ......................................................................... 217

Figura 128 – Carta de Smith de impedâncias ................................................................ 217

Figura 129 – Diagrama cartesiano representando o ganho e a componente E – theta .. 218

Figura 130 – Diagrama de radiação tridimensional ........................................................ 218











Lista de Figuras

Sistema de Telemetria aplicado a uma Plataforma Naval xxvii



Figura 143 – Esquema da simulação 4 .......................................................................... 225

Figura 144 – Diagrama do parâmetro S ......................................................................... 226





Figura 149 – Esquema da simulação 6 .......................................................................... 228

Figura 150 – Esquema pormenorizado da simulação 6 ................................................. 229





Figura 155 – Esquema da simulação ............................................................................. 233


Figura 157 – Diagrama do parâmetro Z (Re) .................................................................. 234

Figura 158 – Diagrama do parâmetro Z (Im) ................................................................... 234



Figura 161 – Diagrama cartesiano representando o ganho e a componente E – Phi ..... 235

Figura 162 – Distribuição de correntes no elemento ...................................................... 236

Figura 163 – Diagrama de radiação tridimensional ( ......................... 236

Figura 164 – Diagrama de radiação tridimensional ( ......................... 236

Figura 165 – Diagrama de radiação tridimensional ( ........................... 237

Figura 166 – Diagrama de radiação tridimensional ( ..................... 237

Figura 167 – Diagrama de radiação tridimensional ( ....................... 237

Lista de Figuras

xxviii Sistema de Telemetria aplicado a uma Plataforma Naval

Figura 168 – Modelo desenhado em AutoCAD (Medidas em ) ............................... 239

Figura 169 – Modelo 3D desenhado em AutoCAD (Ilustrativo) ...................................... 240

Figura 170 – Modelo 3D desenhado em AutoCAD (Ilustrativo) ...................................... 240


Figura 172 – Esquema da simulação ............................................................................ 243


Figura 174 – Diagrama do parâmetro Z (Re).................................................................. 244

Figura 175 – Diagrama do parâmetro Z (Im) .................................................................. 244



Figura 178 – Diagrama de radiação tridimensional ( ............................ 245

Figura 179 – Diagrama de radiação tridimensional ( .......................... 245

Figura 180 – Diagrama de radiação tridimensional ( ........................ 246


Figura 182 – Diagrama do parâmetro Z (Re).................................................................. 247

Figura 183 – Diagrama do parâmetro Z (Im) ................................................................. 247



Figura 186 – Diagrama de radiação tridimensional ( ...................... 248

Figura 187 – Diagrama de radiação tridimensional ( ........................ 249

Figura 188 – Diagrama de radiação tridimensional ( .......................... 249

Figura 189 – Diagrama de radiação tridimensional ( ............................ 249

Figura 190 – Modelo desenhado em AutoCAD (Medidas em ) ............................... 251

Figura 191 – Modelo 3D desenhado em AutoCAD (Apenas Ilustrativo) ......................... 252

Figura 192 – Foto durante a limpeza da placa de substrato .......................................... 253

Figura 193 – Foto da estufa utilizada ............................................................................. 253

Figura 194 – Foto da antena elaborada 1 ...................................................................... 254

Lista de Figuras

Sistema de Telemetria aplicado a uma Plataforma Naval xxix

Figura 195 – Verificação da temperatura da estufa ........................................................ 254

Figura 196 – Utilização de um superstrato à base de folhas de papel autocolante ........ 254

Figura 197 – Testes à constante dieléctrica do superstrato feito à base de folhas de papel

autocolante .................................................................................................................... 254

Figura 198 – Antena na camera anecóica ...................................................................... 255

Figura 199 – Durante as medições na camera anecóica do IST .................................... 255

Figura 200 – Esquema da utilização de um superstrato ................................................. 256

Figura 201 – Esquema da utilização de um superstrato feito de folhas de papel

autocolante .................................................................................................................... 257

Figura 202 – Representação da técnica de efectuar um stub ou slot ............................. 260

Figura 203 – Utilização de um superstrato com as mesmas características do substrato

utilizado ......................................................................................................................... 263

Figura 204 – Demonstração da dimensão e ..................................................... 264

Figura 205 – Arduino Duemilinove ................................................................................. 279

Figura 206 – Arduino Mega............................................................................................ 279

Figura 207 – Exemplo de uma montagem utilizando um microprocessador ................... 280

Figura 208 – Exemplo de um microcontrolador com algumas das funcionalidades

possíveis ........................................................................................................................ 281

Figura 209 – Diagrama de blocos de um microcontrolador ATMega168 ........................ 281

Figura 210 – Representação esquemática do Arduino Duemilinove .............................. 283

Figura 211 – Exemplo de sinal PWM ............................................................................. 284

Figura 212 – Representação de um impulso PWM ........................................................ 285

Figura 213 – Imagem da parte superior do site oficial do Arduino .................................. 287

Figura 214 – Imagem da parte superior do site oficial do Arduino. ................................. 288

Figura 215 – – Conteúdo da pasta que contém o Software de desenvolvimento Arduino

...................................................................................................................................... 288

Figura 216 – Esquema de um FTDI ............................................................................... 288

Figura 217 – Software de desenvolvimento Arduino ...................................................... 289

Lista de Figuras

xxx Sistema de Telemetria aplicado a uma Plataforma Naval

Figura 218 – Botão para compilar o Sketch elaborado .................................................. 289

Figura 219 – Botão para efectuar uploading .................................................................. 289

Figura 220 – Esquema da fase de desenvolvimento de uma aplicação - Ciclo de

desenvolvimento ........................................................................................................... 290

Figura 221 – Esquema da fase de desenvolvimento de uma aplicação ......................... 290

Figura 222 – Imagem da parte superior do site oficial do Arduino ................................. 290

Figura 223 – Representação de um servomotor ............................................................ 326

Figura 224 – Representação de um servomotor de posição mais pormenorizada ......... 327

Figura 225 – Representação de uma comunicação série assíncrona ............................ 332

Figura 226 – Representação de uma comunicação série síncrona ............................... 332

Figura 227 – Representação possível de um Hello World utilizando o “Processing” ...... 337

Figura 228 – Alguns exemplos criados utilizando o “Processing” .................................. 337

Figura 229 – Constituintes de um conversor A/D ........................................................... 338

Figura 230 – Exemplo de aliasing ................................................................................. 339

Figura 231 – ADC Prescaler .......................................................................................... 340

Figura 232 – Representação de um triângulo rectângulo .............................................. 353

Figura 233 – Representação esquemática de um Arduino Duemilinove ........................ 353

Figura 234 – Arduino Diecimilia ..................................................................................... 361

Figura 235 – Representação de um Arduino Diecimilia em desenho ............................. 361

Figura 236 – Créditos do software open-source utilizado no Arduino ............................ 363

Figura 237 – Representação do ambiente de desenvolvimento .................................... 364

Figura 238 – Representação da constituição do código ................................................ 364

Figura 239 – Representação das baud rates aceitadas pelo software de desenvolvimento

Arduino .......................................................................................................................... 366

Figura 240 – Representação da ligação de um led aos pinos de entrada de um Arduino

...................................................................................................................................... 368

Figura 241 – Representação da ligação de um LDR a uma breadboard ....................... 370

Figura 242 – Representação de uma ligação física USB ............................................... 372

Lista de Figuras

Sistema de Telemetria aplicado a uma Plataforma Naval xxxi

Figura 243 – Representação do botão serial monitor existente no software de

desenvolvimento Arduino ............................................................................................... 372

Figura 244 – Representação do da variação do duty cicle de um sinal .......................... 373

Figura 245 – Representação de um shield zigbee e Ethernet ........................................ 374

Figura 246 – Exemplo de um sinal em que ocorreu aliasing .......................................... 375

Figura 247 – Conteúdo do registo ADCSRA .................................................................. 376

Figura 248 – Sistema de aquisição desenvolvido .......................................................... 397

Figura 249 – Esquemático simplificado do exercício realizado ...................................... 397

Figura 250 – – Esquemático simplificado da colocação dos sensores ........................... 397

Figura 251 – Esquemático utilizado na aquisição de imagens da camera de alta-

velocidade ..................................................................................................................... 398

Figura 252 – Esquemático simplificado da colocação das cameras utilizadas ............... 398

Figura 253 – Esquema do sistema de aquisição por wireless ........................................ 399

Figura 254 – Esquema do sistema de aquisição de um PC de registo montado no alvo 400

Figura 255 – Montagem das caixas de protecção .......................................................... 418

Figura 256 – Caixas de protecção construídas e respectivos Arduinos ......................... 418

Figura 257 – Local de disparo dos mísseis MILAN ........................................................ 418

Figura 258 – Efeito de carga focal ................................................................................. 419

Figura 259 – Alvo após impacto ..................................................................................... 419

Figura 260 – Montagem do inversor na viatura de apoio ............................................... 419

Figura 261 – Termopar depois de instalado no alvo ...................................................... 420

Figura 262 – Equipa presente no dia do exercício ......................................................... 420

Figura 263 – Aparato montado no alvo .......................................................................... 420

Figura 264 – Esquemático dos testes ............................................................................ 426

Figura 265 – Representação do firmware DD-WRT e do software BitMeter ................... 427

Figura 266 – Representação dos dados retirados .......................................................... 427

Figura 267 – Testes Efectuados .................................................................................... 428

Lista de Figuras

xxxii Sistema de Telemetria aplicado a uma Plataforma Naval

Figura 268 – Representação de um dos routers utilizado para testes ........................... 428

Figura 269 – Janela inicial do NFTOOL ......................................................................... 431

Figura 270 – Treino da Rede Neuronal ......................................................................... 431

Figura 271 – Exportação do código MatLab .................................................................. 431

Figura 272 – Representação do código Matlab efectuado ............................................. 432

Figura 273 – Interface gráfica desenvolvida .................................................................. 433

Figura 274 – Previsão efectuada ................................................................................... 434

Figura 275 – Previsão efectuada (gráficos de treino) .................................................... 434

Figura 276 – Leitura do Datalogger utilizando o software BitMeter ................................ 471

Figura 277 – Leitura de 3 Arduinos utilizando o software BitMeter ................................ 471

Figura 278 – Leitura da webcam utilizando o software BitMeter .................................... 472

Figura 279 – Leitura de 1 Arduino + 1 Webcam + 1 Datalogger utilizando o software

BitMeter ......................................................................................................................... 472

Figura 280 – Dados obtidos no teste 1 em live utilizando o software BitMeter ............... 473

Figura 281 – Dados obtidos no teste 1 em stream utilizando o software BitMeter ......... 473







Sistema de Telemetria aplicado a uma Plataforma Naval xxxiii

LISTA DE TABELAS

Tabela 1 – Exemplos de sensores típicos e as suas saídas ............................................19

Tabela 2 – Exemplos de aplicações militares ..................................................................25

Tabela 3 – Exemplos de aplicações não militares ............................................................26

Tabela 4 – Características passíveis de configuração numa rede de sensores ...............27

Tabela 5 – Os sensores ontem e hoje .............................................................................28

Tabela 6 – Modelo de referência OSI ..............................................................................45

Tabela 7 – Modelo de referência TCP/IP .........................................................................46

Tabela 8 – Parâmetros das diferentes camadas físicas da norma IEEE802.11g .............58

Tabela 9 – Parâmetros físicos para diferentes cenários de comunicação ........................58

Tabela 10 – Representação da taxa efectiva IEEE 802.11 ..............................................61

Tabela 11 – Material adquirido para a constituição do sistema final .................................68

Tabela 12 – Algumas das características mais relevantes do firmware - DD-WRT ..........68

Tabela 13 – Gama de temperatura e limites de erro nos vários tipos de termopares

existentes ........................................................................................................................70

Tabela 14 – Pacotes obtidos no pedido de identificação e respectiva resposta ...............76

Tabela 15 – Relação entre modelo de Arduino e o microcontrolador utilizado .................78

Tabela 16 – Tabela comparativa entre os três modelos de microcontrolador utilizados ...78

Tabela 17 – Características apresentadas por um Arduino Duemilinove .........................79

Tabela 18 – Conteúdo do registo ADCSRA .....................................................................81

Tabela 19 – Conteúdo do registo ADCSRA .....................................................................81

Tabela 20 – Representação da velocidade de conversão teórica esperada .....................82

Tabela 21 – Inferências que se podem fazer pelas indicações luminosas presentes no

shield Ethernet .................................................................................................................83

Lista de Tabelas

xxxiv Sistema de Telemetria aplicado a uma Plataforma Naval

Tabela 22 – Dataq vs Arduino Duemilinove + shield Ethernet ......................................... 84

Tabela 23 – Vantagens e desvantagens da tecnologia microstrip ................................... 84

Tabela 24 – Requisitos para a antena direccional ........................................................... 85

Tabela 25 – Principais características do agregado (Experimental vs Simulado) ............ 88

Tabela 26 – Valores obtidos para os pinos 5V,3,3V e Vin do Arduino Duemilinove .......... 97

Tabela 27 – Valores do relógio de entrada do conversor A/D obtidos experimentalmente

...................................................................................................................................... 101

Tabela 28 – Resultados obtidos na leitura de 2 Arduinos (em simultâneo) utilizando um

browser ......................................................................................................................... 106

Tabela 29 – Resultados obtidos na leitura de 1 Datalogger utilizando o seu software

proprietário .................................................................................................................... 108

Tabela 30 – Número de canais analógicos máximos em função do protocolo de

transmissão escolhido ................................................................................................... 109

Tabela 31 – Resultados obtidos na leitura de 3 Arduinos utilizando um browser ........... 109

Tabela 32 – Resultados obtidos na leitura de 1 Webcam utilizando o seu software

proprietário .................................................................................................................... 111

Tabela 33 – Resultados obtidos na leitura de 1 Webcam, 1 Datalogger e 1 Arduino ..... 113

Tabela 34 – Resumo dos resultados obtidos experimentalmente .................................. 118

Tabela 35 – Tempos de conversão A/D obtidos experimentalmente ............................. 122

Tabela 36 – Taxas de amostragem obtidas dependendo do valor de prescaler ............ 122

Tabela 37 – Diferença entre a taxa de amostragem obtida experimentalmente. e a

teoricamente esperada .................................................................................................. 122

Tabela 38 – Tempos totais da aquisição e envio com diferentes taxas de amostragem e

baud rates ..................................................................................................................... 124

Tabela 39 – Taxas de amostragem obtidas na leitura e envio de dados por série ......... 124

Tabela 40 – Tempos totais da aquisição e envio por Ethernet....................................... 124

Tabela 41 – Taxas de amostragem obtidas na leitura e envio de dados por Ethernet ... 125

Tabela 42 – Taxas de amostragem obtidas na leitura, envio de dados por série e leitura

Matlab ........................................................................................................................... 125

Lista de Tabelas

Sistema de Telemetria aplicado a uma Plataforma Naval xxxv

Tabela 43 – Taxas de amostragem obtidas na leitura, envio de dados por Ethernet e

leitura Matlab ................................................................................................................. 125

Tabela 44 – Diferenças entre as taxas de amostragem finais por série (115 200) e

Ethernet ......................................................................................................................... 126

Tabela 45 – Resumo dos resultados obtidos ................................................................. 126

Tabela 46 – Configurações utilizadas nos testes efectuados à camera de alta-velocidade

...................................................................................................................................... 129

Tabela 47 – Dados obtidos pelo software OmniPeek em live na configuração de teste 1

...................................................................................................................................... 130

Tabela 48 – Dados obtidos pelo software OmniPeek em stream na configuração de teste

1 .................................................................................................................................... 130


...................................................................................................................................... 131


2 .................................................................................................................................... 132

Tabela 51 – Estimativa da taxa de transferência necessária nas condições de teste 1 e 2

...................................................................................................................................... 132


...................................................................................................................................... 133


3 .................................................................................................................................... 133


...................................................................................................................................... 134


4 .................................................................................................................................... 134

Tabela 56 – Estimativa dos dados que iriam circular na rede em 60 minutos no teste 1 e 2

...................................................................................................................................... 135

Tabela 57 – Frequências da norma IEEE 802.11g ......................................................... 159

Tabela 58 – Configurações de antenas ......................................................................... 164

Tabela 59 – Características pretendidas para a antena ................................................. 201

Lista de Tabelas

xxxvi Sistema de Telemetria aplicado a uma Plataforma Naval

Tabela 60 – Dados utilizadas na simulação 1 ................................................................ 202

Tabela 61 – Valores obtidos na simulação 1 ................................................................. 203









Tabela 70 – Parâmetros de dimensionamento .............................................................. 214

Tabela 71 – Valores para efectuar o adaptador de 325 para 50 ............................. 215

Tabela 72 – Valores para efectuar o adaptador de 325 para 100 ........................... 215



Tabela 75 – Parâmetros da simulação 1 ....................................................................... 216





Tabela 80 – Parâmetros da simulação .......................................................................... 232

Tabela 81 – Valores para efectuar o adaptador de 309 para 100 ........................... 232





Tabela 86 – Resultados obtidos .................................................................................... 238

Lista de Tabelas

Sistema de Telemetria aplicado a uma Plataforma Naval xxxvii

Tabela 87 – Parâmetros do dimensionamento ............................................................... 241



Tabela 90 – Parâmetros da simulação 1 ........................................................................ 242

Tabela 91 – Parâmetros da simulação 2 ........................................................................ 246

Tabela 92 – Valores obtidos variando a constante dieléctrica de um superstrato de

espessura 0,5 mm ......................................................................................................... 257

Tabela 93 – Valores obtidos variando a constante dieléctrica de um superstrato de

espessura 0,3 mm ......................................................................................................... 258

Tabela 94 – Valores obtidos variando o valor de Ls com Ws = 2 mm .............................. 260

Tabela 95 – Valores obtidos variando o valor de Ls com Ws = 4 mm .............................. 262

Tabela 96 – Quantidade de memória disponível em cada modelo de microcontrolador . 282

Tabela 97 – Utilização dada pelo Arduino (utilizador) aos diversos tipos de memória ... 283

Tabela 98 – Pinout disponível - Arduino Duemilinove .................................................... 284

Tabela 99 – Modos de configuração da referência analógica ........................................ 286

Tabela 100 – Condições possíveis ................................................................................ 295

Tabela 101 – Condições possíveis do parâmetro “modo” .............................................. 318

Tabela 102 – Conteúdo do registo ADCSRA ................................................................. 340

Tabela 103 – Conteúdo do registo ADCSRA ................................................................. 341

Tabela 104 – Valores possíveis de Clock de entrada no ADC ....................................... 341

Tabela 105 – Valore obtidos na conversão A/D ............................................................. 343

Tabela 106 – Combinações possíveis do registo ADCSRA ........................................... 376

Tabela 107 – Quantidades de memória disponíveis ...................................................... 379

Tabela 108 – Combinações possíveis (Registo ADCSRA)............................................. 382

Tabela 109 – Tempo de conversão A/D obtido .............................................................. 382

Tabela 110 – Taxa de amostragem obtida ..................................................................... 383

Tabela 111 – Tempo total dispendido (Cálculo FFT+ADC) ............................................ 385

Lista de Tabelas

xxxviii Sistema de Telemetria aplicado a uma Plataforma Naval

Tabela 112 – Tempo total dispendido para 6 entradas .................................................. 386

Tabela 113 – Lista de material e respectivo estado após utilização .............................. 403

Tabela 114 – Dados obtidos após calcular a respectiva média ..................................... 430

Tabela 115 – Resultados obtidos na previsão efectuada ............................................... 435

Tabela 116 – Dados utilizados no treino da rede neuronal ............................................ 454

Tabela 117 – Tempo apenas da conversão A/D de acordo com o seu factor de divisão -

Prescaler ....................................................................................................................... 455

Tabela 118 – Tempo de conversão A/D mais o envio através da instrução “Serial.print”

...................................................................................................................................... 456

Tabela 119 – Tempo de conversão A/D mais o envio através da instrução “Serial.println”

...................................................................................................................................... 456

Tabela 120 – Tempo de conversão A/D mais o envio através da instrução “Server.print”

...................................................................................................................................... 456

Tabela 121 – Tempo de conversão A/D + o envio através da instrução “Serial.print” + a

aquisição Matlab ........................................................................................................... 457

Tabela 122 – Tempo de conversão A/D + o envio através da instrução “Serial.println” + a


Tabela 123 – Tempo de conversão A/D + o envio através da instrução “Server.print” + a


Tabela 124 – Tempo médio da instrução “Server.print” com e sem pedido por um browser

...................................................................................................................................... 458

Tabela 125 – Tempo médio na aquisição por Matlab em série e TCP/IP ...................... 458

Tabela 126 – Tempo médio na instrução “Serial.print” e “Serial.println” - A ................... 458

Tabela 127 – Tempo médio na instrução “Serial.print” e “Serial.println” – B .................. 458

Sistema de Telemetria aplicado a uma Plataforma Naval xxxix

LISTA DE GRÁFICOS

Gráfico 1 – Saída vs Pressão diferencial .........................................................................72

Gráfico 2 – Coeficiente de reflexão teórico e obtido experimentalmente ..........................87



Gráfico 5 – Representação dos dois primeiros níveis de quantização num conversor A/D

ideal .................................................................................................................................97

Gráfico 6 – Representação gráfica das 100 amostras obtidas com um valor de tensão de

20 mV ..............................................................................................................................97

Gráfico 7 – Representação do erro de offset obtido .........................................................98

Gráfico 8 – Curva de conversão A/D obtida com um factor de prescaler de 2 ............... 100

Gráfico 9 – Comparação da curva de conversão A/D com um factor de prescaler de 2 e a

ideal ............................................................................................................................... 100

Gráfico 10 – Comparação da curva de conversão A/D com um factor de prescaler de 128

e a ideal ......................................................................................................................... 101

Gráfico 11 – Comparação da curva de conversão A/D com um factor de prescaler de 8 e

a ideal ............................................................................................................................ 102

Gráfico 12 – Comparação da curva de conversão A/D com um factor de prescaler de 4 e

a ideal ............................................................................................................................ 102

Gráfico 13 – Nível de sinal recebido .............................................................................. 164

Gráfico 14 – SNR ........................................................................................................... 165

Gráfico 15 – Capacidade do canal ................................................................................. 165

Gráfico 16 – Comparação de SNR entre routers ............................................................ 166

Gráfico 17 – Relação sinal ruído nos routers ................................................................. 168

Gráfico 18 - Nível de sinal recebido ............................................................................... 169

Lista de Gráficos

xl Sistema de Telemetria aplicado a uma Plataforma Naval

Gráfico 19 – Taxa de transferência ............................................................................... 169

Gráfico 20 – Tempos de latência ................................................................................... 170

Gráfico 21 – Coeficiente de reflexão teórico e o obtido experimentalmente................... 255

Gráfico 22 – Gráfico obtido variando a constante dieléctrica de um superstrato de

espessura 0,5 mm ......................................................................................................... 257


espessura 0,3 mm ......................................................................................................... 258


espessura 0,3 mm ......................................................................................................... 259

Gráfico 25 – Valores obtidos com o valor de Ls igual a + 1 mm e – 1 mm com Ws = 2 mm

...................................................................................................................................... 261

Gráfico 26 – Valores obtidos com o valor de Ls igual a + 5 mm e – 5 mm com Ws = 2 mm

...................................................................................................................................... 261

Gráfico 27 – Valores obtidos com o valor de Ls igual a 1 mm e 5 mm com Ws =

4 mm ............................................................................................................................. 262

Gráfico 28 – Variação do parâmetro S11 com a variação do tamanho do stub ............... 263

Gráfico 29 – Relação entre a largura do stub e frequência de ressonância ................... 263

Gráfico 30 – Relação entre o corte efectuado e o parâmetro S11 obtido ........................ 264

Gráfico 31 – Relação entre o corte e a frequência de ressonância ................................ 264

Gráfico 32 – Relação entre o corte e a largura de banda .............................................. 265

Gráfico 33 – Padrão de radiação da antena elaborada.................................................. 265

Gráfico 34 – Ganho Experimental vs Teórico da antena elaborada ............................... 266

Gráfico 35 – Curva de conversão A/D obtida para um factor de prescaler de 2 ............. 469

Gráfico 36 – Curva de conversão A/D obtida para um factor de prescaler de 4 ............. 470

Gráfico 37 – Curva de conversão A/D obtida para um factor de prescaler de 16 ........... 470

Sistema de Telemetria aplicado a uma Plataforma Naval xli

LISTA DE ABREVIATURAS

et al. (et aliae) : e outros (para pessoas)

e.g. (exempli gratia): por exemplo

etc.(et cetera): e outros (para coisas)

i.e. (id est): i.e.

sui generis único no seu género

“Não se pode ensinar tudo a alguém, pode-se

apenas ajudá-lo a encontrar por si mesmo.”

Galilleu Galilei

Sistema de Telemetria aplicado a uma Plataforma Naval 1

1. CAPÍTULO I

INTRODUÇÃO

1.1 ENQUADRAMENTO

No seu plano de actividades operacionais, a Marinha de Guerra Portuguesa (MGP)

participa em exercícios nacionais e internacionais em que é efectuado o disparo de

mísseis contra alvos reais. Durante este tipo de prática podem e devem ser efectuadas

algumas questões, tais como:

O que acontece no interior dos compartimentos durante e após o embate de um

míssil?

Quais as suas implicações nos compartimentos adjacentes ao do impacto?

Em caso da presença humana num compartimento, quais os efeitos que se

podem esperar no corpo humano?

Serão os procedimentos operacionais utilizados, os mais correctos para este tipo

de fenómeno?

Quanto tempo demoraria a propagação dos efeitos provenientes do embate de um

míssil entre os compartimentos adjacentes?

Estas questões, tal como muitas outras que poderiam ser também elaboradas,

demonstram-se de uma grande importância no contexto técnico-militar, não se lhe dando

muitas vezes a devida atenção. Ao ser respondidas, podem trazer enormes benefícios,

revelando informações importantes, quer para o desenvolvimento de conhecimentos no

âmbito da construção naval, mais especificamente no comportamento estrutural dos

navios, quer para o fabricante do armamento conhecer o real poder destrutivo da sua

arma e até mesmo para se conhecer o efeito no corpo humano. Podendo mesmo originar

uma doutrina a ser utilizada para maior segurança das pessoas embarcadas nas

plataformas navais e, assim, contribuir para o desenvolvimento da doutrina naval.

Para encontrar as respostas a estas questões é então necessário conhecer os

fenómenos resultantes do impacto de um míssil numa plataforma naval. Pelo que surge a

necessidade de fazer telemetria, utilizando para esse efeito uma rede de sensores –

sensores de pressão, temperatura, acelerómetros - e efectuar captura de vídeo, que


2 Sistema de Telemetria aplicado a uma Plataforma Naval

possibilite a recolha de dados e imagem no interior e exterior do alvo para posterior

análise, bem como a sua transmissão.

Deve-se assegurar que a transmissão de dados é efectuada em tempo real, o que se

apresenta como uma tarefa árdua, devido à situação particular em estudo. Por outro lado,

a análise dos dados não deve ser descuidada, uma vez que é essencial para validar as

conclusões retiradas.

O tema desta dissertação de mestrado surge no seguimento de um pedido da Direcção

de Navios (DN) – Órgão de Direcção Técnica da Marinha – à Escola Naval (EN), onde

solicitou o desenvolvimento do sistema atrás descrito. Mais especificamente, aplicando-o

ao estudo do impacto de disparos de mísseis do tipo Seasparrow1, utilizados pela MGP

contra alvos reais. Existindo assim o interesse actual da MGP no desenvolvimento de um

sistema baseado em telemetria que possa monitorizar os fenómenos decorrentes do

impacto de um míssil numa plataforma naval.

A palavra telemetria, conceito no qual se baseia este estudo, tem origem Grega e resulta

da conjugação da palavra tele (= remota) com a palavra metron (= medida).

Normalmente, é associado à implementação de um sistema que permita fazer o controlo

de parâmetros (metron) de uma forma remota (tele), através de uma tecnologia de

comunicação sem fios. Mas a comunicação de rede sem fios é apenas uma parte de todo

um sistema, não podendo descuidar-se a implementação necessária da rede de sensores

e a posterior análise de todos os dados obtidos.

No âmbito da comunicação sem fios - wireless -, o IEEE2 estabeleceu a norma IEEE

802.11 (Olexa, 2005, p. 7-13), que determina um padrão a seguir neste tipo de rede. Esta

norma encontra-se compilada num standard3 elaborado pelo IEEE, definindo assim todo

o seu conceito de operação e as suas principais características.

Uma das versões disponíveis da norma IEEE 802.11 é designada por IEEE 802.11g4

(Carney, 2002, p.1-3), sendo claro que a letra (neste caso a letra g) define a versão da

norma a considerar. A última destas normas é largamente aplicada a nível mundial, já

1 Seasparrow é um míssil superfície – ar com um alcance máximo de 10 milhas náuticas (≈19 km),

estes equipam as fragatas das classes Vasco da Gama e Bartolomeu Dias pertencentes à Marinha de Guerra Portuguesa.

2IEEE é o acrónimo para Instituto de Engenheiros Electricistas e Electrónicos (Institute of Electrical

and Electronics Engineers), que nos dias de hoje é normalmente referenciada apenas pelo seu acrónimo IEEE. 3 O principal objectivo da elaboração de um standard é permitir que vários equipamentos que

corram o mesmo protocolo possam ser ligados entre si, independentemente do seu fabricante. 4 IEEE 802.11g é a norma utilizada para especificar os requisitos para dispositivos que

possibilitam uma comunicação até 54 Mbps na faixa dos 2,4 GHz.

Capitulo I – Introdução


que tem enormes potencialidades na aplicação doméstica, podendo esta tecnologia ser

adquirida em qualquer loja comum (o que é sem dúvida um factor muito importante a ter

em conta).

Nos dias de hoje, existe já um draft5 da norma IEEE 802.11n, que permite, teoricamente6,

taxas de transferência de dados aproximadamente 2,6 vezes maiores do que a sua irmã,

a IEEE 802.11g. A IEEE 802.11n, apesar de já comercializada, não está tão largamente

difundida e a sua utilização não é tão usual como a IEEE 802.11g, pelo que para a

realização desta dissertação, se irá considerar esta última norma, de forma a ter um

melhor acesso aos componentes tecnológicos implicados. O que não implica que o

estudo corrente não possa ser também aplicado na utilização da norma IEEE 802.11n,

devendo, apenas, para tal efectuar as devidas adaptações.

A norma IEEE 802.11g pode caracterizar-se nos dias de hoje pela necessidade de um

investimento diminuto (componentes de baixo custo) e pelos seus componentes

tecnológicos estarem constantemente em evolução. A necessidade de conseguir um

desempenho melhor e mais rápido leva à evolução constante deste tipo de normas, bem

como as características da tecnologia disponível no mercado para a sua implementação.

Ao utilizar uma norma para estabelecer um padrão de comunicação entre o hardware e

software disponível no mercado, é possível empregar material de diferentes fabricantes e

proceder mais rapidamente ao upgrade, modificação e/ou reparação dos sistemas a

utilizar para efectuar telemetria. Como norma comercial, a IEEE 802.11g não está

desenhada directamente para aplicação em ambiente bélico, nem terá tido

desenvolvimento visando esse objectivo, tornando-se necessário neste projecto encontrar

a melhor forma de a implementar, dadas as especificidades do fenómeno de estudo.

Como foi referido anteriormente, no desenrolar desta introdução, existem outros factores

a ter em conta, não só a comunicação wireless a efectuar. A criação de uma rede de

sensores, normalmente associada ao conceito de multisensor data fusion7 (Liggins, Hall e

Llinas, 2009, p. 1 e 2), mostra-se de grande importância. Neste conceito é necessário

reunir a informação de variadíssimos tipos de sensores, tendo de saber precisamente a

sua localização, pois para fazer a correcta interpretação dos valores obtidos essa é uma

das condições vitais. Outra condição que se revela de grande importância, é fazer com

5 Ao utilizar a expressão draft espera dar-se uma ideia de algo que ainda está em

desenvolvimento, apesar de se poder encontrar já em utilização. 6 É muito importante ter em consideração que é impossível obter os valores teoricamente

esperados, servindo estes para ter uma ideia da gama de valores que se poderá obter. 7 Multisensor data fusion tem como objectivo efectuar a fusão de dados de variadíssimos

sensores, normalmente com o objectivo de retratar um fenómeno específico.



que a arquitectura da localização dos sensores seja fiável, ou seja, é necessário garantir

que a sua arquitectura assenta num modelo robusto e eficaz, fazendo com que os dados

sejam transmitidos de forma eficiente e em tempo real. Por fim, a fiabilidade é o que

devemos procurar não só na localização dos sensores, mas na elaboração global do

sistema em questão.

A comunicação entre o hardware de recolha de dados (Datalogger), que vai possibilitar

adquirir os dados provenientes dos sensores, e o módulo de envio vai ser efectuada

utilizando o protocolo IEEE 802.3 (Ethernet). Esta norma permite teoricamente taxas de

transferência de dados de aproximadamente 100 Mbps, havendo já a Gigabit Ethernet

que permite taxas de transferência de aproximadamente 1 Gbps (Edwards e Bramante,

2009, p. 249). Este último protocolo vai ser utilizado apenas para transmissão de imagens

de vídeo, utilizando uma camera de alta velocidade.

Uma das dificuldades de implementação de uma rede de sensores, utilizando um

protocolo de rede, prende-se com a escolha da melhor arquitectura a utilizar. Podem no

entanto surgir também outras dificuldades como: a redundância a utilizar, os gastos

energéticos da rede, o número de pacotes perdidos, erros nos pacotes enviados na rede

entre muitos outros factores a ter em conta. Estes devem ser abordados tendo em conta

o objectivo final do sistema e situação particular a que se destinam, devendo garantir um

rendimento mínimo aceitável.

Como o afundamento de plataformas navais utilizando mísseis – cenário de aplicação do

sistema a elaborar – não é comum em telemetria, existe a necessidade de conseguir

determinar a gama de valores que se pretende medir e, por consequência, qual o tipo de

sensor indicado para o espectro de valores a observar, pois um sensor adequado para

uma gama muito grande de valores não possibilita uma grande resolução a pequenas

variações. Para retratar um fenómeno com algum rigor é necessário ter uma resolução

mínima, tendo em conta o caso específico em estudo. Assim esta questão terá de ser

respondida ao longo deste trabalho em virtude de definir a gama de operação dos

sensores em função do valor máximo a medir e da resolução pretendida. Pelo que será

necessário recorrer à Direcção de Navios e, por conseguinte, a alguns especialistas em

armamento para saber que valores esperar e, assim, construir um sistema mais

adequado. Ou seja, quanto mais adaptado ao nosso cenário de estudo melhor em termos

de qualidade dos dados obtidos.

Após uma breve descrição do sistema pretendido para o cenário em causa, da

importância das redes de sensores, da importância da análise dos dados e de ter a noção



dos valores esperados (temperatura, pressão entre outros), é importante também referir

que o objectivo deste trabalho é construir um sistema de custo reduzido (normalmente

designado por off-the-shelf8), devendo demonstrar-se uma solução robusta, capaz de

efectuar a recolha dos dados em tempo real e de forma fiável. Posteriormente, e após o

seu correcto planeamento e construção, não poderá haver lugar a falhas e dever-se-á

submeter o sistema a diversas condições de teste, com vista a aferir o seu

comportamento em situações reais.

No sentido de responder da melhor forma à solicitação da DN, a problemática descrita

anteriormente deu origem a duas teses de mestrado complementares. Uma delas

centrou-se na configuração do sistema de transmissão de dados via wireless e a

segunda, que aqui se apresenta, centrou-se na configuração do sistema de aquisição de

dados através do protocolo IEEE 802.3 e correspondente envio por wireless utilizando o

protocolo IEEE 802.11g.

Finalmente, deve referir-se que com vista a melhor cumprir os objectivos delineados,

seguiu-se neste estudo um método científico dividido em três fases – explorativa,

analítica e conclusiva. Na primeira fase estruturou-se o projecto, definindo os limites do

problema em estudo, as questões de investigação, os objectivos, os conhecimentos e as

competências a adquirir, as hipóteses a estudar para se conseguir um maior rendimento

do sistema construído e as metodologias a seguir. Na segunda fase, efectuou-se a

revisão do estado da arte, que permitiu fundamentar a escolha dos equipamentos a

adquirir, bem como a interpretação dos resultados dos seus testes. Após adquirir

sensores, camera de alta-velocidade, camera IP e equipamento de aquisição de dados,

estes foram testados de forma a garantir que se adaptariam da melhor forma aos

requisitos exigidos pela especificidade do cenário no qual o sistema se viria a aplicar. Na

terceira e última fase, procedeu-se à confirmação das hipóteses, verificação dos

objectivos alcançados ao cruzar os resultados dos testes com os conhecimentos

adquiridos, culminando nas conclusões e recomendações finais.

8 Nome atribuído ao material - hardware ou software - já desenvolvido e com venda livre ao

público em qualquer loja física ou virtual (e.g. loja na internet).



1.2. ORGANIZAÇÂO DA TESE

Esta tese está organizada em seis capítulos distintos, que procuram evidenciar todo o

trabalho que foi elaborado acerca desta temática.

No capítulo I além de ser efectuado um enquadramento ao tema de estudo é delineada a

linha de acção deste estudo, referindo assim as diversas fases que foram seguidas neste

estudo.

No capítulo II é efectuada uma revisão do estado da arte sobre redes de sensores e

sobre aquisição de dados, dando especial ênfase aos tipos de erros existentes nos sinais

adquiridos por sensores e aos erros introduzidos pelo conversor A/D. Neste capítulo é

também dedicado um sucapítulo ao teorema de amostragem, subcapítulo este que se

demonstra de enorme importância no cenário e estudo.

No capítulo III é efectuada uma revisão do estado da arte sobre o conceito de telemetria

e sobre os protocolos de rede utilizados (IEEE 802.3 e IEEE 802.11g), proporcionando

assim uma base teórica para compreender o seu funcionamento. Neste capítulo também

é dedicado um subcapítulo às formas de analisar a performance de uma rede,

proporcionando assim uma base teórica a algumas das ferramentas utilizadas nos testes

efectuados.

O capítulo IV é totalmente dedicado ao material utilizado, especificando assim os seus

princípios de funcionamento. Neste capítulo também são explicadas as modificações

efectuadas ao material adquirido e algumas das características mais importantes de cada

equipamento.

No capítulo V são abordados os testes efectuados para quantificar qual a performance

apresentada pelos diversos constituintes do sistema, procurando juntamente com a

informação que se encontra em apêndice chegar às conclusões que se encontram

descritas no capítulo VI e último. Neste último capítulo é efectuada uma conclusão a todo

o trabalho desenvolvido, indicando também as limitações encontradas e algumas

sugestões para trabalho futuro.

1.2.1. METODOLOGIA UTILIZADA

O problema central deste estudo baseia-se na necessidade de efectuar telemetria, de

forma a conhecer os fenómenos que ocorrem durante o afundamento de uma plataforma

naval quando atingida por mísseis do tipo Seasparrow. Assim definiu-se um método



científico que garantisse a maior fiabilidade e conclusões válidas, estruturado de forma a

elaborar um sistema off-the-shelf de baixo custo com o maior rendimento possível, que

seja capaz de transmitir dados no contexto em estudo.

O método científico utilizado divide-se em três fases diferentes tendo cada uma delas

uma diferente função no estudo (Sarmento, 2008, p. 7-9.) A primeira fase designou-se

como explorativa, no seu âmbito definiu-se o problema em estudo, as questões de

investigação, os objectivos, os conhecimentos e competências a adquirir, as hipóteses a

estudar para se conseguir um maior rendimento do sistema construído e as metodologias

a seguir nas diferentes fases do estudo. Na segunda fase - fase analítica -, procedeu-se à

recolha de dados, através de uma metodologia de investigação explorativa no que

concerne aos fundamentos teóricos e com uma metodologia de investigação

demonstrativa, que permite o desenvolvimento de um sistema através do

desenvolvimento de técnicas, ferramentas e materiais mais adequados. Na terceira fase,

a fase final, designada por conclusiva, procedeu-se à confirmação das hipóteses,

verificação dos objectivos alcançados que culminaram nas conclusões e recomendações.

Figura 1 – Esquema design do método científico

1.2.2. FASE EXPLORATIVA

Nesta fase, como já foi referido estruturou-se a questão em estudo nesta dissertação de

mestrado, definindo o problema, as questões relevantes e os objectivos. Foram, ainda,

definidos os conhecimentos e competências a adquirir, bem como as hipóteses a

considerar (Sarmento, 2008, p. 7).

Fase Explorativa

Fase Analítica

Fase Conclusiva



Este estudo surge na sequência de uma solicitação de um órgão técnico da Marinha -

Direcção de Navios - à Escola Naval, onde sugeria o desenvolvimento de um sistema

capaz de efectuar telemetria para recolha de dados durante o afundamento de uma

plataforma militar naval quando atingida por mísseis Seasparrow, que permitisse

conhecer os fenómenos que surgem no interior do navio, em termos de variação da

temperatura, pressão e movimentação em torno dos eixos axiais sofrida pela plataforma

naval.

Assim esta temática deu origem a dois estudos, uma vez que o sistema se basearia na

aquisição de dados através de sensores e a sua transmissão por wireless - com a

configuração visível na Figura 2. Um dos estudos centralizou-se no sistema de

transmissão de dados através de comunicação wireless a grandes distâncias e o estudo

que aqui se apresenta desenvolveu a configuração do sistema de aquisição de dados

adequado ao contexto do estudo - sensores de temperatura, pressão e acelerómetros,

camera de alta velocidade, webcams e equipamento de aquisição de dados -, que

permitisse através de equipamentos off-the-shelf de baixo custo construir um sistema

com elevado rendimento.

Sensores

Sensores

Sensores

Câmara

Datalogger

Router Router

Wireless Bridge Link

Computador

Navio Alvo Navio de Monitorização

Redundância

Figura 2 – Representação ideal do sistema final a desenvolver

Assim, para responder ao objectivo principal desta dissertação de mestrado foram

colocadas diversas questões, entre elas:

Qual a possibilidade de efectuar telemetria no afundamento de uma plataforma

naval, utilizando equipamento off-the-shelf?

Quais serão os parâmetros a medir?



Qual a tecnologia a utilizar nas ligações entre Datalogger e módulo wireless?

Qual a melhor tecnologia e protocolo a utilizar na ligação wireless?

Qual o equipamento de aquisição de dados com a melhor qualidade preço?

O equipamento de aquisição adquirido tem uma taxa de amostragem

suficientemente elevada para retratar o fenómeno em estudo?

Qual o material a adquirir para o sistema - sensores, camera de alta velocidade,

equipamento de aquisição de dados - tendo em vista as condições sui generis?

Estes permitem teoricamente retratar o fenómeno com exactidão?

Será que a sua temperatura de operação do sistema se enquadra no fenómeno a

monitorizar?

Qual o comportamento do Arduino Duemilinove como conversor A/D?

Qual a taxa de transferência necessária para o envio de dados provenientes de

equipamento de aquisição de dados?

Quantos equipamentos poderão estar ligados em simultâneo, tendo em vista a

utilização de um protocolo IEEE 802.3 e transmissão por wireless – IEEE 802.11g

– numa fase final?

Existe largura de banda suficiente à distância operacional considerada

(aproximadamente de 6 milhas náuticas) para a transferência de imagens pelas

cameras adquiridas – camera de alta-velocidade e webcams?

Deverá existir uma redundância à transmissão wireless, alimentação dos

equipamentos e ligações entre equipamentos (topologia de rede redundante)?

Baseando esta análise em valores reais o material adquirido é adequado às

condições sui generis do fenómeno a registar?

Definiu-se, ainda, os conhecimentos e competências a adquirir para responder da melhor

forma aos objectivos definidos anteriormente:

Fundamentos teóricos sobre redes de sensores;

Erros na resposta proveniente de sensores;

Importância da calibração de sensores;

Aplicações actuais das redes de sensores em ambiente militar;

Constituintes e características habituais de uma rede de sensores;

Necessidades de operação mais comuns em redes de sensores;

Fundamentos de conversão de analógico para digital (conversão A/D);

Gama de valores de entrada/resolução de um conversor A/D;

Erros associados à conversão de analógico para digital;



Conceito de taxa de amostragem e teorema da amostragem;

Conceito básico de telemetria;

Análise do protocolo IEEE802.3 e IEEE 802.11g;

Formas de analisar eficazmente a performance de uma rede, nomeadamente o

uso de software apropriado para o efeito;

Utilização de sensores em rede;

Conhecimentos teóricos e práticos sobre os sensores e hardware de aquisição a

adquirir para o sistema de aquisição de dados;

Conhecimentos de programação em linguagem Matlab, nomeadamente na

aquisição de dados utilizando comunicação série e TCP/IP;

Conhecimentos de programação e operação com a placa de desenvolvimento

Arduino.

Na revisão do estado da arte - no âmbito dos tópicos anteriores - de forma a retirar

conclusões válidas, definiu-se uma metodologia qualitativa, onde se pretende conhecer o

processo, através de análise documental de registos organizacionais, relatórios,

normativos, estudos e outras publicações (Sarmento, 2008, p. 5). Podendo assim

construir uma base teórica que sustente as hipóteses, que de seguida se apresentam.

Nesta fase inicial de estruturação, definiram-se hipóteses a validar através de testes aos

equipamentos adquiridos, recorrendo a uma metodologia demonstrativa, foi possível

verificar se o sistema de aquisição de dados escolhido se adequa ao cenário em questão,

através da exploração das ferramentas e materiais a utilizar:

Utilização de Arduino em substituição do Datalogger Dataq DI -710-EL, como

ferramenta de aquisição de dados provenientes dos sensores, considerando a

dicotomia qualidade/preço;

Determinar quais as larguras de banda dos equipamentos adquiridos -

equipamentos de aquisição e cameras -, de forma a garantir que a largura de

banda máxima das ligações Ethernet e wireless a utilizar não são excedidas,

comprometendo assim o sistema;

Definir se a utilização do software de aquisição de dados Matlab se adequa à

situação de estudo;

Determinar se é possível efectuar comunicação a 6 milhas náuticas com o

equipamento adquirido;

Determinar como a posição relativa entre as duas antenas adquiridas pode

influenciar a transmissão;



Utilização do sistema desenvolvido num cenário real, ou seja, analisar a

performance do sistema desenvolvido num caso real.

Figura 3 – Esquema design fase explorativa

1.2.3. FASE ANALÍTICA

Nesta segunda fase do estudo, designada como analítica, concretizou-se o definido na

fase anterior, no que concerne à revisão do estado da arte e à confirmação das hipóteses

através de testes aos equipamentos escolhidos com base nas competências adquiridas

durante a revisão do estado da arte (Sarmento, 2008, p. 7 e 8).

Após a concretização da revisão do estado da arte e já com competências adquiridas,

procedeu-se à escolha da tecnologia, do material e das ferramentas necessárias para

concretizar o sistema de aquisição de dados. Escolheram-se então as tecnologias

wireless - IEEE 802.11g - para transmissão de dados a longas distâncias e Ethernet -

IEEE 802.3 - para aquisição de dados a partir dos sensores, camera de alta velocidade,

equipamentos de aquisição de dados – Arduino e Datalogger e software de aquisição de

dados. Assim baseou-se a escolha na contraposição entre os parâmetros presentes nas

características técnicas e os que se sabiam necessários para o sistema de aquisição de

dados funcionar no contexto.

A tecnologia wireless, aqui escolhida para a transmissão de dados a uma longa distância,

ou seja, navio monitorizado e estação de monitorização deve a sua selecção ao facto de

estar largamente difundida nas utilizações domésticas e ser comercializada a baixo custo.

Por sua vez, a tecnologia Ethernet foi escolhida para a transmissão dos dados para a

unidade de transmissão devido à sua elevada interoperabilidade com a tecnologia

wireless escolhida, o seu baixo custo e grande flexibilidade de utilização nos vários

contextos.

Fase Explorativa

Problema

Questões Relevantes

Objectivos

Conhecimentos a Adquirir

Metodologias a Utilizar nas Fases Seguintes



No que concerne aos equipamentos de aquisição de dados, optou-se por adquirir dois

diferentes – com preços e parâmetros técnicos distintos. Assim, adquiriu-se o Arduino

Duemilinove e o Datalogger Dataq DI-710-EL, cujos custos de aquisição são bastante

díspares, bem como as suas taxas de amostragem, quantidade de entradas analógicas

entre outros parâmetros. Contudo ambos partilham contextos como o facto de conseguir

uma ligação Ethernet - IEEE.802.3, sendo que no Arduino Duemilinove ainda é

necessário recorrer a um shield Ethernet (Ver subcapítulo 4.3.3.), com vista a dar-lhe esta

potencialidade. Embora se soubesse à partida que o Datalogger adquirido possuía

características técnicas que se adaptavam mais ao sistema pretendido, o seu preço

elevado punha em causa o objectivo de construir um sistema de baixo custo. Pelo que se

adquiriu também o Arduino, com características técnicas mais modestas, mas que em

termos monetários era bastante mais apetecível, baixando grandemente o custo geral do

sistema. Perante esta dualidade entre equipamentos, foi necessário realizar testes que

permitissem assegurar que o equipamento escolhido fosse o mais viável no que concerne

à relação qualidade/preço e garantisse o rendimento necessário.

Por final, escolheram-se os sensores a utilizar, bem como a camera de alta-velocidade e

cameras IP (webcams). Dos disponíveis no mercado, optou-se por aqueles que com base

nas suas características técnicas permitissem medir temperatura e pressão, filmar e

quantificar a movimentação em torno dos três eixos axiais dos fenómenos espectáveis na

situação específica do estudo, tendo em conta a relação entre a gama de valores

mensuráveis pelos respectivos sensores e o seu custo.

Seguidamente, de forma a garantir que a performance do material adquirido correspondia

às suas especificações técnicas e para definir parâmetros não quantificados, optou-se

por efectuar testes, que permitiram também responder às hipóteses colocadas na fase

anterior.

Para a aquisição e tratamento da informação durante os testes, foi necessário encontrar

dois softwares distintos. Para a análise do tráfego de rede, consideraram-se dois

softwares do tipo packet sniffer: Wireshark e OmniPeek (ver subcapítulo 3.6.). Contudo

devido à sua capacidade de elaborar relatórios estatísticos, autonomamente, sobre os

dados recolhidos, permitindo uma mais fácil análise através de gráficos e tabelas, foi

utilizado maioritariamente o software OmniPeek. Por sua vez, para possibilitar algum

tratamento da informação foi escolhido o software BitMeter, devido à sua capacidade

para elaborar de forma gráfica relatórios estatísticos de parâmetros da rede,

nomeadamente, sobre os parâmetros de download e upload utilizados durante a ligação.



Procurou-se também efectuar testes para decidir entre a utilização do Datalogger ou do

Arduino, o que permitiu através dos valores encontrados verificar se o Arduino pode

substituir o Datalogger adquirido, como solução mais em conta monetariamente.

1.2.3.1. 1º TESTE

Efectuar a caracterização da curva de conversão A/D de um Arduino Duemilinove,

segundo a metodologia definida no subcapítulo 5.2. Este teste procura assim demonstrar

e quantificar experimentalmente os erros existentes na conversão A/D, podendo estes

influenciar a fiabilidade dos resultados.

1.2.3.2. 2º TESTE

Determinar a taxa de transferência necessária para a camera IP e dos equipamentos de

aquisição – Arduino e Datalogger – durante a aquisição de dados provenientes de

sensores, de forma a garantir que a taxa de transferência máxima teórica do protocolo

IEEE 802.3 e IEEE 802.11g não é excedida, comprometendo o sistema – subcapítulo 5.3.

1.2.3.3. 3º TESTE

Este teste consistiu na determinação da taxa de amostragem de um Arduino Duemilinove

(transmissão de dados por série e Ethernet) recorrendo ao software de aquisição Matlab.

De modo a definir o mais adequado aos parâmetros necessários para o melhor

rendimento do sistema, segundo a metodologia apresentada no subcapítulo 5.4.

No que concerne ao software utilizado, escolheu-se, à partida, como ferramenta de

trabalho o Matlab. Já que se revela um software de aquisição com grande capacidade de

processamento matemático e com maior afinidade com o utilizador. Assim, no sentido de

comprovar a sua adequabilidade, realizaram-se também testes.

Este teste permite, de acordo com o descrito no subcapítulo 5.4. Definir a taxa de

amostragem ao nível do utilizador, i.e., o tempo gasto na aquisição de dados, no envio e

na leitura dos mesmos por um computador portátil.

1.2.3.4. 4º TESTE

Este teste consistiu na determinação da largura de banda utilizada pela camera de alta-

velocidade, tentando assim aferir qual seria a necessária e como as modificações nos

seus parâmetros de operação afectam esta variável – subcapítulo 5.5.

Este teste teve lugar na carreira de tiro da Escola Naval, tendo como objectivo secundário

filmar com sucesso o disparo de um atirador.



1.2.3.5. 5º TESTE

Este teste consistiu em testes ao alcance da antena Omnidireccional adquirida na Base

aérea do Montijo e recorrendo a embarcações da Escola Naval, verificando assim se esta

tinha o alcance e a largura de banda pretendidos – apêndices A e B.

1.2.3.6. 6º TESTE

Este teste consistiu em medir os parâmetros de saída dos routers adquiridos (e.g.

potência transmitida) e o coeficiente de reflexão das antenas omnidireccionais adquiridas

recorrendo a aparelhos de medição da GOAME9 – apêndices A e B.

1.2.3.7. 7º TESTE

Este teste consistiu na montagem de um sistema de telemetria durante um exercício de

disparo de mísseis MILAN, procurando assim comprovar a possibilidade de utilização de

um sistema de telemetria com material off-the-shelf – apêndice E.

1.2.3.8. 8º TESTE

Este teste consistiu na elaboração de uma rede neuronal que possibilitasse aferir como a

posição relativa entre as antenas provenientes dos routers podia influenciar o

comportamento da ligação wireless – apêndice G. Este estudo é importante pois no

cenário de estudo ambas as plataformas estão sujeitas às condições de mar existentes,

ou seja, procurou-se assim quantificar como os balanços existentes influenciam os

parâmetros de comunicação.

Finalmente, procedeu-se à interpretação dos resultados experimentais verificados nos

testes descritos anteriormente. Pôde concluir-se então que com a execução destes testes

se garantiu neste estudo uma melhor interpretação do rendimento do sistema, tendo em

conta o fenómeno a medir e o material utilizado, conseguindo identificar falhas

possibilitando uma maior compreensão do sistema. Procurou-se também interpretar o

funcionamento da camera de alta-velocidade verificando se a mesma se adequaria à

velocidade a que o impacto do míssil se verifica.

9 Grupo Oficinal de Apoio ao Material Electrónico, divisão técnica pertencente ao Arsenal do

Alfeite.



Figura 4 – Esquema design fase analítica

1.2.4. FASE CONCLUSIVA

Nesta última fase, confrontou-se os conhecimentos e competências adquiridos durante a

revisão do estado da arte com os resultados dos testes práticos efectuados. Assim,

através da discussão dos resultados, confirmaram-se as hipóteses colocadas na fase

explorativa e verificaram-se os objectivos alcançados, dando então origem às conclusões

e recomendações deste estudo, bem como a sugestões para futuras investigações

(Sarmento, 2008, p. 8).

Figura 5 – Esquema design fase conclusiva

Fase Analítica

Revisão do Estado da Arte

Escolha de material e software a utilizar

no sistema e nos testes a efectuar

Testes com Material Adquirido

Confronto entre conhecimentos adquiridos e resultados dos testes

Confirmação das hipóteses

Verificar Objectivos Alcançados

Conclusões e Recomendações

Fase Conclusiva



1.3. CONTRIBUIÇÕES DA TESE

O trabalho efectuado procurou colmatar, como foi referido anteriormente, uma

necessidade da Marinha de Guerra Portuguesa. Esta levou a que fossem aplicadas

ferramentas já existentes, mas não directamente vocacionadas para aplicação neste tipo

de problemas.

A principal contribuição da tese foi a interligação de equipamento de baixo custo

disponível comercialmente em lojas de e.g. centros comerciais, configurando-o e

adaptando-o para que seja possível efectuar a monitorização do impacto de mísseis em

plataformas navais. Nas situações em que o equipamento adquirido não apresentava o

rendimento esperado, e a obtenção de outro equivalente mas com capacidades

superiores se tornava bastante dispendiosa enveredou-se pela elaboração própria (e.g.

antena microstrip desenhada e fabricada).

O desenvolvimento deste trabalho contribuiu também para a divulgação do nome da

Escola Naval através das participações em conferências e colóquios, em que foi exposto

o trabalho desenvolvido nesta área.


2. CAPÍTULO II

REDES DE SENSORES E AQUISIÇÃO DE DADOS

2.1. INTRODUÇÃO

Nos dias que correm, em que vivemos claramente numa era de informação, os dados são

adquiridos e tratados muitas vezes em tempo real. Este tipo de tratamento de dados

reveste-se de grande importância, sendo impulsionado pelo enorme avanço tecnológico

na capacidade de processamento de dados existente actualmente.

Deste avançar tecnológico surgiu a famosa lei de Moore, através da qual o presidente da

Intel Corporation10, Gordon Moore, fez uma previsão sobre a evolução do poder de

computação presente nos chips produzidos pela sua empresa em 1965. Esta previsão,

que veio a confirmar-se, afirmava que este iria aumentar em 100% a cada 18 meses pelo

mesmo custo. Curiosamente, essa tendência ainda se verifica nos dias de hoje (Bell,

Gray e Szalay, 2006, p. 1).

A grande facilidade de aquisição e montagem de sensores verificada nos dias de hoje e

os preços bastante aceitáveis destes, faz com que exista a possibilidade de efectuar um

estudo prático neste tipo de temáticas. Esta análise prática permite fazer um estudo mais

fiável do seu desempenho, pois contempla variáveis externas que muitas vezes não se

conseguem modelar matematicamente com a exactidão necessária.

Nos próximos subcapítulos vão ser abordados temas relacionados com as redes de

sensores – calibração, tipos de erros, aplicações actuais, constituintes, características e

sobrevivência – e temas relacionados com a recolha de dados – conversão de analógico

para digital, gama de valores de entrada e resolução, erros e uma abordagem ao teorema

da amostragem.

10

Integrated Electronic Corporation é uma empresa multinacional de origem Americana, normalmente designada apenas por Intel.



2.2. REDES DE SENSORES

Em Agosto de 1999, a revista Business Week11, apelidou a tecnologia das redes de

sensores (Networked sensor technology) como sendo uma das vinte e uma tecnologias

mais importantes para o século XXI (Week, 1999, p. 78-167). Numa fase em que a

mudança de século levou a inúmeras reflexões, possibilitando assim uma nova imagem

sobre o futuro tecnológico.

Num Mundo que se caracteriza cada vez mais pela vontade de fazer com que exista uma

capacidade de resposta autónoma por parte dos sistemas electrónicos (procurando dotar

os sistema com inteligência), fazendo com que estes sintam os estímulos externos

provenientes do Mundo exterior - sensores - e actuem em conformidade. Mas mais do

que obter valores provenientes de sensores, geralmente resultantes de grandezas cuja

medição se baseia em variações de tensão ou corrente, deve-se prezar a qualidade de

informação obtida a partir dos dados. Desta preocupação surge a expressão garbage in,

garbage out - atribuída a George Fuechsel, pertencente à IBM12 (Smith, 2010) -, que

traduz o que muitas vezes acontece no tratamento de dados, i.e., se os dados que se

estão a tratar são lixo, então também a informação resultante será lixo sem qualquer

fiabilidade

Para melhor conceber as diferentes fases deste estudo, é importante definir o que é um

sensor, fazendo a distinção concreta entre transdutor e sensor, pois são conceitos

relevantes e muitas vezes omitidos. Um sensor permite converter um sinal - normalmente

designado por estímulo13 -, numa saída eléctrica, ou seja, num sinal analógico ou digital.

Enquanto um transdutor (Figura 6) permite converter de um tipo de energia para outro

(Wilson, 2005, p. 16).

Muitas vezes, o sensor está associado à ideia de que é o dispositivo que realmente sente

o Mundo exterior e dá um sinal de resposta. Por outro lado, o significado de transdutor

está associado a algo que converte energia – um sinal de entrada – noutra forma distinta

passível de ser medida (Hansman, 1999, p. 25).

Figura 6 – Principio de funcionamento de um transdutor Fonte: Adaptado de Lewis (2004, p. 9).

11

Business Week é uma revista publicada pela editora McGraw-Hill, tendo efectuado a sua primeira publicação em 1929. 12

Internacional Business Machines normalmente conhecida pelo seu acrónimo IBM. 13

Estímulo designa uma mudança/variação de uma propriedade física.

Sinal detectável Quantidade a medir Transdutor

Capitulo II – Redes de sensores e Aquisição de dados


Os sensores podem ser classificados de variadíssimas maneiras. Numa perspectiva de

condicionamento de sinal14 (signal conditioning), podemos defini-los como activos ou

passivos. Um sensor activo necessita de uma corrente ou tensão externa para poder

operar, adicionando energia ao ambiente em que se efectua a medição, originando assim

a respectiva medição. É exemplo de um sensor activo um radar, que envia ondas

electromagnéticas, ou um sonar, que envia ondas acústicas. Por outro lado os sensores

passivos, normalmente designados na literatura por self-generating sensors, geram a sua

própria energia de operação, removendo assim a energia necessária para a sua

operação da grandeza medida (Wilson, 2005, p.16; Hansman, 1999, p. 27). Uma síntese

de sensores típicos e o seu output comum pode ser analisado através da seguinte tabela:

Propriedade a medir Sensor Activo/Passivo Resultado (output)

Temperatura

Termopar Passivo Tensão

Silício Activo Tensão/Corrente

RTD15

Activo Resistência

Termístor16

Activo Resistência

Força/Pressão

Extensómetro17

Activo Resistência

Piezoeléctricos Passivo Tensão

Acelerómetro Activo Capacitância

Posição LVDT18

Activo Tensão AC

Intensidade da luz Fotodíodo Passivo Corrente

Tabela 1 – Exemplos de sensores típicos e as suas saídas Fonte: Adaptado de Wilson (2005, p. 17).

O sinal de saída, proveniente de um sensor deve ser mostrado, por exemplo, num

indicador - display. Este deverá apresentar uma escala conveniente, que permita uma

leitura fácil por parte do utilizador (Figura 7).

Outro método paralelo a este (Figura 8), em que surge a necessidade de guardar os

dados para, por exemplo, posterior visualização ou tratamento, implica a necessidade de

uma conversão dos sinais analógicos para digitais. Esta conversão pode ser efectuada

recorrendo e.g. a um computador que permita guardar, visualizar ou enviar os dados em

formato digital para e.g. outra unidade que efectue o seu processamento.

14

Expressão utilizada para designar o tratamento de sinais analógicos, sendo o tratamento mais comum a conversão A/D (conversão de um sinal analógico para digital). 15

Resistance temperature detectors são sensores que variam a sua resistência, conforme as variações de temperatura existentes. 16

Termístor é um semicondutor sensível a variações de temperatura. 17

Extensómetro é utilizado para medir deformações em corpos, devido a variações na sua resistência causadas pela sua própria deformação. 18

Um sensor linear variable differential transformer é utilizado para medição do deslocamento linear.



Figura 7 – Leitura e apresentação dos dados provenientes de um sensor num display Fonte: Adaptado de Hansman (1999, p. 26).

Figura 8 – Leitura e conversão A/D dos dados provenientes de um sensor para armazenamento ou display

Fonte: Adaptado de Hansman (1999, p. 26).

Existem inferências que apenas se podem fazer recorrendo a informação proveniente de

múltiplas origens, surgindo assim o conceito de multisensor data fusion (MSDF) (Liggins,

Hall e Llinas, 2009, p. 1). Este conceito refere-se a uma combinação de dados

provenientes de múltiplos sensores – que podem ser iguais ou de tipos distintos –, de

dados introduzidos por humanos ou, por exemplo, de dados provenientes da internet,

sendo a fusão de informação caracterizada pela correcta combinação e interpretação

desses dados.

Para melhorar a percepção da importância do cruzamento de informação pode-se

constatar o exemplo das Fragatas da Classe Bartolomeu Dias que possuem dois

anemómetros, um em cada bordo. Através do cruzamento da informação disponibilizada

por estes dois anemómetros é possível obter dados mais fiáveis acerca da direcção e

intensidade do vento, podendo assim diminuir a influência das superstruturas do navio no

resultado final obtido.

Quanto mais dados provenientes de diversos sensores forem utilizados, se os soubermos

interpretar e cruzar, vamos conseguir obter informação mais rigorosa e, acima de tudo,

retirar daí conhecimento (Figura 9).

Figura 9 – Hierarquia de compreensão e utilidade Fonte: Adaptado de Navega (2002, p. 3).

Display Processo Físico

Medição Sinal variável Grandeza física a medir

Mensurando

Sensor

Grandeza Física a medir

Sensor

Sinal analógico

Amplificador

Sinal analógico

Amplificado Conversor A/D

Memória Saída

Conhecimento

Informação

Dados



2.2.1. CALIBRAÇÃO DE SENSORES

A calibração de sensores é definida como a relação entre o parâmetro físico de entrada e

o parâmetro físico de saída. Assim, o processo de calibração baseia-se em providenciar

uma entrada bem conhecida ao sistema de aquisição e verificar qual a saída respectiva

(Hansman, 1999, p. 27).

A calibração é utilizada para obter dados provenientes de sensores com o menor erro

possível. Não devem haver erros e.g. de 10 ºC, se pretendemos medir variações de

centésimas de grau Célsius. O erro pode ser definido como a diferença entre o valor

medido e o valor real da variável a medir, e pode ser representado pela seguinte equação

(Dieck, 1999, p. 62):

E = Vm – Vr (1)

Onde E: Erro medido; Vm: Valor obtido pela medição efectuada e Vr: Valor real.

Os tipos de variáveis que podem influenciar um sensor em dois tipos distintos (Hansman,

1999, p. 27):

Interfering Input (Interferência de entrada);

Modifying Input (Modificação da relação entre a entrada e a saída).

O ruído branco19 (white noise) é um exemplo de interferência de entrada o que vai fazer

com que exista uma modificação na grandeza medida, adicionando assim uma

interferência no sinal de entrada. Um exemplo de uma grandeza considerada como

modifying input é a temperatura, que influencia a própria calibração efectuada ao sensor.

Ao variar este tipo de parâmetro (Figura 10), mesmo mantendo a entrada constante,

verifica-se uma alteração na variável de saída, pois a curva de calibração vai ser

altamente influenciada por este parâmetro (Hansman, 1999, p. 28).

Figura 10 – Introdução de uma modifying input na variação da curva de calibração de um sensor

Fonte: Adaptado de Hansman (1999, p.28).

19

Ruído branco é caracterizado por ter uma densidade de energia igual em todo o espectro de frequência.

Sinal de saída (s)

tempo (t)



O cruzamento de dados de várias fontes pode originar informação fiável. No entanto se

estes são pouco precisos e de variação desconhecida pode(Hall e Llinas, 1998, p. 2), o

conhecimento da variação média esperada, ou mesmo da variação máxima, pode ser

informação útil para calibrar os respectivos sensores, diminuindo assim o erro nas

medições obtidas.

Figura 11 – Exemplo da fusão de dados provenientes de 3 sensores Fonte: Adaptado de Hansman (1999, p. 31).

Deve-se também ter em conta que os dados apenas podem ser cruzados, directamente,

como raw data20, se forem dados proporcionais. Isto é, não se pode combinar dados com

proporções diferentes, sem previamente os tratar através de métodos matemáticos (Hall

e Llinas, 1998, p. 8).

2.2.2. TIPOS DE ERROS DE MEDIDA

Os tipos de erros existentes na aquisição de dados provenientes de sensores podem ser

separados em dois tipos distintos (Hansman, 1999, p. 29):

Erros sistemáticos (systematic error);

Erros aleatórios (random error).

O erro sistemático pode ter a sua origem em variadíssimos factores, sendo o principal a

variação de uma modifying input (conceito já introduzido anteriormente). Este erro é

associado geralmente a uma calibração deficiente do sensor, com origem numa variação

de temperatura de operação.

Outra forma passível de originar um erro sistemático é através de um processo

denominado na literatura como invasividade (invasiveness) (Hansman, 1999, p. 29). A

interacção entre a grandeza a medir e o aparelho de medição faz com que exista um erro

20

Representam dados que não foram alvo de qualquer tratamento matemático, normalmente designados por dados em bruto.

Medição

Sensor 1

Sensor 2

Sensor 3

Fusão dos

dados

provenientes

dos sensores



na medição. Um exemplo de invasividade dado por Hansman (1999, p. 29) é a medição

de um pequeno volume de líquido a uma baixa temperatura com um termómetro quente,

existindo claramente uma transferência de energia para o líquido resultando numa

medição imprecisa (com a variável medida a ser influenciada pelo sensor).

Figura 12 – Analogia de um alvo com a precisão das medidas efectuadas Fonte: Adaptado de Hansman (1999, p. 29).

É preciso ter em consideração que erros sistemáticos também podem ser introduzidos

por observadores humanos, sendo um exemplo deste tipo de erros os erros de

paralaxe21. Os erros sistemáticos encontram-se representados na Figura 12 - A através

da distância das medições efectuadas ao centro do alvo, sendo os erros aleatórios

representados também, na Figura 12 - B.

O erro aleatório é, muitas vezes, referido como ruído, sendo este ruído de uma forma

muito simplificada, sinal que não transporta nenhuma informação útil misturado com o

sinal de entrada pretendido. Este erro se for aleatório é frequentemente caracterizado por

apresentar uma distribuição Gaussiana (Figura 13) (Hansman, 1999, p. 30). A sua

precisão é normalmente quantificada pelo desvio padrão22 ao considerar uma grande

quantidade de medições efectuadas, estando 68% das medições compreendidas em ,

95% em e 99,7% em

.

Figura 13 – Representação de uma distribuição Gaussiana Fonte: Hansman (1999, p. 30).

21

Erro de leitura normalmente associado à má colocação do operador em relação à escala de medida. 22

É a medida mais comum da dispersão estatística, pertencendo a um ramo designado estatística descritiva. Este ramo da estatística é normalmente caracterizado por aplicar variadíssimas técnicas para conseguir descrever um conjunto concreto de dados.

A B



2.2.3. APLICAÇÕES ACTUAIS DAS REDES DE SENSORES

EM AMBIENTE MILITAR

Ao longo dos tempos muitas aplicações foram criadas e utilizadas com vista a suprimir

necessidades existentes. Durante a guerra fria, foi utilizado um sistema de vigilância

acústica (SOSUS23), em que foram utilizados uma série de hidrofones24 para detectar e

seguir submarinos soviéticos. Com o avançar dos anos outros sistemas mais evoluídos

foram surgindo, sendo o SOSUS actualmente utilizado para monitorizar eventos no

oceano (e.g. sons de actividade animal). Também no decurso da guerra fria foram

utilizadas redes de radares aéreos (uma rede de sensores aéreos), com vista a defender

os Estados Unidos da América (EUA) e o Canadá de possíveis ataques (Chong e Kumar,

2003, p.1248).

Seguiram-se, em meados de 1980, vários programas de desenvolvimento, impulsionados

pelo Defense Advanced Research Projects Agency (DARPA), que tivera como principal

objectivo a criação de Distributed Sensor Networks (DSN). O final verificou-se em 2003

durante o desenvolvimento do projecto Sensor Information Technology (SensIT) ao longo

deste projecto foram desenvolvidas novas técnicas de comunicação em redes num

cenário de guerra. As necessidades actuais de transferência de dados de vídeo e voz são

cada vez maiores, e as técnicas de comunicação são mais fiáveis. Foram também

aperfeiçoados os métodos para extrair informação útil, fiável e atempada dos dados

adquiridos (Chong e Kumar, 2003, p.1248-1250).

As aplicações das redes de sensores podem ser divididas consoante a sua aplicação.

Aplicações puramente militares, segurança de infra-estruturas, segurança de tráfego

aéreo, vigilância do tráfego aéreo, videovigilância, automação industrial, robótica,

monitorização do ambiente que nos rodeia, controlo de infra-estruturas, medicina, etc.

(Chong e Kumar, 2003, p.1247). As principais vantagens das redes de sensores nos dias

de hoje centram-se no seu baixo custo e facilidades de implementação.

Algumas das suas aplicações prendem-se com o guiamento de mísseis, controlo de

veículos não tripulados (e.g. o UAV25), efectuar condition monitoring26 a armas e

23

SOSUS é o acrónimo de SOund SUrveillance System. 24

É um transdutor de som para um sinal de tensão ou corrente, podendo ser utilizado na água ou noutros líquidos. Este permite assim a escuta de sons propagados num fluido. 25

UAV é um acrónimo de Unmanned Aerial Vehicle. 26

Efectuar a monitorização contínua de parâmetros de funcionamento, com vista a acompanhar e prever eventuais falhas existentes no sistema monitorizado.



máquinas (e.g. o projecto MecPAB27 que se encontra a ser desenvolvido actualmente na

Escola Naval). Os exemplos acima enumerados correspondem apenas a alguns

exemplos das inúmeras aplicações possíveis, sendo na realidade as suas aplicações

aplicadas a mais campos (Liggins, Hall e Llinas, 2009, p. 6).

Alguns exemplos de aplicações militares podem ser retirados, mais pormenorizadamente,

da análise da tabela seguinte:

Aplicação Variáveis a observar Plataforma sensor

Vigilância Oceânica

Sinais Electromagnéticos Sinais Acústicos

Relacionadas com energia nuclear Entre outros

Navios Aviões

Submarinos Meios terrestres

Defesa anti-aérea Radiações electromagnéticas Aviões Navios

Meios terrestres

Vigilância e aquisição de alvos Radiações electromagnéticas Aviões

Meios terrestres

Aviso antecipado e defesa Radiações electromagnéticas

Relacionadas com energia nuclear

Satélites Aviões

Meios terrestres

Tabela 2 – Exemplos de aplicações militares Fonte: Adaptado de Hall e Llinas (1998, p. 9).

Dando um exemplo concreto de uma aplicação das redes de sensores em ambiente

militar e, mais precisamente na Marinha, pode-se dar o exemplo de vigilância Oceânica

(Figura 14). Estas redes possibilitam a variadíssimos meios navais a troca de informação

proveniente dos seus sensores (e.g. contactos de alvos inimigos), podendo assim cruzar

a informação obtida e conseguir detectar a presença concreta de ameaças. Assim,

possibilita um claro aumento na probabilidade de detecção por parte de uma força naval.

Figura 14 – Exemplo de um sistema de vigilância oceânica (ocean surveillance)

Fonte: Liggins, Hall e Llinas (2009, p. 25).

27

Monitorização do estado de condição e predição de avarias de bordo, dando este projecto origem também (à semelhança do projecto UAV e de muitos outros) a várias Memórias de fim de curso/Teses de Mestrado por parte dos alunos da classe de Engenheiros Navais ramo de Armas e Electrónica (EN-AEL), alunos do Departamento de Armas e Electrónica da Escola Naval.



O sistema de comunicação Link11, utilizado pelas Fragatas da Classe Vasco da Gama,

também possibilita que entre diversos meios navais exista uma troca de informações

sobre contactos adquiridos através dos seus sensores (e.g. radares). Este é um exemplo

de como a troca de informação proveniente de sensores externos ao próprio navio pode

ser utilizada de forma útil para detectar ameaças.

Uma abordagem às redes de sensores, consideradas de aplicação não militar, pode ser

feita através da seguinte tabela:

Aplicação Variáveis a observar Plataforma sensor

Manutenção baseada no estado de condição

Sinais electromagnéticos Sinais Acústicos

Sinais magnéticos Temperatura

Raios X Vibrações

Navios Aviões

Meios terrestres (e.g. fábrica)

Robótica

TV Sinais acústicos

Sinais electromagnéticos Raios X

Corpo de um robô

Diagnostico médico

Raios X Ressonâncias magnéticas nucleares

Temperatura Raios infravermelhos

Inspecção visual Dados biológicos/químicos

Laboratório

Monitorização do ambiente Ondas sísmicas

Radiação electromagnética Dados biológicos / químicos

Satélites Aviões

Meios terrestres Amostras subterrâneas

Tabela 3 – Exemplos de aplicações não militares Fonte: Adaptado de Hall e Llinas (1998, p. 10).

A comunidade que se pode designar por não militar e que se interessa por este tipo de

temática centra-se basicamente na comunidade académica, comercial e industrial. Foram

desenvolvidos sistemas para localizar e monitorizar desastres naturais, o estado do

tempo, desenvolvimento de domótica, aplicações médicas, etc. A grande variedade e

aplicabilidade levaram a que a investigação e desenvolvimento tivessem de ser

constantes, com vista a resolver os problemas que foram surgindo no dia-a-dia (Hall e

Llinas, 1998, p. 10). Verifica-se assim, neste campo, um claro avanço dia após dia, pois a

indústria possui uma capacidade de evolução e desenvolvimento bastante elevada,

tendo, na grande maioria dos casos, enormes verbas disponíveis.

Uma das primeiras conferências internacionais importantes teve como tema Multi-Sensor

Fusion and Integration for Intelligent Systems e foi patrocinada pelo IEEE, tendo sido

realizada em Las Vegas, USA de 2 a 5 de Outubro de 1994.



2.2.4. CONSTITUINTES DE UMA REDE DE SENSORES

Um sistema de sensores é constituído basicamente por três componentes: sensores

(sensing), comunicações (communication) e computação (computing) (Chong e Kumar,

2003, p 1247).

Figura 15 – Os três Pilares constituintes de uma rede de sensores

O sensor faz a aquisição e por vezes algum pré-processamento dos dados (e.g.

conversão A/D), permitindo sentir o Mundo que nos rodeia. O bloco de comunicações

permite o envio dos dados para e.g. armazenamento ou processamento. O bloco de

computing faz o armazenamento dos dados adquiridos e possibilita a utilização de

algoritmos de processamento (Chong e Kumar, 2003, p. 1248).

2.2.5. CARACTERÍSTICAS PRESENTES NAS REDES DE

SENSORES

As características das redes de sensores variam consoante a aplicação a que se

destinam. Podemos resumir as características de uma rede de sensores da seguinte

forma:

Sensores

Tamanho: pequeno ou grande (e.g. satélites, radares). Número: muitos ou poucos. Tipo: passivos (e.g. sensores acústicos, sísmicos, vídeo, magnéticos) ou activos (e.g. radares). Composição: de apenas um tipo ou uma mistura heterogénea de diferentes tipos de sensor. Cobertura espacial: dispersos ou juntos. Implementação: Pensada e estruturada (e.g. sensores numa fábrica) ou ad-hoc. Dinâmica: fixos (e.g. sensores de ondas sísmicas) ou móveis (e.g. veículos robot).

Variável a medir

Localização: distribuídos (e.g. monitorização do ambiente) ou localizada (e.g. seguimento de alvos). Mobilidade: Estática ou dinâmica. Natureza: Cooperante (e.g. controlo de tráfego aéreo) ou não cooperante (e.g. alvos militares).

Ambiente de operação

Favorável (e.g. Escritório) ou adverso (e.g. campo de batalha).

Comunicação Rede: Com fios ou sem fios. Largura de banda: Alta ou baixa.

Arquitectura de processamento

Centralizada (todos enviam os dados para uma unidade única), distribuída (processamento é efectuado pelo sensor ou noutra localização) ou híbrida (misto das descritas anteriormente).

Energia disponível Limitada (e.g. Sensores isolados) ou sem limites (e.g. Sensores perto de alimentação).

Tabela 4 – Características passíveis de configuração numa rede de sensores Fonte: Adaptado de Chong e Kumar (2003, p. 1248).

Sensing Communication Computing

Rede de

comunicações

Datalogging

Algoritmos de Processamento

+

+

+

+ Sensores

Rede d

e S

ensore

s



Possuindo, actualmente, variadíssimos tipos de tecnologia à disposição, as redes de

sensores estão cada vez mais a passar por uma constante miniaturização e uma

diminuição de custos associados à tecnologia existente. É possível assim, efectuar

funções que não seriam sequer imagináveis à 20 anos atrás, através de tecnologia off-

the-shelf (OTS).

A capacidade de combinar diversos tipos de protocolos de comunicação, é hoje uma

realidade a que podemos chamar utilização de redes híbridas. Deste modo, é possível

utilizar o melhor protocolo, dependendo do caso concreto, o que melhora o rendimento da

rede de sensores elaborada. Ao combinar diversos protocolos numa única rede de

sensores, aumentamos assim a sua aplicabilidade. Assim é possível evitar a utilização de

um único protocolo por rede, o que iria levar a que em casos muito concretos tivessem de

ser desenvolvidos protocolos específicos adaptados a cada aplicação, possibilitando

assim obter o rendimento28 desejado. Um exemplo da utilização de redes de sensores

híbridas foi a efectuada por Vitturi e Miorandi (2005, p. 5), em que foram efectuadas

simulações utilizando algum software específico de simulação de redes (NS-229)

constituídas pelo protocolo IEEE 802.3 (Ethernet) e IEEE 802.11 (Wi-Fi). Uma rede de

sensores deste género é o que se pretende elaborar e aplicar no sistema final

desenvolvido neste estudo.

A evolução tecnológica dos sensores que se tem vindo a descrever pode ser descrita

através da seguinte tabela:

Passado (2000 – 2003) Presente (2010)

Tamanho: De um baralho de cartas até a uma caixa de sapatos pequena

Pode ir até à dimensão de uma partícula de pó

Peso: Gramas Negligenciável

Topologia: Cliente/Servidor e Peer to Peer Peer to Peer

Tempo de vida da alimentação: Pilhas AA - dias a semanas Energia solar - meses a anos

Implementação: Colocado manualmente Colocação quase aleatória

Tabela 5 – Os sensores no Passado e no Presente Fonte: Adaptado de Chong e Kumar (2003, p. 1251).

Figura 16 – Exemplos de várias gerações de sensores

Fonte: Chong e Kumar (2003, p. 1251).

28

O conceito de rendimento está associado, neste contexto, à quantidade mínima de serviço que um sistema concreto pode fornecer. 29

Software de simulação do comportamento de uma rede, que viu o seu desenvolvimento começar em 1989. Este é nos dias de hoje considerado um software de referência, principalmente devido à fiabilidade obtida nas simulações que executa.



2.2.6. ALIMENTAÇÃO DE UMA REDE DE SENSORES

A maior parte dos sensores existentes necessita de alimentação externa, ou seja, não

são auto-suficientes. Os sensores podem assim ser divididos em dois tipos: os que têm

uma fonte de alimentação inesgotável e os que têm uma fonte de alimentação esgotável.

Estes últimos têm de ser dotados de meios de alimentação autónomos (e.g. painéis

solares).

A eficiência energética é bastante importante em redes de sensores sem fios, pois estas

são normalmente colocadas em locais de difícil acesso, onde não existem, na maioria

dos casos, possibilidades de fornecer alimentação. A implementação de sistemas de

gestão dos recursos energéticos quer seja em software ou hardware aplica-se a estes

casos. As redes de sensores sem fios verificam um maior gasto energético durante a

comunicação, tendo de efectuar o mínimo de ligações com a maior eficiência possível,

aumentando assim a eficiência do sistema (Bharathidasan e Ponduru, 2003, p.3).

No caso concreto deste estudo, a necessidade de alimentação reveste-se de grande

importância, pois o navio alvo, onde estará instalada a rede de sensores terá de ter a sua

própria alimentação. Um esquemático simplificado do sistema a implementar, pode ser

representado pelas seguintes figuras:

Figura 17 – Esquemático da situação operacional

Acelerómetro

Sensores de pressão

Sensores de Temperatura

Câmara

Data logger

Router Router

Wireless Bridge Link

Computador

Navio Alvo Navio que efectua a monitorização

Figura 18 – Esquemático simplificado da rede de sensores a implementar

Rede de sensores



A rede de sensores a implementar no navio alvo, encontra-se assinalada na figura

anterior pela caixa a amarelo. Esta deve possuir redundância para que uma falha na

alimentação do sistema não origine a falha total do sistema, possibilitando assim a

continuação da recolha de dados.

2.3. RECOLHA DE DADOS

A maior parte dos sinais provenientes de sensores são sinais analógicos, cuja variação

de tensão ou corrente (grandezas medidas mais comuns), nos indica a variação de um

parâmetro físico. É necessário e importante, não só saber como varia esse sinal em

função do parâmetro a medir, mas também armazenar os dados adquiridos para posterior

análise.

É neste contexto que surge a conversão A/D (de analógico para digital). Existem

inúmeras obras relativas à conversão A/D, mas, sem dúvida, é de realçar o artigo escrito

por Harry Nyquist em 1924, publicado no Bell Labs Technical Journal, com o título Certain

Factors Affecting Telegraph Speed, que apesar de fortemente focado nos aspectos

próprios da engenharia de um telégrafo, começou por separar alguns conceitos

essenciais (Nyquist, 1924).

Os referidos conceitos essenciais baseavam-se no conteúdo da mensagem e da

informação que esta necessitaria de transportar, preocupando-se com a máxima largura

de banda necessária. Algumas regras para a transferência de informação em linhas

telegráficas foram assim definidas.

Em 1948, Claude Shannon, através do seu artigo A Mathematical Theory of

Communication, publicado também no Bell Labs Technical Journal, apresenta-nos o

esquemático geral de um sistema de comunicação. Podendo assim verificar que existiu

um claro avanço ao trabalho apresentado por Harry Nyquist. O esquemático apresentado

por Shannon foi então o seguinte:

Figura 19 – Diagrama do esquema de um sistema de comunicações (Esquema geral) Fonte: Shannon (1948, p. 380).



Podemos relacionar o descrito na figura anterior com uma simples rede de sensores,

apesar de muito possivelmente não ter sido essa a ideia original. Na maioria dos casos,

os sinais analógicos provenientes de sensores analógicos situam-se na gama dos mV,

sendo impensável transmitir sinais dessa ordem de grandeza em meios de transmissão

com perdas elevadas e sujeitos a interferências externas. Estes sinais já de si fracos

sujeitos a muito ruído necessitam de ser convertidos em sinais digitais o mais cedo

possível. A interferência pode ser diminuída utilizando blindagem (shielding), esta

consiste em isolar o cabo utilizado na transmissão diminuindo assim as interferências

(Crovella, 1999, p. 14). Os conversores A/D têm, devido à sua constituição física,

componentes electrónicos que adicionam sempre algum ruído interno (Kester, 2006, p.

1). A conversão A/D aumenta assim a fiabilidade na transmissão de dados.

Do trabalho de Harry Nyquist e Claude Shannon, duas grandes referências nesta

temática, surgiram variadíssimos teoremas e estudos posteriores. Um dos mais

relevantes teoremas nesta área ficou conhecido como teorema de Nyquist (conhecido

também como teorema da amostragem30), sendo abordado com mais rigor no

subcapítulo 2.3.4.

2.3.1. CONVERSÃO A/D

A conversão A/D faz-se, normalmente, recorrendo a um ADC31, permitindo assim

amostrar um sinal analógico em períodos de tempo normalmente constantes. Esta

amostragem consiste em atribuir um conjunto de valores digitais a um sinal contínuo no

tempo, tentando assim ter uma representação digital de um sinal analógico.

com (2)

Onde : Sinal amostrado e : representa um sinal contínuo no tempo.

Ou seja, é efectuada a amostragem de um sinal contínuo no tempo Xa(t), originando um

sinal discreto X(n) (com n valores inteiros). Os constituintes de um ADC podem ser

representados da seguinte forma (Hayes, 1999, p. 101; Loewenstein, 1999, p. 2202-

2209):

30

Sendo esta a designação que vai ser maioritariamente adoptada ao longo do texto. 31

Analog-to-digital converter ou conversor de analógico-para-digital vai ser utilizado, quando necessário, ao longo do texto a designação ADC ou conversor A/D.



Figura 20 – Esquema de blocos de um conversor A/D (ADC) Fonte: Adaptado de Hayes (1999, p. 101).

No bloco 1 da Figura 20, normalmente designado por sampler, é efectuada a conversão

de um sinal analógico - Xa(t) - para uma sequência discreta - X(n). Esta sequência

discreta é criada ao guardar os valore de Xa(t) em intervalos de tempo constantes Ts

(como descrito na equação 2)

A amostragem (sampling) pode ser feita utilizando um circuito chamado Sample-and-Hold

(S/H), sendo normalmente efectuada recorrendo a um circuito deste tipo. É possível

assim, em períodos de tempo constantes, a amostragem do sinal de entrada através da

carga e.g. de um condensador, que posteriormente é alvo de quantização32

(Loewenstein, 1999, p. 2199).

Outro método utilizado nesta fase da conversão A/D é o Track-and-Hold (T/H), diferindo

ligeiramente do S/H no seu modo de operação. O S/H opera mantendo o sinal analógico

amostrado até ao próximo ciclo de amostragem, enquanto o T/H apenas mantém o sinal

amostrado até que exista uma quantização do mesmo. Após este processo, o circuito

abre a sua entrada acompanhando o sinal de entrada até ao próximo período de

quantização, sendo o circuito do tipo T/H mais preciso, pois tem mais tempo para captar

o sinal de entrada e carregar o respectivo condensador (Loewenstein, 1999, p. 2199).

No bloco 2, é efectuada uma quantificação dos valores de amplitude obtidos pelo sampler

(bloco 1), ou seja, como as amostras X(n) têm infinitos valores possíveis de amplitude é

necessário atribuir valores de amplitude discretos. Estes valores discretos de amplitude

estão divididos em intervalos de quantização ( ). Quantos mais intervalos de quantização

houver (maior resolução), mais precisão vou obter em relação ao valor real amostrado.

O máximo erro de quantização é de

LSB33, sendo que em média o erro espera-se que

seja de 0 LSB (Loewenstein, 1999, p. 2202).

32

Quantização é o processo de atribuição de valores discretos a um sinal cuja amplitude varia entre infinitos valores. 33

Least significant bit (LSB) é o bit menos significativo na representação em binário de um dígito.

1

Sampler Quantizer Encoder

2 3



No bloco 3 - último bloco da figura - é atribuída a respectiva sequência binária, para cada

valor amostrado. Este produz uma sequência diferente para cada valor analógico de

entrada (Hayes, 1999, p. 101).

Figura 21 – Representação de um quantizador uniforme de 3 bits Fonte: Hayes (1999, p. 105).

Em qualquer conversão A/D existe ainda ruído de dois tipos distintos:

Ruído interno;

Ruído de entrada (externo ao conversor A/D).

Como ruído interno considera-se todo o ruído introduzido pelos componentes electrónicos

constituintes do sistema (e.g. resistências, condensadores e até o próprio ruído

introduzido pelo funcionamento de um microcontrolador) (Kester, 2006, p. 1). O ruído

causado pela condução eléctrica em resistências e transístores, verifica-se mais

acentuadamente na presença de altas temperaturas e de resistências de valor elevado, e

é chamado de ruído térmico – thermal noise (Loewenstein, 1999, p. 2207).

O ruído de entrada verifica-se em sinais contínuos de entrada e caracteriza-se por ter

normalmente uma distribuição Gaussiana (Kester, 2006, p. 1).

Figura 22 – Representação do ruído de entrada de um conversor A/D Fonte: Adaptado de Kester (2006, p. 1).



Uma das técnicas descritas por Kester (2006, p. 1) para possibilitar a medição do ruído

de entrada num conversor A/D baseia-se em retirar um grande número de amostras de

um sinal de entrada constante, efectuando depois o plot dos dados obtidos num

histograma. Assim, teremos a representação do ruído de entrada, que na figura seguinte

se apresenta na sua forma esperada:

Figura 23 – Representação do comportamento ideal de um ADC, face à existência de ruído de entrada Fonte: Kester (2006, p.1).

Se for obtida uma distribuição com um comportamento que não se assemelhe a uma

distribuição Gaussiana (Figura 23), pode significar que estamos perante um conversor

A/D mal desenhado ou perante um problema no fabrico do próprio conversor A/D (Figura

24) (Kester, 2006, p. 1).

Figura 24 – Representação do comportamento de um conversor A/D mal desenhado Fonte: Kester (2006, p. 1).

O ruído é usualmente especificado em volts RMS34 ou pico a pico, ou LSBs RMS ou pico

a pico rms (Loewenstein, 1999, p. 2207).

34

Root Mean Square (RMS) é também conhecido como valor eficaz de um sinal.



2.3.2. GAMA DE VALORES DE ENTRADA E RESOLUÇÃO

O conhecimento da gama de valores possíveis da variável a medir é importante pois

deve-se adaptar o sensor a esta gama de valores. Este intervalo de valores de entrada

num conversor A/D é definido por um sinal de tensão de referência. Ao alterar este sinal

aumenta-se ou diminui-se a gama de valores de entrada, fazendo variar assim a

resolução.

O valor inferior da escala é 0 V quando a escala é unipolar, quando existem valores

negativos a escala é bipolar. Os topos da gama de valores de entrada são chamados -

full scale e + full scale ([ - full scale; + full scale] ) (Loewenstein, 1999, p. 2202).

O conversor A/D do microcontrolador ATmega168 tem 10 bits de resolução, e temos

neste caso níveis de quantização (a contar com o valor 0 da gama de valores

de entrada). Uma gama de valores de 5 V ([0;5] V) é diferente de termos uma gama de

valores de 10 V ([0;10] V), mantendo o mesmo número de bits de resolução, ou seja, ao

termos um intervalo de 5 V temos

de resolução35 e ao termos 10 V de

intervalo de entrada temos

de resolução.

O aumento da taxa de amostragem não traz um aumento significativo na representação

do sinal de entrada (Figura 25), se este já está a ser amostrado a uma frequência em que

não ocorra aliasing (explicado mais à frente no texto) (Actel Corporation, 2007, p. 5). Ou

seja, a ocorrência de oversampling36 (Figura 26) não provoca por si só um aumento de

resolução na representação do sinal amostrado. O sinal amostrado deve assim ser

tratado matematicamente para diminuir ao máximo a diferença entre o sinal amostrado e

o sinal de origem e.g. efectuar a média a cada dois valores obtidos.

Figura 25 – Sinal de entrada amostrado com uma taxa de amostragem 2 vezes a sua frequência

Fonte: Actel Corporation (2007, p. 5).

35 O termo resolução é aqui utilizado para designar quanto corresponderá no sinal de entrada a

variação de 1 LSB no valor amostrado. 36

Oversampling é o termo designado para referir uma taxa de amostragem significativamente superior que a taxa de amostragem mínima necessária para amostrar o sinal sem a ocorrência de aliasing (conceito que vai ser explicado mais à frente no texto).



Figura 26 – Sinal de entrada amostrado com uma taxa de amostragem 8 vezes a sua frequência Fonte: Actel Corporation (2007, p. 6).

2.3.3. ERROS NUM CONVERSOR A/D

O conversor A/D pode apresentar dois tipos de erros (Atmel Corporation, 2006, p. 4;

Loewenstein, 1999, p. 2202-2205):

Erros lineares (Linear errors);

Erros não lineares (Nonlinear errors).

Os erros lineares são os maiores e mais comuns, mas conseguem ser corrigidos através

da multiplicação do valor obtido por uma constante (Loewenstein, 1999, p. 2202-2205).

Os erros lineares podem ser de dois tipos:

Erro de offset (offset error);

Erro de ganho (gain error).

O erro de offset é a variação da função de transferência, em relação à função ideal, no

ponto de origem. Ao ocorrer a transição do valor de 0 para 1 num valor diferente de 1/2

LSB, estamos perante erro de offset (Corporation, 2006, p. 5).

Figura 27 – Exemplo de erros de Offset positivos (A) e negativos (B) Fonte: Corporation (2006, p. 5).

B A



O erro de offset pode apresentar valores positivos e negativos conforme a variação do

sinal é para cima do eixo horizontal - entrada analógica - como na Figura 27 (A)

representa + 11/2 LSB de erro de offset ou para baixo do eixo horizontal Figura 27 (B) que

representa - 2 LSB de erro de offset.

O erro de ganho é o desvio do último nível de quantização em relação à função de

transferência ideal, depois de compensado o erro de offset. Na Figura 28 (A) temos um

erro em ganho positivo de + 11/2 LSB, e na Figura 28 (B) temos um erro de - 11/2 LSB e,

neste caso, já foi compensado o erro de offset.

Figura 28 – Exemplo de erro em Ganho positivo (A) e negativo (B) Fonte: Corporation (2006, p. 7).

Os erros não lineares são os mais difíceis de compensar, sendo preferível escolher um

conversor A/D bem desenhado. Os erros lineares podem ser de dois tipos (Loewenstein,

1999, p. 2203-2205):

Differential nonlinearity (DNL);

Integral nonlinearity (INL).

O erro DNL é a diferença entre o intervalo de quantização obtido e o tamanho do

intervalo de quantização ideal (1 LSB). A Figura 29 (A) representa dois casos em que não

existe linearidade na dimensão dos intervalos de quantização, ou seja, representa um

caso em que o erro de DNL é -1/2 e um caso em que o erro é de + 11/2 LSB.

O erro de INL é a diferença vertical entre a função de transferência obtida e a ideal, um

exemplo deste tipo de erro encontra-se representado na Figura 29 (B). Esta figura

apresenta um exemplo em que o erro de INL é de + 3/4 LSB.

B A



Figura 29 – Exemplo de erros DNL (A) e exemplo de erro INL (B) Fonte: Corporation (2006, p. 9).

Os erros abordados neste subcapítulo podem ser resumidos num erro designado por erro

absoluto (absolute error). Este erro é definido como sendo (Corporation, 2006, p. 4):

Eabsoluto = Equantização + Eoffset + Eganho + EDNL + EINL (3)

A compensação do erro absoluto é feita compensando cada um dos erros descritos ao

longo deste subcapítulo.

2.3.4. TEOREMA DA AMOSTRAGEM

O teorema da amostragem diz-nos que um sinal - x(t), de forma a haver uma correcta

reconstrução a partir da amostra, deve ser amostrado com uma frequência - famostragem(t),

duas vezes superior à maior frequência do sinal a amostrar (Karris, 2008, p. 417).

Contudo, na aplicação do teorema anterior, deve-se considerar que estamos perante um

sinal limitado na sua banda (Karris, 2008, p. 417). Sendo um exemplo de um sinal

limitado na sua banda, o representado pela figura seguinte:

Figura 30 – Exemplo de um sinal limitado na sua banda

Fonte: Adaptado de Hayes (1999, p. 103).

Ao respeitarmos a condição anterior, garantimos que através da condição (Hayes, 1999,

p. 103):

B A



Wamostragem =

2W0 (4)

Onde W0 representa a maior frequência do sinal a amostrar, vamos obter uma

transformada de Fourier do sinal original replicado periodicamente. Como podemos

constatar pela seguinte figura:

Figura 31 – Transformada de Fourier de um sinal amostrado respeitando o teorema da amostragem Fonte: Adaptado de Hayes (1999, p. 103).

A amostragem de um sinal também pode ser feita sem respeitar as condições expostas

anteriormente, onde teremos uma Wamostragem 2W0. Neste caso concreto vai haver um

deslocamento no espectro de frequência do sinal amostrado, havendo assim uma perda

de informação (Carlson, Crilly e Rutledge, 2002, p. 241). Um dos resultados possíveis,

meramente ilustrativo pode ser descrito pela seguinte figura:

Figura 32 – Exemplo de aliasing Fonte: Adaptado de Hayes (1999, p. 103).

Pela análise do sinal amostrado obtido na figura anterior e comparando-o com o sinal

original (Figura 30), é obvio que estamos a perder informação. Este fenómeno toma o

nome de aliasing, ou seja, estamos perante uma clara sobreposição dos elementos do

espectro em frequência do sinal amostrado (Carlson, Crilly e Rutledge, 2002, p. 241;

Hayes, 1999, p. 103).

A designação de frequência de Nyquist (também designada por frequência de aliasing ou

folding frequency) é normalmente utilizada para designar a frequência máxima do sinal a

amostrar (Semiconductor, 1980, p. 4). A frequência mínima segundo a qual não ocorre

aliasing designa-se por taxa de Nyquist (Nyquist rate) (Hayes, 1999, p. 103).



Figura 33 – Exemplo de aliasing numa função do tipo seno Fonte: Adaptado de Loewenstein (1999, p. 2199).

É importante ter em conta que no Mundo real muitas vezes não se tem conhecimento a

priori da gama de frequências esperada. Sendo assim não existe uma receita para

efectuar boa amostragem, mas sim um conjunto de regras, como as descritas

anteriormente, que se forem correctamente interpretadas e aplicadas garantem bons

resultados.

Ao colocar um filtro37 pode-se limitar a largura de banda do sinal de entrada, ou seja,

garantimos assim que não se obtém um sinal de entrada com uma frequência maior que

a fcorte do filtro aplicado. A utilização deste filtro garante assim que não existirão

fenómenos de aliasing, se for assegurada uma taxa de amostragem com uma frequência

superior a duas vezes a fcorte do filtro aplicado (Semiconductor, 1980, p. 2).

O filtro utilizado (Figura 34) deve ser um filtro com um ganho de 1 dB, garantindo apenas

a passagem de sinal nas frequências de interesse, como foi aliás referido anteriormente

(Loewenstein, 1999, p. 2214).

Figura 34 – Exemplo de filtro passa-baixo (antialiasing filter) aplicado para evitar a ocorrência de aliasing Fonte: Semiconductor (1980, p. 2).

37

Normalmente este filtro toma a designação de antialiasing input filter.

Amplitude

Tempo



2.4. CONCLUSÕES OU SÍNTESE

Este capítulo efectua uma abordagem ao fundamento teórico das redes de sensores,

descrevendo assim os seus componentes. Os erros associados a cada sensor e ao

conversor A/D são descritos prevendo desde já a sua existência, influenciando a

fiabilidade dos dados retirados do sistema. As aplicações das redes de sensores foram

também descritas dando uma ideia concreta dos seus campos de aplicação.

As redes de sensores necessitam na grande maioria das vezes de adquirir dados

analógicos (normalmente tensões e/ou correntes), sendo abordado o funcionamento da

conversão A/D.

Outro tema relevante é a taxa de amostragem, pois afecta o tipo de fenómenos a registar,

que neste caso concreto de estudo se prevê bastante rápido. O pacote

hardware/software tem de assegurar assim uma taxa de amostragem mínima para que

não ocorra aliasing.

Os variadíssimos erros existentes no conversor A/D e nos sensores devem procurar ser

compensados, devendo se possível ser compensados de forma autónoma e em tempo

real.

O capítulo seguinte faz uma abordagem aos protocolos de rede, fazendo uma ponte entre

o universo das redes de sensores e as redes de computadores. Estes dois Mundos que

parecem tão distintos trazem inúmeras vantagens ao campo de aplicação das redes de

sensores.


3. CAPÍTULO III

TELEMETRIA E PROTOCOLOS DE REDE

3.1. INTRODUÇÃO

O desenvolvimento de sistema de telemetria utilizando as normas IEEE 802.3 e IEEE

802.11g é um desafio, pois é necessário ter conhecimentos de várias áreas e reuni-los

criando um produto final fiável e com a performance esperada.

A revisão do estado da arte neste capítulo vais ser feita ao conceito de telemetria, aos

protocolos a utilizar no sistema a desenvolver e vai ser feita também uma abordagem aos

sensores de rede.

3.2. TELEMETRIA

A telemetria indica como se recolhem dados de uma localização remota e os transmitem

de forma eficiente possibilitando assim a sua gravação e análise (Lozano-Nieto, 1999, p.

1). A aquisição pode simplesmente ser feita recorrendo a um sensor, convertendo o sinal

obtido de analógico para digital e recorrendo a um Datalogger com interface Ethernet

enviar esses dados para outra localização. Ao utilizar protocolos de rede com

interoperabilidade (e.g. IEEE 802.3 e IEEE 802.11g), permite transmitir os dados por fio

ou por wireless.

Os modos de envio do sinal, após um correcto condicionamento (normalmente conversão

A/D), são os seguintes:

I. Envio por fio sem modulação;

II. Envio por fio modulando o sinal enviado;

III. Envio por wireless.



Figura 35 – Diagrama de blocos para um sistema de telemetria Fonte: Adaptado de Lozano-Nieto (1999, p. 2).

A distância de comunicação efectiva de um sistema de telemetria por wireless é

influenciada pelos seguintes factores (Lozano-Nieto, 1999, p. 2):

Potência irradiada pelo transmissor;

Sensibilidade do receptor;

Largura de banda do sinal RF.

A largura de banda ao ser aumentada provoca também um aumento do contributo do

ruído para o sinal enviado, para contrariar isto podemos utilizar uma maior potência de

transmissão para manter a mesma relação entre o sinal e o ruído (SNR38 - signal-to-noise

ratio) (Lozano-Nieto, 1999, p. 2).

A telemetria, assim como muitas outras aplicações, encontra-se regulada num standard,

desenvolvido pela InterRange Instrumentation Group (IRIG), de Maio de 2004 que é

usado em todo o Mundo pela indústria militar e civil (IRIG, 2004).

O conceito de telemetria surge da interligação de tudo o que foi abordado neste

subcapítulo e em subcapítulos anteriores. A telemetria vai ser efectuada, neste caso

concreto de estudo, através da recolha de dados através de sensores adequados,

conversão A/D e transporte recorrendo a Dataloggers com interface Ethernet (IEEE

802.3) e envio para a unidade monitorizadora através de um router com uma ligação a

uma antena de alto ganho (a funcionar na banda de frequências do IEEE 802.11g). A

utilização de antenas com elevado ganho é importante pois foi obtido por Capela,

Pessanha, Vieira e Monsanto (2008, p. 10), com o material existente inicialmente e com

antenas omnidireccionais nos dois pontos de envio e recepção, capacidade de envio de

dados provenientes de sensores a uma distância de 7,49 km. A largura de banda e

alcance obtidos não foram no entanto satisfatórios.

38

Apresenta a relação entre o sinal obtido e o ruído presente numa determinada situação.

Sensor

Condicionamento de sinal (e.g. Conversão A/D)

Codificador Repetidor

Modulador Adaptador de linha

Amplificador RF +

Modulador

Antena

Telemetria com fios

Telemetria com fios

Telemetria sem fios

Capitulo III – Telemetria e Protocolos de rede


3.3. MODELO OSI VS MODELO TCP/IP

A ANSI39, em 1977, começou a trabalhar no modelo OSI40 (OSI reference model) com o

objectivo de elaborar um standard, que pudesse ser utilizado nas comunicações em rede

heterogéneas. Ou seja, procurou-se encontrar um padrão de comunicação que

conseguisse, através de vários dispositivos de diferentes fabricantes, configurar uma

ligação em rede capaz de trocar informações quando ligados entre si (comummente

designado por ligados em rede41). O modelo OSI nos dias de hoje é muito utilizado para o

ensino desta temática, mas não é o mais utilizado. O modelo TCP/IP é que representa a

base para a maioria dos protocolos existentes nos dias de hoje (Edwards e Bramante,

2009, p. 45; Zimmermann, 1980, p. 425).

A larga utilização e difusão do modelo TCP/IP deve-se essencialmente ao

desenvolvimento tardio do modelo OSI (Tabela 6), pois quando este finalizou o seu

aperfeiçoamento já o modelo TCP/IP se encontrava implementado nos sistemas

existentes. A migração do modelo TCP/IP para o OSI não se conseguiu justificar pois

este já tinha visto o seu funcionamento comprovado e apreendido, sendo o modelo

TCP/IP o mais usado nos dias de hoje (Goralski, 2009, p. 22)

Camada 7 Camada de aplicação

Camada 6 Camada de apresentação

Camada 5 Camada de sessão

Camada 4 Camada de transporte

Camada 3 Camada de rede

Camada 2 Camada de ligação

Camada 1 Camada física

Tabela 6 – Modelo de referência OSI Fonte: Adaptado de Edwards e Bramante (2009, p. 46).

O modelo TCP/IP, ou modelo de internet (internet model), foi criado em meados de 1970

(como foi referido anteriormente antes do modelo OSI). O modelo TCP/IP implementa

uma série de camadas, e cada camada é responsável por implementar o seu protocolo

específico (Goralski, 2009, p. 26). O modelo TCP/IP é normalmente representado sobre a

forma de uma pilha (Tabela 7) (semelhante à representação do modelo OSI), em que

aparecem discriminadas as camadas existentes.

39

ANSI é o acrónimo de American National Standards Institute, em português é designado por “Instituto Nacional Americano de Padronização”. 40

OSI é o acrónimo de open systems interconnection. 41

Designação normalmente utilizada para designar vários tipos de hardware interligado entre si utilizando o mesmo protocolo de comunicação.



Camada 5 Camada de aplicação

Camada 4 Camada de transporte

Camada 3 Camada de rede

Camada 2 Camada de ligação

Camada 1 Camada física

Tabela 7 – Modelo de referência TCP/IP Fonte: Adaptado de Edwards e Bramante (2009, p. 57).

A análise a cada camada do modelo TCP/IP (Tabela 7) vai ser feita nos próximos

subcapítulos e é baseada no trabalho de Kurose e Ross (2004, p. 91-455), Goralski

(2009, p. 30-41), Edwards e Bramante (2009, p. 197-241) e Parziale, Britt, Davis,

Forrester, Liu, Matthews e Rosselot (2006, p. 6-9).

3.3.1. CAMADA DE APLICAÇÃO

A camada de aplicação (application layer) é a responsável por manter as aplicações de

rede e mantém a comunicação com as aplicações que são executadas num sistema

terminal42, sendo esta camada implementada por software. Os protocolos aplicados nesta

camada são o File Transfer Protocol (FTP), Simple mail Transfer Protocol (SMTP), Hyper

Text Transfer Protocol (HTTP), etc. O mesmo sistema terminal (host) possibilita também

a comunicação entre dois processos utilizando a comunicação inter-processos (esta

comunicação é definida pelo sistema operativo). Os processos executados num sistema

terminal interactuam com a camada de transporte através de um socket43, que permite

receber e enviar dados provenientes da camada de transporte (transport layer).

3.3.2. CAMADA DE TRANSPORTE

A camada de transporte faz o transporte das mensagens provenientes da camada de

aplicação. O transporte de mensagens proporciona, assim, uma comunicação lógica

entre aplicações (processos) a correr em sistemas terminais diferentes. A camada de

transporte permite implementar os protocolos: TCP44, UDP45, etc. O protocolo TCP está

42

Sistema terminal é muitas vezes designado por nó terminal, sendo utilizado para referir os dispositivos que se encontram na periferia da rede. 43

É aqui utilizado o termo socket para designar a combinação de um endereço IP, um protocolo e o número da sua porta de comunicação. 44

São as iniciais utilizadas para Transmission Control Protocol, este protocolo pode suportar variadíssimas ligações em simultâneo tendo um socket diferente para cada ligação. Este protocolo está associado a uma transferência de dados fiável, pois efectua controlo de erros dos dados enviados.



associado a uma ligação connection-oriented46 e o protocolo UDP a uma ligação

connectionless47.

3.3.3. CAMADA DE REDE

A camada de Rede (network layer) faz a comunicação lógica entre sistemas terminais

(hosts). Os protocolos IP48 e protocolos de encaminhamento (routing protocols) são

implementados nesta camada. A Figura 37 representa dois routers49, representado as

camadas do modelo TCP/IP que são implementadas. O router implementa o modelo

TCP/IP até esta camada aplicando assim os protocolos de encaminhamento, o switch50

apenas implementa até à segunda camada, a camada de ligação (link).

3.3.4. CAMADA DE LIGAÇÃO

A camada de ligação (link layer) faz a transferência dos pacotes51 de dados entre nós

adjacentes (vizinhos) através da sua ligação. A sua implementação é feita fisicamente em

cada placa de rede52, implementados os protocolos Ethernet53 e PPP54.

45

Iniciais utilizadas para designar User Datagram Protocol. Este protocolo está associado à ideia de best effort. (melhor esforço), em que não é assegurada a entrega dos pacotes enviados, não sendo assim assegurada uma QoS (Quality of Service) mínima. 46

Associada a uma elevada fiabilidade na entrega da mensagem ao seu destino, executando assim um controlo de erros. Esta faz o pedido de retransmissão dos pacotes quando estes não são recebidos ou são recebidos com erro. 47

Ligação que não assegura uma entrega fiável dos pacotes enviados, não executando controlo de entrega nem do erro associado aos pacotes que envia. 48

Iniciais utilizadas para designar Internet Protocol. 49

Um router é um dispositivo de rede cujo software e hardware estão geralmente adaptados às tarefas de roteamento e encaminhamento de pacotes. 50

Hardware utilizado para reencaminhamento de pacotes numa rede. 51

O termo pacote encontra-se largamente associado ao termo PDU (Packet Data Unit), sendo utilizada a palavra pacote para designar um PDU que inclui os cabeçalhos de todas as camadas implementadas pelo modelo em utilização. 52

Normalmente referidas em literatura como Network Interface Card (NIC), podemos designar uma placa de rede como uma combinação equilibrada entre hardware, software e respectivo firmware. 53

É a tecnologia de rede com fios dominante nos dias de hoje, definida no standard IEEE 802.3. Permite implementar velocidades, que nos dias de hoje, variam entre 10 Mbps e 10 Gbps. 54

Protocolo ponto-a-ponto (Point-to-Point Protocol). Este foi criado com o objectivo de transportar todo o tráfego entre dois dispositivos utilizando uma ligação única.



Figura 36 – Recriação do esboço original efectuado por Metcalfe do standard de internet 10 Base 5 Fonte: Kurose e Ross (2004, p. 402).

3.3.5. CAMADA FÍSICA

A camada física (physical layer) é a responsável por enviar cada bit individualmente,

desde o nó de origem até ao nó de destino. Esta camada é muitas vezes associada ao

conceito de bits no fio (bits on the wire).

Figura 37 – Modelo de referência TCP/IP - Exemplo de Implementação

Fonte: Goralski (2009, p. 28).

3.4. IEEE802.3 - ETHERNET

O primeiro standard da norma IEEE 802.3 foi publicado em 1985 (IEEE, 2008, p. IV), este

standard foi constantemente desenvolvido acrescentando maiores funcionalidades e

maiores capacidades de operação. A camada MAC (Media Access Control), como

referido no seu standard, utiliza o mecanismo CSMA/CD (Carrier Sense Multiple Access

with Collision Detection). O mecanismo CSMA/CD já se encontrava descrito mesmo

anteriormente ao aparecimento deste standard, por Metcalfe e Boggs em 1976 (Metcalfe

e Boggs, 1976, p. 398).

A Ethernet experimental, desenvolvida por Metcalfe e Boggs, elementos pertencentes à

Xerox Palo Alto Research Center, começaram inicialmente com taxas de transferência de



dados de aproximadamente 2,94 Mbps e evoluiu posteriormente para 10 Mbps (Metcalfe

e Boggs, 1976, p. 399). As evoluções seguintes proporcionaram velocidades de 100

Mbps (Fast Ethernet) e de 1 000 Mbps (Gigabit Ethernet), estando actualmente

estabelecida (no ano de 2010) nos 10 Gbps (10 Gigabit Ethernet) a maior taxa de

transferência de dados possível com recurso a este protocolo de comunicação (IEEE,

2008, p. IV).

As aplicações deste estudo vão utilizar a Fast Ethernet e a Gigabit Ethernet. A primeira

para a transferência dos dados provenientes dos respectivos Dataloggers (Dataq e

Arduino) com interface Ethernet e aquisição de imagens provenientes de simples

webcams e a segunda para interface e.g. entre um computador portátil (unidade de

aquisição) e uma camera de alta-velocidade.

Fast Ethernet

Gigabit Ethernet

Sensores

Figura 38 – Dois exemplos de utilização da norma IEEE 802.3

O protocolo IEEE 802.3 divide a camada de ligação (Data link layer) em duas

subcamadas distintas (Edwards e Bramante, 2009, p. 264). As subcamadas referidas são

as seguintes (Figura 39):

Logical Link Control (LLC);

Media Access Control (MAC).

Os dois subcapítulos seguintes explicam pormenorizadamente cada uma das

subcamadas referidas anteriormente.

Figura 39 – Relação do modelo OSI com a norma IEEE 802.3 Fonte: Adaptado de Edwards e Bramante (2009, p. 264)

Camada de rede

Camada de ligação

Camada física

Camada de rede

Media Access Control

Camada física

Logical Link Control

Restantes camadas

do modelo OSI

Restantes camadas do

standard IEEE 802.3



3.4.1. LOGICAL LINK CONTROL (LLC)

A camada LLC faz o controlo efectivo da taxa de transmissão entre dois nós que estão a

comunicar, impedindo assim que o nó transmissor envie dados com uma velocidade

superior à velocidade de recepção. O controlo de fluxo, durante a recepção de dados de

múltiplos nós, depende do feedback dado pelo receptor ao transmissor. O feedback é

dado através de uma frame de pausa (pause frame) que permite parar a transmissão por

um determinado período de tempo, esta frame é unicamente utilizada em comunicações

full-duplex55 (Figura 40). As comunicações em half-duplex56 (Figura 41) não permitem

este feedback pois o receptor neste caso enquanto recebe dados não consegue enviar

(Edwards e Bramante, 2009, p. 265).

Figura 40 – Representação de uma ligação full-duplex

Figura 41 – Representação de uma ligação half-duplex

3.4.2. MEDIA ACCESS CONTROL (MAC)

A camada MAC faz a interligação entre a subcamada LLC e a camada física, é a

responsável pelo encapsulamento e desencapsulamento dos dados e verificação dos

erros nas frames recebidas (Edwards e Bramante, 2009, p. 265). Esta faz também

identificação de cada nó através da atribuição de um endereço MAC (MAC address). O

endereço MAC deve ser diferente para cada unidade de rede de forma a não gerar

conflitos, este endereço é constituído por 12 dígitos hexadecimais agrupados 2 a 2 (e.g.

00 23 54 80 CA D3). O mesmo endereço MAC em dois dispositivos distintos vai fazer

com que exista uma incompatibilidade na entrega de dados na rede.

55

Full-duplex é definido como a capacidade de enviar e receber em simultâneo. 56

Half-duplex é definido como a capacidade de um nó apenas poder ter dois estados: receber ou enviar. Não podendo enviar e receber em simultâneo.



3.4.2.1. CSMA/CD

O mecanismo Carrier Sense Multiple Access with Collision Detection (CSMA/CD) envia

um sinal que interfere com as restantes estações na rede (sinal de jamming57 constituído

por 48 bits), sempre que é detectado outro sinal no meio. Este sinal de jamming avisa

todos os nós da rede que ocorreu uma colisão e não poderão transmitir por um

determinado período de tempo, este período de tempo é baseado no algoritmo

exponential backoff. O algoritmo exponential backoff faz com que os intervalos de

transmissão entre nós sejam aleatórios, fazendo com que a probabilidade de voltar a

existir uma colisão entre nós seja muito baixa (Edwards e Bramante, 2009, p. 266 e 267;

SENA, 2002, p. 7; Kurose e Ross, 2004, p. 406).

O espaçamento máximo entre dois nós próximos é imposto pelo standard da norma nos

100 metros. Esta distância á a distância máxima para assegurar que se for escolhido o

menor tempo possível, utilizando o algoritmo de exponential backoff, as estações

conseguem comunicar entre si sem ocorrer uma nova colisão de dados (Kurose e Ross,

2004, p. 406).

3.5. A NORMA IEEE 802.11G

As normas IEEE 802.11 iniciais estabelecem taxas de transmissão de 1 Mbps e de 2

Mbps, com 3 camadas físicas distintas. As três camadas físicas são as seguintes (Vassis,

Kormentzas, Rouskas e Maglogiannis, 2005, p. 1; Xu e Saadawi, 2001, p. 2; Carney,

2002, p. 1; Walke, Mangolg e Berlemann, 2006, p. 103):

DSSS (Direct Sequence Spread Spectrum);

FHSS (Frequency Hopping Spread Spectrum);

IR (Infrared).

As operações das camadas físicas DSSS e FHSS são especificadas para a banda dos

2,4 GHz, e esta é uma banda de frequência ISM58. O espectro de frequências da norma

IEEE 802.11 é o seguinte:

57

Normalmente em português jamming é traduzido na palavra empastelamento. 58

ISM é um acrónimo de Industrial, Scientific and Medical. São bandas de frequência reservadas, internacionalmente, para uso industrial, científico e médico. Os aparelhos de comunicação ao serem construídos devem aceitar interferências provenientes de outros equipamentos, e conseguir operar sem limitações.



Figura 42 – O espectro de frequências utilizado pela norma IEEE 802.11 Fonte: Walke, Mangolg e Berlemann (2006, p. 103).

Os canais 1,6 e 11 (Figura 42) não se sobrepõem entre si, sendo estes os canais que se

devem utilizar se existir mais do que um dispositivo a operar nesta norma na vizinhança.

Os canais que não se sobrepõem possibilitam uma diminuição das interferências mútuas

entre canais, possibilitando teoricamente uma melhor relação SNR do que a obtida ao

utilizar canais que se sobrepõem.

As estações de comunicação, ao usar a camada física FHSS, operam numa frequência

comum por um curto período de tempo antes de seleccionarem outro canal de

comunicação (Figura 42). As estações operam assim numa sequência pseudo-aleatória,

reduzindo a probabilidade de outras estações utilizarem o mesmo canal no mesmo

período de tempo, diminuindo assim a interferência mútua (Walke, Mangolg e Berlemann,

2006, p. 83; Olexa, 2005, p. 59).

Figura 43 – Frequency Hopping Spread Spectrum (FHSS)

Fonte: Olexa (2005, p. 59).



A camada física DSSS, ao contrário da camada física FHSS, faz com que as estações de

comunicação operem na mesma frequência central. O envio é feito recorrendo a códigos

pseudo-aleatórios utilizados para espalhar a portadora, resultando um sinal que está tão

separado que pode ser indistinguível face e.g. à existência de ruído térmico59. O receptor

recebe este sinal e amplifica-o recuperando-o através do mesmo código utilizado no

transmissor, obtendo desta forma o sinal original (Olexa, 2005, p. 59; Walke, Mangolg e

Berlemann, 2006, p. 83).

Figura 44 – Representação do funcionamento do Direct Sequence Spread Spectrum (DSSS)

Fonte: Olexa (2005, p. 59).

A evolução desta norma fez com que surgisse as especificações a, b e g. A norma IEEE

802.11b permite velocidades de transmissão de 11 Mbps na banda dos 2,4 GHz. A

norma IEEE 802.11a especifica uma norma wireless na banda dos 5 GHz, com

velocidade de transmissão até 54 Mbps, tendo como principal desvantagem não ser

compatível com os equipamentos baseados na norma IEEE 802.11b e IEEE 802.11g

(Vassis, Kormentzas, Rouskas e Maglogiannis, 2005, p. 1;Carney, 2002, p. 2)

A norma IEEE 802.11g combina as vantagens existentes na norma IEEE 802.11b ao

utilizar a mesma banda de frequências (2,4 GHz) e da norma IEEE 802.11a ao conseguir

iguais taxas de transmissão máximas teóricas (54 Mbps) (Walke, Mangolg e Berlemann,

2006, p. 116). A grande vantagem desta norma é a interoperabilidade com a norma IEEE

802.11b.

59

A existência deste tipo de ruído é inevitável e deriva dos movimentos dos electrões, acima do valor de temperatura considerado o zero absoluto (0º K).



O espectro de frequência dos 2,4 GHz é um espectro de frequência altamente saturado,

ao contrário do espectro dos 5 GHZ. O espectro dos 5 GHz permite também a existência

de mais canais, disponibilizando assim suporte para mais utilizadores (Zyren, 2001, p. 1).

A principal desvantagem seria a perda de compatibilidade com a norma IEEE 802.11b.

As principais características da norma IEEE802.11g, face às versões anteriores, são as

seguintes (Vassis, Kormentzas, Rouskas e Maglogiannis, 2005; Society, 2008):

Existência de 4 camadas físicas distintas;

O suporte obrigatório de um short preamble style;

O atributo de rede Extended Rate Physicals (ERP);

Novos mecanismos de protecção que lidam com aspectos de interoperabilidade;

O mecanismo CTS-to-self.

Os subcapítulos seguintes descrevem cada um dos pontos referidos anteriormente,

possibilitando assim compreender o funcionamento da norma IEEE 802.11g.

3.5.1. EXISTÊNCIA DE 4 CAMADAS FÍSICAS DISTINTAS

A norma IEEE 802.11g permite implementar a tecnologia DSSS, OFDM ou as duas em

simultâneo. As quatro camadas existentes encontram-se definidas no standard da norma

como Extended Rate Physicals (ERP), coexistindo durante a troca de dados por parte do

transmissor e do receptor. A escolha de uma das quatro camadas disponíveis depende

do transmissor e do receptor, devendo a camada escolhida ser suportada por ambos. As

quatro camadas distintas presentes nesta norma são as seguintes (Vassis, Kormentzas,

Rouskas e Maglogiannis, 2005, p. 21; Walke, Mangolg e Berlemann, 2006, p. 115):

ERP – DSSS/CCK: Camada física semelhante à utilizada pela norma IEEE802.11b,

sendo a tecnologia DSSS utilizada com uma modulação Complementary Code Keying

(CCK).

Figura 45 – Uso da técnica CCK para a transmissão do Preâmbulo/Cabeçalho (Preamble/Header)

e para os dados constituintes da comunicação (Payload) Fonte: Zyren (2001, p. 4).

ERP – OFDM: Esta apresenta-se como uma nova camada física introduzida pela norma

IEEE802.11g, esta camada física é utilizada para providenciar transmissões da ordem

dos 54 Mbps na frequência dos 2,4 GHz.



Figura 46 – Uso da técnica OFDM para a transmissão do Preâmbulo/Cabeçalho (Preamble/Header) e para os dados constituintes da comunicação (Payload)

Fonte: Zyren (2001, p. 5).

ERP – DSSS/PBCC: Esta camada física foi introduzida na norma IEEE802.11b e

providencia a mesma taxa de transmissão da DSSS/CCK, utilizando para isso a

tecnologia DSSS com o algoritmo de codificação Packet Binary Convolutional Coding

(PBCC).

Figura 47 – Uso da técnica DSSS/PBCC para a transmissão híbrida do Preâmbulo/Cabeçalho (Preamble/Header) e para os dados constituintes da comunicação (Payload)


DSSS - OFDM: Esta camada usa uma combinação híbrida da camada física DSSS e

OFDM. O cabeçalho do pacote é transmitido usando DSSS, enquanto o pacote é

transmitido usando OFDM.

Figura 48 – Uso da técnica DSSS - OFDM para a transmissão híbrida do Preâmbulo/Cabeçalho (Preamble/Header) e para os dados constituintes da comunicação (Payload)


Figura 49 – Elementos obrigatórios e opcionais da norma IEEE 802.11g Fonte: Adaptado de Zyren (2001, p. 3)

Os dispositivos que utilizam a norma IEEE 802.11g devem suportar as duas primeiras

camadas (Figura 49), sendo as duas últimas opcionais (Vassis, Kormentzas, Rouskas e

Maglogiannis, 2005, p. 22).

A camada física Orthogonal Frequency Division Modulation (OFDM) é uma técnica que

permite o envio de dados, utilizando um grande número de pequenos canais que se

Obrigatório

Opcional



sobrepõem. Os canais utilizados encontram-se sobrepostos e possuem a sua portadora

específica, estes estão espaçados igualmente em frequências precisas para providenciar

ortogonalidade (Cada portadora difere da sua adjacente em precisamente um ciclo) -

Figura 50 e 51. Esta técnica previne que os desmoduladores na recepção vejam

frequências que não correspondem à frequência real de envio (Olexa, 2005, p. 62; Walke,

Mangolg e Berlemann, 2006, p. 25). A OFDM é uma técnica já conhecida e utilizada mas

existiam regulamentações - FCC60 regulations - que não permitiam o seu uso na banda

de frequências dos 2,4 GHz, isto foi modificado em Maio de 2001 e ainda é permitida a

sua utilização nos dias de hoje (Zyren, 2001, p. 4).

A informação é transportada em cada portadora de uma forma paralela, modificando a

sua fase, amplitude ou ambas (Gomez, 2001, p. 11). O envio é efectuado em simultâneo

de acordo com as frequências de cada portadora, sendo efectuado o envio de uma forma

paralela (Aspinwall, 2003, p. 371).

A interferência resultante de multi-percurso é assim diminuída utilizando a técnica OFDM,

esta diminuição deve-se ao aumento do tempo utilizado na transmissão de cada símbolo

face ao envio de um símbolo de cada vez (Chakravarthy, Nunez e Stephens, 2005, p. 11

e 12).

Figura 50 – Representação das múltiplas portadoras utilizando a técnica de OFDM (A) Fonte: Adaptado de Zyren (2001, p. 4).

Figura 51 – Representação das múltiplas portadoras utilizando a técnica de OFDM (B) Fonte: Adaptado de Gomez (2001, p. 11).

60

Federal Communications Commission (FCC) é um órgão regulador, situado nos Estados Unidos, que permite o controlo da área das comunicações e radiodifusão.

Frequência

Largura de banda do sinal

Múltiplas Portadoras



A técnica descrita anteriormente como CCK (complementary code keying) é baseada

numa modulação básica, tendo sido inicialmente implementada na norma IEEE 802.11b.

Esta técnica permite o envio de dados utilizando uma única portadora, sendo o formato

da portadora o seguinte:

Figura 52 – Representação da portadora na técnica CCK Fonte: Adaptado de Zyren (2001, p. 4).

A técnica descrita anteriormente com Packet Binary Convolutional Coding (PBCC) é, à

semelhança da técnica CCK, baseada na utilização de uma única portadora para o envio

de dados. A técnica PBCC aplica um envio de dados envolvendo 8 níveis de mudança de

fase (8-PSK61), ou seja, a sua fase pode tomar 8 valores distintos no envio (Zyren, 2001,

p. 6). A taxa máxima de despacho teoricamente disponível utilizando esta técnica é de

aproximadamente de 33 Mbps (Tabela 8).

3.5.2. O SUPORTE OBRIGATÓRIO DE UM SHORT

PREAMBLE STYLE

O envio de dados é sempre precedido pelo envio de um preâmbulo e de um cabeçalho,

apresentando a norma IEEE 802.11b um preâmbulo demasiado longo. O desempenho da

norma IEEE 802.11g foi aumentado criando um preâmbulo curto (short preamble), sendo

a sua utilização obrigatória na nova norma (Vassis, Kormentzas, Rouskas e

Maglogiannis, 2005, p. 22). A comparação entre os tempos de envio e o tamanho dos

preâmbulos é feito na Tabela 8.

61

Phase shift key.

Frequência

Largura de banda do sinal

Única Portadora



Camada física

Taxas de transferência suportadas

Atraso no envio do preâmbulo e cabeçalho

Tamanho do preâmbulo e cabeçalho

Longo Curto Longo Curto ERP-DSSS (Obrigatório)

1;2;5,5;11 192 s 96 s 192 Bits 120 Bits

ERP-OFDM (Obrigatório)

6;9;12;18;24;36;48;54 20 s 40 Bits

ERP-PBCC (Opcional)

1;2;5,5;11;22;33 192 s 96 s 192 Bits 120 Bits

DSSS-OFDM (Opcional)

6;9;12;18;24;36;48;54 192 s 96 s 192 Bits 120 Bits

Tabela 8 – Parâmetros das diferentes camadas físicas da norma IEEE802.11g Fonte: Adaptado de Vassis, Kormentzas, Rouskas e Maglogiannis (2005, p. 22).

3.5.3. O ATRIBUTO DE REDE EXTENDED RATE

PHYSICALS (ERP)

Os valores padrão para o tempo de cada slot62 e janela de contenção63 para a norma

IEEE 802.11b são de 20 s e de 31 slots respectivamente. A norma IEEE 802.11g

manteve estes valores para conseguir assegurar a interoperabilidade entre normas, mas

no entanto estes valores não estão optimizados para velocidades de transferência de

dados de 54 Mbps. O atributo de rede ERP surge deste problema, permitindo um ajuste

dinâmico dos valores de tempo de slot e tamanho da janela de contenção através do

envio de uma frame de controlo que contém informação sobre a rede. A capacidade

descrita anteriormente apenas se verifica para redes que tenham suporte ERP, como é o

caso e.g. de uma rede com suporte ERP-OFDM (Vassis, Kormentzas, Rouskas e

Maglogiannis, 2005, p. 22).

Comunicação Preâmbulo Tempo de cada slot Janela de contenção mínima (slots) ERP-ERP ERP-OFDM 20 s 31

ERP-non-ERP/S Curto 20 s 31

ERP-non-ERP/L Longo 20 s 31

Non-ERP/S-non-ERP/S Curto 20 s 31

Non-ERP/S-non-ERP/L Longo 20 s 31

Non-ERP/L-non-ERP/L Longo 20 s 31

All ERP ERP-OFDM 9 s 15

Tabela 9 – Parâmetros físicos para diferentes cenários de comunicação Fonte: Adaptado de Vassis, Kormentzas, Rouskas e Maglogiannis (2005, p. 23).

62

Tempo atribuído a um determinado sistema para recepção de informação, mesmo que esteja a receber de uma única origem esta recepção é feita em múltiplos slots de tempo dependendo da quantidade de dados a transmitir. 63

Nome dado a um conjunto de slots específicos, sendo o tamanho desta janela variável de acordo com a situação e algoritmo utilizado.



3.5.4. ASPECTOS DE INTEROPERABILIDADE

Os três tipos de estações (resumidas na Tabela 9) que podem coexistir são os seguintes

(Vassis, Kormentzas, Rouskas e Maglogiannis, 2005, p. 23):

Estações que suportam ERP;

Estações que não suportam ERP, mas que suportam short preamble;

Estações que não suportam ERP e que não suportam short preamble.

A existência de vários tipos de estações pode gerar problemas de interoperabilidade, pois

estas podem não conseguir comunicar entre si. A utilização de DSSS-OFDM é uma

solução pois as estações de destino têm a capacidade de receber dados em OFDM, e as

restantes estações interpretam o preâmbulo e o cabeçalho abstendo-se de transmitir

(evitando assim colisões no meio) mesmo que não detectem a transmissão OFDM. Os

mecanismos RTS/CTS (Request To Send/Clear To Send) e CTS-to-self são as

alternativas existentes, sendo abordados no próximo subcapítulo.

3.5.5. O MECANISMO CTS-TO-SELF

O mecanismo CTS-to-self é utilizado como uma alternativa ao RTS/CTS (Request to

send/Clear to send). Os dois mecanismos estão representados na Figura 53, estando o

mecanismo RTS/CTS representado no lado esquerdo e o mecanismo CTS-to-self

representado no lado direito da figura.

A figura 53 (a) representa o envio de um pacote da estação “A” para a estação “C”

utilizando o mecanismo RCS/CTS, este tem de enviar uma frame RTS (seta 1) para

informar as outras estações da sua intenção de enviar um pacote para o meio de

transmissão. A frame enviada é recebida por “B” e “C” (setas com o número 2), pois

estão na área de alcance da estação que vai efectuar o envio, estas ao receberem a

frame RTS enviam frames CTS (setas 3). A frame CTS é utilizada para informar que a

estação não se encontra a transmitir e que o meio está desimpedido para o envio da

estação “A”. As frames enviadas são recebidas por todas as estações na rede (setas 4),

mesmo por aquelas que no início não tinham recebido a frame RTS da estação “A” por

estarem fora do seu alcance (Vassis, Kormentzas, Rouskas e Maglogiannis, 2005, p. 23).



Figura 53 – (a) RTS/CTS e (b) CTS-to-self Fonte: Vassis, Kormentzas, Rouskas e Maglogiannis (2005, p. 23).

A Figura 53 (b) representa a utilização do mecanismo CTS-to-self. A estação “A” quando

quer enviar um pacote para a estação “C”, envia um frame CTS (seta 1), e esta ao ser

recebida pela estação “B” e “C” (setas 2) faz com que as estações adiem as suas

transmissões. A estação “D” não está no alcance de transmissão da estação “A”, ou seja,

não vai receber qualquer indicação que no meio se encontra a ocorrer uma transmissão.

O método CT-to-self apresenta esta clara desvantagem, e apenas deve ser utilizado

quando todas as estações conseguem comunicar entre si. A comunicação entre todas as

estações evita a existência de estações escondidas (não detectadas) (Vassis,

Kormentzas, Rouskas e Maglogiannis, 2005, p. 23).

3.5.6. O DÉBITO REAL - IEEE 802.11G

Os valores normalmente referidos como taxas máximas de transferência de dados são os

valores teoricamente esperados ao nível da camada física, ou seja, não representam a

taxa de transferência de dados disponível ao nível do utilizador (camada de aplicação). A

taxa de transferência ao nível do utilizador vai diminuir de acordo com as necessidades

de processamento das restantes camadas até chegar à camada de aplicação,

Os testes aos valores efectivos obtidos foram efectuados pela Atheros (Atheros, 2003),

esta empresa representa uma das maiores empresas de fabricantes de chipsets para a

norma IEEE 802.11a. Os valores obtidos foram os seguintes:



Protocolo

Números de canais

que não se sobrepõem

Modulação Taxa de

transferência máxima

Taxa de transferência máxima teórica usando

TCP

Taxa de transferência máxima teórica usando

UDP

802.11b 3 CCK 11 Mbps 5,9 Mbps 7,1 Mbps

802.11g (com

802.11b) 3 OFDM/CCK 54 Mbps 14,4 Mbps 19,5 Mbps

802.11g (apenas)

3 OFDM/CCK 54 Mbps 24,4 Mbps 30,5 Mbps

802.11a 19 OFDM 54 Mbps 24,4 Mbps 30,5 Mbps

Tabela 10 – Representação da taxa efectiva IEEE 802.11 Fonte: Adaptado de Atheros (2003, p. 1).

Os valores para as taxas de transmissão obtidos são de 24,4 Mbps para comunicações

em TCP e de 30,5 Mbps para comunicações em UDP (Tabela 10). Os valores da Tabela

10 foram obtidos através de testes efectuados em condições óptimas, em terminais

parados e muito próximos do ponto de acesso wireless.

Taxa de dados efectiva

Taxa de dados na camada física (5)

A análise dos resultados expostos leva a que se chegue à relação representada pela

equação 5, em que a taxa de transferência de dados efectiva é de aproximadamente

metade da taxa de transferência de dados da camada física.

3.6. COMO ANALISAR A PERFORMANCE DE UMA REDE

A taxa de despacho e a latência64 apresentadas por uma rede afectam a sua

performance, quer esta seja baseada num protocolo de comunicação sem fios (wireless)

ou com fios (Kozierok, 2005, p. 95-98).

A performance é um conceito muito importante e depende da aplicação, ou seja, depende

do que se pretende implementar pois as características requeridas para sistemas

distintos raramente são as mesmas. As características normalmente requeridas para uma

rede são: elevada velocidade, grande largura de banda, elevada taxa de despacho e

baixa latência.

A largura de banda (bandwith) dá uma indicação da quantidade máxima de dados que

conseguimos enviar de um ponto para outro, estando limitada e.g. nas comunicações

wireless pelo espectro de radiofrequência (espectro RF) utilizado. A taxa de despacho

(throughput) é caracterizada como a quantidade de dados que consegue circular na rede

por uma determinada unidade de tempo, sendo esta taxa de despacho limitada pelo

conceito de largura de banda. Estas características devem resultar num factor

64

Diferença de tempo entre um pedido à rede e sua respectiva resposta.



denominado por qualidade de serviço (Quality of service - QoS) aceitável, que neste

âmbito específico representa a relação entre a largura de banda e a capacidade

apresentada para efectuar uma entrega de dados fiável (reliable).

O tipo de protocolo utilizado numa determinada aplicação não garante sempre a mesma

performance, temos sim um intervalo esperado de algumas variáveis como e.g. a taxa de

despacho podendo assim tentar inferir o comportamento esperado (QoS mínimo

esperado). A obtenção de valores concretos, recorrendo a software adequado, é

essencial.

O software disponível para análise redes de computadores é dividido em função dos seus

objectivos da seguinte forma (Burns, 2003, p. 29-65):

Gestão do desempenho e simulação (Performance management and

simulation);

Analisadores de protocolo (Protocol analysers).

As aplicações cliente/servidor são bastante utilizadas nos dias de hoje, originando a

necessidade do aparecimento de software capaz de analisar a performance apresentada

pela rede, com o objectivo de garantir um nível de serviço mínimo aos utilizadores. O

software do tipo performance management and simulation pode ser dividido em dois

subtipos, um denominado por active management (gestão activa) e outro por passive

management (gestão passiva).O primeiro subtipo de software faz a análise através da

simulação de alguns parâmetros de teste (e.g. introdução de tráfego na rede), e

consegue assim aferir o desempenho apresentado. O segundo subtipo de software faz a

análise através da escuta permanente do que se está a passar na rede e,

simultaneamente, efectua uma análise ao seu comportamento. A análise efectuada tem

por base os parâmetros de funcionamento da rede, sem recorrer a qualquer parâmetro

externo.

O software pode também ser do tipo protocol analyzer, que possibilita, com base no

conhecimento do protocolo utilizado, representar os dados de acordo com os tipos de

estrutura de pacotes utilizados, no envio e respectiva recepção. O termo protocol

analyser, referido anteriormente, é utilizado para designar um software que executa uma

análise aos pacotes enviados na rede (packet analysis). O real funcionamento da rede

pode ser percebido utilizando este tipo de software, não existindo segredos a este nível

(Sanders, 2007, p. 23). O software Wireshark65 e OmniPeek66 são do tipo protocol

65

Site oficial http://www.wireshark.org/.

http://www.wireshark.org/



analyzer, existem outros com as mesmas potencialidades mas os referidos anteriormente

foram os utilizados nos testes efectuados.

A elaboração dos cálculos estimados é uma alternativa à utilização de software, mas para

a elaboração destes é necessário contemplar todos os factores existentes na

comunicação e que podem influenciar a performance da rede (Jun, Peddabachagari e

Sichitiu, 2003). O recurso a software apropriado permite ultrapassar esta dificuldade e

analisar o caso particular de estudo com relativa facilidade.

3.6.1. INTERFERÊNCIAS EM REDES DE COMPUTADORES

O sistema de detecção de interferências descrito em 1976 por Robert Metcalfe e David

Boggs (Robert Metcalfe e David Boggs, 1976, p. 398), fazia com que cada

transmissor/receptor tivesse a capacidade de detectar a diferença entre o bit recebido e o

enviado. Este apresentava as seguintes vantagens:

A colisão ao ser detectada fazia com que a estação de recepção soubesse qual o

pacote que foi danificado e agendasse a sua imediata retransmissão;

A informação das interferências na rede pode ser utilizada para poder estimar o

tráfego na rede e reajustar os intervalos de retransmissão, possibilitando assim

aumentar a eficiência do canal de transmissão.

As colisões podem ser diminuídas, diminuindo as interferências e fazendo com que

existam menos pacotes retransmitidos. A existência de menos pacotes retransmitidos

reduz o consumo da rede e aumenta o seu tempo de vida (Johansson e Carr-Motycková,

2005, p. 1). As redes de sensores com alimentações limitadas podem ver assim

aumentado o ser desempenho.

As redes de sensores wireless têm uma elevada probabilidade de ter interferências

mútuas entre os sensores utilizados, pois na maioria das vezes a transmissão é

efectuada com potências bastante elevadas (comparado com o necessário) e com

antenas omnidireccionais (Moscibroda e Wattenhofer, 2005, p. 1). A utilização de uma

menor potência de transmissão tem vantagens em termos de gastos energéticos, mas ao

diminuir o alcance da comunicação wireless faz com que determinados nós possam

deixar de comunicar. Este factor pode levar ao abandono da ligação entre alguns nós da

66

Site Oficial http://www.wildpackets.com/products/network_analysis/omnipeek_network_analyzer.

http://www.wildpackets.com/products/network_analysis/omnipeek_network_analyzer



rede, não podendo diminuir a potência de uma forma aleatória, mas sim de uma forma

fundamentada.

O sistema de telemetria que se pretende elaborar deve ser correctamente projectado,

pois as colisões entre os pacotes que circulam na rede devem ser diminuídas ao máximo.

Ao existirem colisões de pacotes faz com que seja necessário efectuar retransmissões

dos dados perdidos, o que pode saturar a rede de pacotes teoricamente desnecessários.

Figura 54 – Topologia de rede básica a utilizar

O aumento do número de sensores faz com que mais dados tenham de ser recolhidos

dos Dataloggers e mais dados tenham de ser enviados para o módulo de envio67 (Figura

54). Os dados enviados para o módulo de envio podem originar um atraso no envio

fazendo com que o buffer68 de entrada do router seja excedido e por conseguinte os

pacotes a enviar sejam perdidos.

3.7. SENSORES DE REDE

Um sistema de sensores de rede tem a vantagem de permitir a vários utilizadores,

através da partilha de uma única comunicação, aceder a dados provenientes de várias

origens. Os utilizadores podem estar em posições geográficas diferentes, bastando que

tenham ligação à respectiva rede. A ligação descrita pode ser por wireless ou por fio,

dependendo do protocolo de rede utilizado, e pode também ser híbrida (utilização de

vários protocolos).

67

Os módulos de envio, neste caso concreto de estudo, proporcionam o envio de dados que circulam em fio para wireless. 68

Memória utilizada de forma temporária para leitura e escrita de dados.

Sensores (Nível 3)

Dataloggers (Nível 2)

Módulo de Envio (Nível 1)



O sensor de rede é constituído por duas partes distintas: um módulo destinado à

aquisição (sensor) e outro destinado à comunicação (interface entre o sensor e a rede)

(Figura 55) (Crovella, 1999, p. 1). A comunicação em rede pode também ser feita por

uma unidade de conversão com a capacidade de comunicar em rede, esta unidade

normalmente efectua também a conversão de analógico para digital e faz o envio desses

dados (e.g. Datalogger com interface Ethernet). O Datalogger normalmente adquire

dados provenientes de vários sensores o que em termos de redundância pode ser

prejudicial pois caso essa unidade de aquisição seja danificada, ou fique de alguma

forma inoperacional, é perdida a possibilidade de adquirir dados não de apenas um

sensor mas de variadíssimos sensores.

Figura 55 – Sensor com componente para comunicar em rede Fonte: Adaptado de Crovella (1999, p. 2).

A aquisição de dados de múltiplos sensores utilizando uma comunicação de rede

também tem vantagens, pois diminui o número de fios necessários para efectuar a

transmissão de dados entre dois pontos (Crovella, 1999, p. 2).

O controlo de erros deve ser feito neste tipo de redes, e mais importante que isso,

devem-se dotar as redes com capacidade de efectuar um isolamento dos erros (Crovella,

1999, p. 6 e 7). Ou seja, dotar as redes com capacidade de detecção e isolamento dos

componentes de rede que apresentam problemas. A detecção e isolamento de erros

permite que a rede continue a comunicar mesmo quando existem componentes

degradados e a gerar enormes quantidades de erros, introduzindo assim redundância no

sistema.

Sensor

Interface sensor/rede Variável medida

Rede de comunicação

Sinal eléctrico representativo da variável medida




O conceito de telemetria foi abordado neste capítulo, dando assim as bases teóricas para

o seu entendimento.

A distribuição dos dados, após a sua aquisição por parte de Dataloggers com interface de

rede, é efectuada recorrendo ao protocolo IEEE 802.3 e posto isto tornou-se essencial

abordar este protocolo. O modelo TCP/IP e OSI mostraram-se os pontos de partida para

a abordagem dos protocolos de rede utilizados neste sistema de telemetria (IEEE 802.3 e

IEEE 802.11g).

A comunicação sem fios a vai-se fazer recorrendo ao protocolo IEEE 802.11g, sendo feito

neste capítulo um estudo sucinto sobre o seu funcionamento e como a troca de

informação se processa. A taxa de transferência efectiva que se poderá esperar por TCP

e UDP ao nível do utilizador (camada de aplicação) foi abordada, baseada em estes

práticos efectuados pela Atheros Corporation.

A abordagem dos diferentes tipos de software efectuada neste capítulo demonstrou a

forma como é possível analisar a performance de uma rede, sendo este o modo de

análise utilizado nos testes efectuados.

As interferências em redes de computadores são também analisadas neste capítulo,

terminando o capítulo com um subcapítulo dedicado aos sensores em rede abordando a

sua constituição e vantagens.


4. CAPÍTULO IV

IMPLEMENTAÇÃO DO SISTEMA

4.1. INTRODUÇÃO

Torna-se importante neste capítulo, e no seguimento do trabalho que tem sido efectuado,

descrever o material escolhido e adquirido para constituir o sistema final. Neste capítulo

vão também ser descritas as modificações mais importantes feitas ao material adquirido,

descrevendo assim como foram feitas.

A ferramenta de baixo custo utilizada como alternativa aos Dataloggers adquiridos vai ser

descrita neste capítulo, e vai também ser utilizada em algumas das experiências

efectuadas - Arduino69. A descrição deste vai ser feita, primariamente, em termos de

capacidade de conversão A/D, velocidade de aquisição de dados e alguns parâmetros de

funcionamento O agregado planar 4x4 desenhado e fabricado vai também ser

sucintamente descrito, este foi desenvolvido com vista a ser um substituto à antena

omnidireccional adquirida. Ao utilizar uma antena direccional com um maior ganho face à

antena omnidireccional adquirida no mercado, espera-se assim aumentar o alcance

obtido por wireless na comunicação entre o navio alvo e o navio responsável por efectuar

a respectiva monitorização.

O capítulo vai ser finalizado com uma análise teórica ao problema de estudo,

evidenciando algumas das dificuldades esperadas.

4.2. MATERIAL OFF-THE-SHELF UTILIZADO

O material foi adquirido tendo em conta os requisitos iniciais idealizados para o sistema,

em que seria necessário a aquisição de antenas, amplificadores, routers, Dataloggers,

sensores, placas de desenvolvimento com microcontrolador - Arduino Duemilinove,

webcam e camera de alta velocidade. A EN e a DN disponibilizaram os fundos

necessários para adquirir o material descrito na seguinte tabela:

69

Site oficial http://www.arduino.cc.

http://www.arduino.cc/



Função no Sistema Modelos Adquiridos Fabricante Antenas OMNI H Ferimex

Router WRT54GS v. 7

Linksys WRT54GL v. 1.1

Dataloggers DI-710-EL Dataq Instruments

Arduino Duemilinove Tinker

Sensores Acelerómetros

ADXL 321 Analog Devices

ADXL 203

MMA 7260 Freescale Semiconductor

Termopares JQSS-IM30E-300 Omega

Webcam TV-IP 100

TRENDnet TV-IP 110

Camera de Alta Velocidade GC640C Prosilica

Sensores de pressão MPX2100 Motorola Semiconductor

MPX5999D Freescale Semiconductor

Tabela 11 – Material adquirido para a constituição do sistema final

Algum do material adquirido, e à medida que foram efectuados testes ao equipamento, foi

configurado de forma a aumentar o seu desempenho. As modificações efectuadas foram

desde a actualização do firmware de equipamentos a testes à leitura de todos os

sensores utilizando os equipamentos adquiridos. Os testes efectuados e considerados

relevantes para este estudo vão ser aprofundados com mais rigor no capítulo V,

descrevendo as modificações efectuadas, pormenores relevantes e montagens

efectuadas para cada um.

4.2.1. ROUTER UTILIZADO

Os routers adquiridos foram da marca Linksys70, correspondendo ao modelo WRT54GS

(versão 7) e WRT54GL (versão 1.1). Esta escolha prendeu-se não só com as suas

características em termos de hardware, mas também com a sua reconhecida

compatibilidade com o firmware open source - DD-WRT (Asadoorian e Pesce, 2007, p.

53-108). Este permite expandir as funcionalidades do firmware proprietário de origem,

tornando o router numa ferramenta facilmente configurável e acessível. Algumas das

suas características, são facilmente descritas pela tabela seguinte, de acordo com o seu

site oficial (GmbH, 2009):

Características Principais

Suportado por mais de 200 aparelhos distintos

User Friendly

Suporta todos os protocolos wireless actuais

Pode ser aplicado ao exterior

Integração VPN71

Suporta o controlo da largura de banda

Interface em várias línguas

Podem ser variados parâmetros de funcionamento

Tabela 12 – Algumas das características mais relevantes do firmware - DD-WRT Fonte: Adaptado de GmbH (2009).

70

Marca pertencente à Cisco, uma companhia multinacional sediada em San José na Califórnia. 71

VPN – Virtual private network é usado para referir uma rede de comunicações privada normalmente utilizada por uma empresa/instituição, construída utilizando uma rede de comunicações pública (e.g. a internet).

Capitulo IV – Implementação do sistema


Figura 56 – Imagem de um router Linksys WRT54GS (versão 7)

.A mudança de firmware teve como principal objectivo a capacidade de configurar o router

como cliente de uma rede e baseou-se numa pré-análise de Asadoorian e Pesce (2007,

p. 53-108), em que é efectuada uma abordagem a inúmeros firmwares não proprietários

existentes para a marca e modelos especificados anteriormente. Este firmware foi

escolhido devido às suas funcionalidades, enorme facilidade de configuração e instalação

(Tabela 12).

4.2.2. SENSOR DE TEMPERATURA - TERMOPAR

Os termopares constituem meios baratos e precisos de determinar a temperatura

(Pollock, 1993, p. 229). Estes baseiam-se num fenómeno conhecido como efeito Seebeck

(ou efeito termoeléctrico) para fazer a respectiva transformação de energia térmica para

eléctrica.

O efeito Seebeck foi verificado em 1821 por Thomas Johan Seebeck (1770 – 1831), que

comprovou que uma corrente circula num circuito fechado composto por dois condutores

diferentes, gerando uma f.e.m. (força electromotriz, normalmente da ordem dos mV)

distinta entre os seus terminais, normalmente designada por tensão termoeléctrica.

Todos os termopares possuem duas junções, uma junção de medição e uma junção de

referência (Pollock, 1993, p. 229; Wilson, 2005, p. 533).

Figura 57 – Representação do princípio de Seebeck

Fonte: Adaptado de Pollock (1993, p. 230).

A utilização de junções feitas com materiais que tenham um comportamento regular em

função da temperatura, dentro da gama de medição de interesse, possibilita ter um

sensor de temperatura com uma elevada precisão.

A

B

T T + T



A junção de referência é normalmente colocada a 0º C (designado por ponto de gelo - ice

point), ou é simulado através utilização de um circuito integrado (e.g. AD594 da Analog

Devices) (Pollock, 1993, p. 230). O integrado AD594 coloca na junção de referência uma

tensão representativa dos 0 ºC, permitindo assim que o sinal da junção de medição seja

referenciado a esses 0 ºC. Este método permite que a temperatura medida corresponda

à temperatura absoluta (Devices, 1999, p. 8).

Figura 58 – Representação do princípio de Seebeck

Fonte: Adaptado de Devices (1999, p. 8).

O modelo de termopar adquirido foi o JQSS-IM15E-300 da Omega, sendo este um

termopar do tipo J (Tabela 13). Este termopar é constituído por uma conjugação de ferro

e constantan (material constituído por uma liga de cobre - 58 % - e níquel - 42 %),

estando indicado para medição num intervalo de temperatura de 0 a 750 ºC (Tabela 13).

A relação entre os vários tipos de termopares existentes, dependendo do tipo de material

combinado, encontram-se representados na seguinte tabela:

Tipo de termopar Gama de temperatura º C Limites de erro standard T 0 a 350 1 ºC ou 0,75%

J 0 a 750 2,2 ºC ou 0,75%

E 0 a 900 1,7 ºC ou 0,5%

K 0 a 1250 2,2 ºC ou 0,75%

R ou S 0 a 1450 1,5 ºC ou 0,25%

B 800 a 1700 0,5%

T - 200 a 0 1 ºC ou 1,5%

E - 200 a 0 1,7 ºC ou 1%

K - 200 a 0 2,2 ºC ou 2%

Tabela 13 – Gama de temperatura e limites de erro nos vários tipos de termopares existentes Fonte: Adaptado de ANSI (1975).

O modelo adquirido é do tipo ponta exposta (exposed), sendo a ponta de detecção unida

por uma soldadura para formar a junção de medição. Este tipo de termopar foi escolhido

porque das junções existentes esta é a que apresenta uma velocidade de resposta maior

(Wilson, 2005, p. 544).

Figura 59 – Termopar adquirido modelo JQSS-IM15E-300

Ponto de gelo

Junção de referência

Temperatura desconhecida

Junção de medição



4.2.3. SENSOR DE PRESSÃO

A necessidade de medir os efeitos do impacto ao nível da pressão (onda de choque) nos

diferentes compartimentos, levou a que fosse necessário adquirir sensores com esta

capacidade.

O sensor adquirido foi o da Freescale Semicondutor modelo MPX5999D que, segundo o

seu datasheet (Semicondutor, 2009, p.1 e 2), permite leituras de 0 a 1 000 000 Pa (0 a

150 psi72). Ao nível do mar a pressão atmosférica é de aproximadamente 101325 Pa

(1,01 Bar), ou seja, é possível medir com este sensor até aproximadamente dez vezes a

pressão existente ao nível médio da água do mar.

A pressão é a força exercida por unidade de área por um fluido (líquido ou gasoso) numa

superfície, sendo a componente normal à superfície que indica a pressão num

determinado ponto. Os três tipos de medidas de pressão existentes são os seguintes

(Chau, Goehner, Drubetsky, Brady, Bayles e Pedersen, 1999, p. 663 e 664; Harman,

2005, p. 414):

Pressão absoluta;

Pressão relativa;

Pressão diferencial.

A pressão absoluta representa a diferença de pressão entre o ponto medido e a pressão

no vácuo, a pressão relativa representa a diferença entre a pressão medida e a pressão

atmosférica (ambiente) e a pressão diferencial é medida como sendo a diferença entre

dois pontos de medição.

O modelo de sensor adquirido, de acordo com as suas especificações técnicas, é

baseado num transdutor piezoresistivo (Semicondutor, 2009, p. 1). Os sensores de

pressão baseados no efeito piezoresistivo são os mais comuns nos dias de hoje, este

efeito é caracterizado por uma mudança na resistência eléctrica do material quando lhe

são aplicadas tensões (Chau, Goehner, Drubetsky, Brady, William H. Bayles e Pedersen,

1999, p. 626; Semicondutor, 2009, p. 412).

O datasheet do sensor (Semicondutor, 2009, p. 4) indica que o diafragma do sensor é

feito de silicone (Figura 60). A sensibilidade do sensor vai ser proporcional à espessura

apresentada pelo diafragma, sendo que ao dobrar a sua espessura vai existir uma

diminuição da sua sensibilidade e vice-versa (Harman, 2005, p. 414). O aumento para o

72

Libras por polegada quadrada.



dobro da espessura do diafragma vai diminuir a sensibilidade em quatro vezes. O tipo de

material que constitui o diafragma também é importante, pois permite saber qual a

máxima pressão que pode ser aplicada sem alterar as suas capacidades físicas. Ao

alterar as capacidades físicas do diafragma faz com que existe uma variação na resposta

obtida pelo sensor.

Figura 60 – Representação da constituição do sensor de temperatura adquirido Fonte: Semiconductor (2009, p. 4).

Gráfico 1 – Saída vs Pressão diferencial

Fonte: Semiconductor (2009, p. 4).

4.2.4. ACELERÓMETROS

Os acelerómetros são sensores que podem ser utilizados para providenciar uma saída

proporcional à aceleração, vibração e choque (Eren, 1999, p. 454; Aszkler, 2005, p. 137).

Os acelerómetros adquiridos foram o ADXL321 e ADXL203 da Analog Devices e o

MMA7260Q da Freescale Semicondutor. O modelo ADXL321 possui uma sensibilidade

de +/- 18 g (2 eixos), o modelo ADXL203 possui uma sensibilidade de +/- 1,7 g (2 eixos) e



o modelo MMA7260Q possui uma sensibilidade regulável de +/- 1,7, +/- 2, +/- 4 e +/- 6g

(3 eixos).

Verificando os datasheets (Devices, 2004; Devices, 2007; Semiconductor, 2005) dos

modelos de acelerómetro referidos anteriormente é possível constatar que estes são do

tipo capacitive micromachined accelerometer. Os acelerómetros capacitivos são

baseados numa mudança de capacitância (quantidade de energia armazenada no

eléctrodo), ou seja, existe uma mudança de capacitância proporcional à aceleração

aplicada. Estes têm na sua constituição física uma massa a uma distância constante de

dois eléctrodos, a variação da posição desta massa de acordo a estes eléctrodos vai

fazer que o valor da capacitância obtida varie (Aszkler, 2005, p. 146; Eren (1999, p. 467).

Esta capacitância vai, posteriormente, ser convertida num sinal analógico através de um

circuito electrónico embutido, ou seja, este vai converter o valor obtido num sinal de

tensão proporcional (Aszkler, 2005, p. 147).

Figura 61 – Representação da construção do elemento principal de um sensor capacitivo Fonte: Aszkler (2005, p. 146).

Figura 62 – Modelo simplificado de um acelerómetro capacitivo Fonte: Adaptado de Semiconductor (2005, p. 4).

A variação do modelo simplificado (Figura 62) é feita de acordo com a seguinte relação

(Semiconductor, 2005, p. 4; Aszkler, 2005, p. 146; Eren, 1999, p. 467):

(6)

Onde: A é a área da massa; é a constante dieléctrica e D é a distância em relação ao

eléctrodo escolhido.

Massa

Eléctrodos



O aparecimento dos microacelerómetros baseados em circuitos integrados teve origem

em 1979, tendo existido uma constante progressão desde essa data (Eren, 1999, p. 477

e 478). Os acelerómetros de três eixos produzidos, segundo esta técnica podem não

apresentar a mesma sensibilidade nos eixos apresentados, devendo a direcção de menor

sensibilidade ser indicada pelo fabricante na documentação técnica disponibilizada. O

acelerómetro de três eixos utilizado MMA7260Q confirma isto, pois este apresenta uma

menor sensibilidade em torno do eixo do Z (Semiconductor, 2005, p. 3).

4.2.5. DATALOGGER DATAQ DI-710-EL

O Datalogger Dataq adquirido é referido pelo seu fabricante como sendo uma versão de

baixo custo, portátil e com interface Ethernet (Instruments, 2007, p. 1).

Este possui dezasseis portas analógicas de entrada com um ganho regulável devido à

utilização de um amplificador de ganho programável (Programable Gain Amplifier - PGA),

ou seja, é recebida informação da unidade de controlo para modificar o ganho de cada

canal. O PGA utilizado na versão adquirida é o PGA204 (Figura 63), que possibilita

ganhos programáveis de 1, 10, 100 e 1 000 (Corporation, 1993).

Figura 63 – Representação do PGA presente no Datalogger Dataq DI-710-EL

Pela análise da Figura 64 é possível verificar que a selecção do sinal de entrada é feita

por um multiplexer (MUX), sendo de seguida este sinal amplificado no PGA e, por fim,

entra num conversor A/D de 14 bits de resolução. Este conversor A/D, segundo

Instruments (2007, p. 6), apresenta um conversor A/D do tipo de aproximações

sucessivas (sucessive aproximation), já abordado anteriormente. Este Datalogger tem

uma velocidade máxima de conversão de 4 800 S/s para o seu sinal de entrada, se

tivermos em consideração que temos um MUX, temos de dividir esta taxa de amostragem

pelo número de entradas seleccionadas. O factor de ganho escolhido também influencia

a taxa de amostragem obtida.



Figura 64 – Representação do PGA presente no Datalogger Dataq DI-710-EL Fonte: Adaptado de Instruments (2007, p. 39).

É necessário ter em consideração que os parâmetros de funcionamento do MUX e do

PGA são controlados pelo microcontrolador existente - PIC 18F8620. Após ser efectuada

a conversão A/D o valor é adquirido pelo microcontrolador e enviado por Ethernet

directamente, através do programa previamente carregado no microcontrolador

(designado de interface code).

Através da utilização do software OmniPeek foi possível compreender o protocolo de

comunicações utilizado e perceber o seu funcionamento.

Figura 65 – Datalogger Dataq DI-710-EL

A comunicação entre o Datalogger requer que se utilize o software WinDaq a correr em

ambiente Windows. O programa de aquisição WinDaq ao ser iniciado efectua um

broadcast para a rede obtendo como resposta pacotes do Datalogger ligado em rede.

Depois de obter o endereço IP é efectuado o broadcast de pacotes ARP request para

obter o endereço MAC a partir do seu endereço IP (Parziale, Britt, Davis, Forrester, Liu,

Matthews e Rosselot, 2006, p. 119). É possível verificar que existe um broadcast de um

pacote ARP request, que contém um endereço IP de outro host na rede e que espera que

este lhe responda com uma mensagem do tipo ARP respond com o seu endereço MAC.

Entradas analógicas

1 2 3 4

(….)

16

MUX PGA 14-Bit

ADC

Dados Controlo de ganho

Selecção de entrada (diferencial / singular)

Microcontrolador

PIC 18F8620

Interface Ethernet

Relógio de sistema



Número do pacote: Origem: Destino: Protocolo: Tipo: 1 169.254.76.27:6237 255.255.255.255:30718 UDP -

2 169.254.218.206:30718 169.254.76.27:6237 UDP -

3 00:23:54:80:CA:D3 FF:FF:FF:FF:FF:FF ARP Request



6 Pronet:A3:48:60 00:23:54:80:CA:D3 ARP Response

Tabela 14 – Pacotes obtidos no pedido de identificação e respectiva resposta

Pela análise da tabela anterior, sendo esta originada num teste efectuado utilizando o

software OmniPeek, é possível verificar que foram efectuados três envios ARP request

antes de receber um pacote ARP response.

Pelos testes efectuados, recorrendo ao software descrito anteriormente, é possível

afirmar que, à excepção da inicialização do Datalogger (Tabela 14) feita pelo software

WinDaq, o resto da comunicação é efectuada recorrendo ao protocolo TCP.

4.3. FERRAMENTA DE DESENVOLVIMENTO ARDUINO

O Arduino nas suas diversas versões é uma ferramenta de desenvolvimento open

source73, tendo surgido inicialmente de um projecto meramente académico. Como

ferramenta de desenvolvimento de aplicações físicas é usualmente associado à filosofia

de physical computing, ou seja, associado à criação de sistemas físicos através do uso

de software e hardware capazes de responder a entradas provenientes do Mundo real

(Arduino, 2006; Santos, 2008; Santos, 2009).

O Arduino pode ser designado simplesmente como uma peça de hardware ou um

software de desenvolvimento, mas é muito mais que isso. Devido ao enorme sucesso

que tem vindo a alcançar ao longo do tempo já conta com uma enorme comunidade de

utilizadores/seguidores por todo o Mundo, podendo afirmar que o Arduino representa

também uma enorme comunidade. As razões para tal sucesso baseiam-se

principalmente no seu baixo custo (dadas as suas funcionalidades), a simplicidade na sua

utilização (programação em linguagem C74) e a possibilidade de utilização em vários

sistemas operativo, como o Windows, Macintosh OS e Linux - capacidade denominada

por cross-platform. Este possibilita, assim, uma forma simples e intuitiva de actuar no

Mundo que nos rodeia (Arduino, 2006; Santos, 2008; Santos, 2009).

73

O conceito de open source está associado a uma filosofia de partilha global em que todo o conteúdo pode ser visualizado e alterado sem qualquer restrição, não devendo no entanto esquecer de referenciar os direitos intelectuais de terceiros. 74

Linguagem de alto nível criada por Dennis Ritchie em 1972, no AT&T Bell Labs.



Apesar de o Arduino possuir inúmeras funcionalidades e campos de aplicação, apenas

vão ser abordadas neste capítulo as suas características como Datalogger, ou seja, a sua

capacidade de efectuar a aquisição de dados analógicos e converte-los para valores

digitais. Esta conversão tem como objectivo o envio para uma unidade de

armazenamento para posterior processamento e análise. Mas, antes de iniciar a

exploração do Arduino como Datalogger, torna-se essencial efectuar uma pequena

análise às suas características, sendo essa descrição efectuada no subcapítulo seguinte.

4.3.1. ARDUINO – PRINCÍPIOS BÁSICOS

O Arduino pode ter diversas versões, sendo a que se vai abordar neste subcapítulo e,

consequentemente, neste trabalho, a versão Arduino Duemilinove, pois é a que se

encontra até à data disponível no Departamento de Armas e Electrónica da EN. Esta

abordagem pode ser estendida para os restantes modelos, pois não existe uma grande

diferença em termos de funcionamento (Software) mas em termos de capacidades, com

as respectivas adaptações. O Arduino Duemilinove pode ser facilmente representado da

seguinte forma:

Figura 66 – Representação de um Arduino Duemilinove Fonte: Adaptado de Arduino (2006).

Como é possível constatar pela figura acima a versão utilizada do Arduino é constituída

por uma montagem numa placa de circuito impresso (Printed Circuit Board – PCB), que

juntamente com alguns componentes electrónicos garantem o correcto funcionamento de

um microcontrolador ATmega. A versão Duemilinove vem equipada com o

microcontrolador ATmega168, sendo que as placas mais recentes vêem com o

ATmega328. Estas duas versões de microcontrolador são utilizadas por toda a família de



Arduinos75 com a excepção do Arduino Mega, que utiliza um microcontrolador

ATmega1280. A relação entre versões existentes e o microcontrolador é a seguinte:

Modelo Microcontrolador utilizado Arduino Duemilinove ATmega168 ou ATmega328

Arduino Diecimilia ATmega168

Arduino Mega ATmega1280

Arduino Nano ATmega168 ou ATmega328

LilyPad ATmega168V

Pro ATmega168 ou ATmega328

Pro mini ATmega168

Tabela 15 – Relação entre modelo de Arduino e o microcontrolador utilizado

Através da análise da tabela anterior é possível constatar que o Arduino LilyPad utiliza o

microcontrolador ATmega168V. Este microcontrolador possui exactamente as mesmas

funcionalidades do ATmega168, sendo uma versão de baixo consumo. Esta diferença

deve-se à sua utilização, pois este modelo tem como objectivo ser incorporado em peças

de vestuário (Arduino, 2006).

As principais diferenças entre os três modelos de microcontrolador utilizados são as

seguintes:

ATmega168 ATmega328 ATmega1280 Flash 16 KB Flash 32 KB Flash 128 KB

SRAM 1 KB SRAM 2 KB SRAM 8 KB

EEPROM 512 Bytes EEPROM 1 KB EEPROM 4 KB

Relógio máximo 20 MHz Relógio máximo 20 MHz Relógio máximo 16 MHz

ADC 10 Bits ADC 10 Bits ADC 10 Bits

Consumo a 25ºC (Modo activo)

250 μA 1 MHz (1.8 V)


0.2 mA 1 MHz (1.8 V)


500 μA 1 MHz (1.8 V)

Outros

PWM

Outros

PWM

Outros

PWM

I2C I

2C I

2C

SPI SPI SPI

RS232 RS232 RS232 Tabela 16 – Tabela comparativa entre os três modelos de microcontrolador utilizados

A análise da tabela anterior indica uma clara diferença em termos da memória disponível

(SRAM, Flash e EEPROM). O ATmega328 tem mesma arquitectura do ATmega168, mas

com diferentes capacidades em termos de quantidade de memória disponível. O

consumo energético apresentado pelo ATmega1280 é inferior ao apresentado pelo

ATmega328 nas mesmas condições de funcionamento. Um factor importante a ter em

75

Mais informação acerca de todos os modelos no seu site oficial http://www.arduino.cc.




conta, e que vai ser abordado mais aprofundadamente no subcapítulo seguinte, é a

resolução do conversor A/D que é igual nos três modelos de estudo.

Podemos dividir os componentes constituintes da placa de desenvolvimento Arduino

Duemilinove, que foi a utilizada no desenvolvimento deste trabalho, da seguinte forma:

Figura 67 – Representação dos constituintes principais de um Arduino Duemilinove

Através da análise à figura anterior é possível constatar que este modelo possui uma

série de entradas e saídas, as quais vão ser resumidas na seguinte tabela:

AArrdduuiinnoo DDuueemmiilliinnoovvee

Microcontrolador Atmega168/328

Tensão de operação 5V

Tensão de entrada para alimentação (intervalo limite) 6 - 20V

Pinos de input/output digital 14

Pinos analógicos 6

Pinos PWM76

6

Corrente DC por pino de input/output 40 mA

Corrente DC (3,3 V) 50 mA

Tabela 17 – Características apresentadas por um Arduino Duemilinove

A análise à tabela anterior demonstra que existe um total de 6 entradas analógicas.

Existe assim a possibilidade de ligar 6 sinais analógicos em simultâneo para efectuar a

sua correcta conversão A/D e, caso seja necessário, efectuar algum processamento e

armazenamento. O seu fabricante na sua página oficial indica que ao configurar os pinos

analógicos como entradas estas passam a ter um estado de impedância elevada, sendo

esta de 100 M (Arduino, 2006). Este valor de impedância faz com que exista um pedido

76

Iniciais utilizadas para designar Pulse Width Modulation. Este método permite variar a tensão média de um sinal de saída variando o seu duty cicle (tempo em que o sinal está no estado lógico 1).



de corrente baixo na entrada, fazendo também com que quando um pino de entrada é

deixado desligado (sem qualquer ligação física) surjam valores aleatórios, resultantes do

ruído eléctrico existente no ambiente que o rodeia ou de um pino próximo do mesmo.

O funcionamento do Arduino em termo de software e outros pormenores de operação

importantes encontram-se descritos no apêndice D, procurando neste capítulo especificar

apenas as características necessárias para o caso prático de estudo.

4.3.2. ARDUINO COMO DATALOGGER

O Arduino Duemilinove possui na sua constituição básica um microcontrolador

ATmega168, que de acordo com o seu datasheet77, possui 10 bits de resolução no seu

conversor A/D, ou seja, uma entrada analógica cujo valor varia entre 0 V e 5 V que terá a

sua correspondência em binário com valores entre 0 (0000000000) e 1023 (1111111111),

respectivamente (ATmel, 2009, p. 242). O que nos leva a resoluções na ordem dos 5 mV.

O relógio de sistema presente no Arduino Duemilinove é um cristal que oscila a 16 MHz.

A primeira conversão A/D efectuada demora 25 ciclos de relógio, sendo que as restantes

conversões A/D demoram cerca de 13 ciclos de relógio (ATmel, 2009, p. 246). Esta

diferença acontece pois a primeira conversão A/D precisa de efectuar a respectiva

inicialização do ADC.

Analisando o referido anteriormente e considerando e.g. um relógio de entrada do

conversor A/D de 1 MHz, podemos facilmente concluir o seguinte (ignorando a conversão

inicial):

Hz (7)

Ou seja, iríamos obter uma taxa de amostragem de 77 kHz. Analisando a taxa de

amostragem obtida a frequência máxima do sinal a amostrar, deve ser menor ou igual a

38,5 kHz, de forma a respeitar o teorema da amostragem.

O Arduino apesar de possuir um relógio de sistema de 16 MHz não é este o relógio de

entrada no nosso conversor A/D. O relógio de sistema é dividido por um factor de divisão

- Prescaler, sendo na saída do Prescaler este sim o relógio que vamos obter no nosso

conversor A/D.

77

Este termo é utilizado para descrever a documentação técnica disponibilizada pelo seu fabricante, elaborada para explicar o seu funcionamento.



O factor de divisão pode no entanto ser configurado, fazendo variar o conteúdo do bit

ADPS0, ADPS1 e ADPS2 (como se pode constatar pela análise da Figura 68).

Figura 68 – Representação do funcionamento do Prescaler do microcontrolador ATmega168 Fonte: ATmel (2009, p. 246).

Estes bits são parte integrante do registo ADCSRA, que é constituído da seguinte forma:

Bit 7 6 5 4 3 2 1 0

(0x7A) ADEN ADSC ADATE ADIF ADIE ADPS2 ADPS1 ADPS0

Read/Write R/W R/W R/W R/W R/W R/W R/W R/W

Valor Inicial 0 0 0 0 0 0 0 0

Tabela 18 – Conteúdo do registo ADCSRA

Fonte: Adaptado de ATmel (2009, p. 255).

As combinações possíveis para os bits referidos anteriormente podem ser resumidas pela

seguinte tabela:

ADPS2 ADPS1 ADPS0 Factor de divisão 0 0 0 2

0 0 1 2

0 1 0 4

0 1 1 8

1 0 0 16

1 0 1 32

1 1 0 64

1 1 1 128

Tabela 19 – Conteúdo do registo ADCSRA Fonte: Adaptado de ATmel (2009, p. 255).

Ou seja, o relógio de entrada do conversor A/D é obtido através da seguinte condição:

(8)

Mas para se obter a taxa de amostragem teórica máxima ainda é preciso dividir os

valores presentes na tabela anterior por 13 (se ignorarmos os 25 ciclos de relógio iniciais

necessários para efectuar a inicialização do conversor A/D). Ao efectuarmos os

respectivos cálculos obtemos os seguintes valores:



Factor de divisão (Prescaler)

Relógio final (MHz) Relógio final

MHz (13 ciclos de relógio)

Relógio final

kHz (13 ciclos de relógio)

2 8 0,62 615,38

2 8 0,62 615,38

4 4 0,31 307,69

8 2 0,15 153,85

16 1 0,08 76,92

32 0,5 0,04 38,46

64 0,25 0,02 19,23

128 0,125 0,01 9,62

Tabela 20 – Representação da velocidade de conversão teórica esperada

Estes valores vão ser abordados experimentalmente, tentando assim aferir qual a

velocidade de conversão A/D obtida na prática (subcapítulo 5.4.). Uma análise à sua

curva de conversão A/D (subcapítulo 5.2.) também vai ser efectuada tendo em conta a

sua velocidade de conversão, tentando assim aferir as perdas de resolução existentes e

os erros associados ao mesmo.

4.3.3. SHIELD ETHERNET

O shield Ethernet (Figura 69) tem como principal função permitir que o Arduino se possa

ligar utilizando o protocolo IEEE 802.3, utilizando para tal uma ficha RJ45.

Figura 69 – Shield Ethernet

O shield Ethernet é baseado na utilização de um chip Ethernet Wiznet W5100 (Figura

70). Este chip Ethernet permite a implementação de uma pilha TCP/IP (já descrita

anteriormente no subcapítulo 3.3) suportando os protocolos TCP e UDP com capacidade

de criação de até 4 ligações em simultâneo (WIZnet, 2006, p. 4 e 5).



Figura 70 – Chip Ethernet Wiznet 5100 Fonte: WIZnet (2006, p. 1).

É possível constatar através da sua utilização que os pinos 10,11,12 e 13 do Arduino são

os responsáveis por implementar uma comunicação SPI78 com o chip Ethernet utilizado,

não podendo assim ser utilizados para as suas funções de input/output habituais.

Este shield tem uma série de indicações luminosas - leds – que indicadores do seu

estado de funcionamento, este podem ser resumidos da seguinte forma:

Indicação no led Estado Significado

TX Ligado O chip Ethernet encontra-se a transmitir dados

Desligado O chip Ethernet não se encontra a transmitir dados

RX Ligado O chip Ethernet encontra-se a receber dados

Desligado O chip Ethernet não se encontra a receber dados

FULLD Ligado Ligação em full-duplex

Desligado Ligação em half-duplex

LINK Ligado Houve recepção ou envio de dados

Desligado Não está presente qualquer ligação física

100M Ligado Ligação com uma velocidade de 100 Mbps

Desligado Ligação com uma velocidade de 10 Mbps

COLL Ligado Houve uma colisão e foi detectada

Desligado Não foi detectada qualquer colisão dos dados

Tabela 21 – Inferências que se podem fazer pelas indicações luminosas presentes no shield Ethernet

As funções executadas pelo Arduino com a utilização deste shield necessitam de recorrer

a uma biblioteca específica - Ethernet, sendo que a programação do microcontrolador

continua a necessitar de uma ligação série não podendo ser programado através da ficha

RJ45.

A utilização deste shield permite também ligar o Arduino ao Mundo pois é possível aceder

ao seu conteúdo e funções através da internet, podendo ser acedido a partir de qualquer

lugar do Mundo. Esta capacidade alarga assim ainda mais o seu campo de aplicação

para outro tipo de utilizações e.g. domótica, que possibilitam assim aumentar o sucesso

deste produto.

Este não é o único shield disponível no mercado, existem variadíssimos shields que

aplicam os protocolos: zigbee, bluetooth, etc. Estes permitem expandir a sua

aplicabilidade.

78

Comunicação síncrona que opera em full-duplex, como é síncrona é baseada numa ligação de master/slave em que o master é o responsável por iniciar a ligação.



4.3.4. DATAQ VS ARDUINO

Este subcapítulo tem como principal objectivo resumir as características dos

equipamentos de aquisição utilizados, procurando assim efectuar uma comparação entre

eles.

Através de uma análise à Tabela 22 é possível verificar que existem largas diferenças

entre os dois, principalmente o nº de bits de resolução, ritmo de amostragem, nº de

entradas analógicas e custo.

Parâmetro analisados: DATAQ DI-710-EL Arduino Duemilinove +

Shield Ethernet

Ritmo máximo de amostragem (1 canal): 4 800 S/s 888 S/s

Gama de valores de entrada:

+/- 10 V Ganho de 1 +/- 1 V Ganho de 10

+/- 100 mV Ganho de 100 +/- 10 mV Ganho de 1000

+/- 5 V Padrão +/- Vin Tensão de entrada

constante

Nº de bits de resolução (conversor A/D): 14 Bits 10 Bits

Impedância de entrada: 1 M 100 M

Canais diferenciais/referenciados à massa: 16 Referenciados à massa

8 Diferenciais 6 Referenciados à massa

Interface de saída: Ethernet Série e Ethernet

Capacidades de transmissão: 4 800 S/s Valor não disponível

Custo estimado: 575 € 60 €

Tabela 22 – Dataq vs Arduino Duemilinove + shield Ethernet

Fonte: Adaptado de Instruments (2007, p. 5) e ATmel (2009, p. 1).

4.4. AGREGADO PLANAR 4X4 DESENHADO, FABRICADO E

TESTADO

A necessidade de aumentar o alcance e a taxa de transferência obtida nos testes

descritos por Capela, Pessanha, Vieira e Monsanto em que a uma distância de 7,49 km

foi obtida uma taxa de transferência de 68 kBps (544 kbps) (Capela, Pessanha, Vieira e

Monsanto, 2008, p. 10), fez com que existisse a necessidade de arranjar uma solução

fiável e de baixo custo.

Para tal foi desenhado um agregado planar em tecnologia microstrip79, que reúne as

seguintes características:

Vantagens Desvantagens Baixo peso

Largura de banda útil reduzida Baixo custo

Flexibilidade na polarização

Flexibilidade no diagrama de radiação

Tabela 23 – Vantagens e desvantagens da tecnologia microstrip Fonte: Adaptado de Mendes e Peixeiro (2005, p. 1).

79

É possível fabricar utilizando a tecnologia de fabrico de placas de circuito impresso, usado normalmente para utilização em sinais no domínio das microondas.



Ao existir a possibilidade de desenhar, fabricar e testar uma antena impressa, ou seja, ao

criar uma antena em vez de utilizar uma já construída (comprada numa superfície

comercial) tem a vantagem de se poder ajustar todos os seus parâmetros. As principais

motivações que levaram à elaboração de uma antena foram o fraco desempenho obtido

pela antena Omnidireccional adquirida – ganho de 10 dB, nomeadamente em termo de

alcance e de largura de banda obtidos (Capela, Pessanha, Vieira e Monsanto, 2008, p.

11).

Com vista a melhorar a eficiência da comunicação, foram definidos os seguintes

requisitos:

Frequência central 2,462 GHz (Canal 11 IEEE 802.11g)

Largura de banda 22 MHz (1 canal)

Ganho > 16 dBi

Polarização Horizontal

Abertura V (-3 dB) 15º

Abertura H (-3 dB) 15º

Impedância de entrada 50 Ω

Tabela 24 – Requisitos para a antena direccional

O seu desenvolvimento foi feito recorrendo ao software PCAAD80 e ENSEMBLE 5.1. O

software PCAAD foi utilizado para efectuar algumas análises preliminares pois possibilita

uma alteração de parâmetros com grande facilidade, tendo como principal inconveniente

a fraca precisão nos resultados obtidos face à realidade. O software ENSEMBLE 5.1 é

bastante antigo mas é utilizado à bastante tempo no Instituto Superior Técnico obtendo

resultados fiáveis, tendo como principal inconveniente o tempo que demora a efectuar

cada simulação. Este leva aproximadamente uma hora por ponto simulado mesmo

utilizando um computador com um CPU de 2 GHz. Ambos os softwares descritos

anteriormente possibilitaram o desenvolvimento de um agregado de elementos

quadrados impressos de 4x4. Como mostra a seguinte figura:

Figura 71 – Representação do agregado planar 4x4 desenvolvido

As diferentes fases de desenvolvimento da antena planar encontram-se retratadas nos

relatórios presentes no apêndice C. Neste subcapítulo apenas vai ser feito um breve

resumo ao trabalho elaborado nesta área.

80

O seu site oficial é http://www.antennadesignassociates.com/.

http://www.antennadesignassociates.com/



Figura 72 – Representação das medições efectuadas em camera anecóica

Figura 73 – Agregado de elementos quadrados impressos de 4x4

A geometria do agregado é demonstrada na Figura 73, sendo as dimensões do agregado

impostas por limites máximos de fabrico no laboratório utilizado - 45,72 cm de

comprimento por 30,48 cm de largura. O espaçamento entre elementos nos dois planos

(plano E e H) foi escolhido tendo em conta os requisitos de abertura de feixe a - 3 dB.

Foram utilizados elementos quadrados com uma dimensão de 39,4 mm por 39,4 mm num

substrato Duroid 5880 com uma espessura de 3,175 mm, utilizado com vista a obter a

largura de banda desejada. A malha de alimentação é uma malha paralela e através de



variadíssimos adaptadores de quarto de comprimento de onda conseguimos adaptar os

50 de impedância de entrada até à impedância dos elementos, fazendo com que a sua

frequência de ressonância se situe na banda do IEEE 802.11g (2,4 GHz).

Gráfico 2 – Coeficiente de reflexão teórico e obtido experimentalmente

Das medições efectuadas a mais importante é o coeficiente de reflexão (S11), pois quanto menor

este valor melhor estará o agregado adaptado, sendo este uma boa medida para saber a

quantidade de sinal/potência reflectidos. Quanto menor for este valor menores vão ser as

respectivas perdas (Huang e Boyle, 2008, p. 36). Estas medições são efectuadas

experimentalmente utilizando um Vector Network Analyser (VNA).

Figura 74 – Medição experimental do S11 utilizando um VNA

-40-35-30-25-20-15-10

-50

2 2,1 2,2 2,3 2,4 2,5 2,6 2,7 2,8 2,9 3

S 11

[dB

]

Frequency [GHz]Experimental

Simulation



Simulação Experimental

Largura de Banda (Abaixo dos -10dB)

2460 MHz – 2540 MHz (80 MHz)

2375 MHz – 2452 MHz (77 MHz)

Plano E Plano H

Simulado Experimental Simulado Experimental

Ganho (0º) 19.3 17.7 19.3 17.69

Ganho Máximo 19.32 (1º) 17.89 (2º) 19.97 (-1º) 17.69 (0º)

Abertura de feixe a -3dB

18º 17º 25º 25º

Tabela 25 – Principais características do agregado (Experimental vs Simulado)

As principais características do agregado encontram-se expostas na tabela anterior,

sendo efectuada nesta tabela uma comparação entre os resultados obtidos

experimentalmente e os resultados simulados. A análise aos resultados leva a que se

constate que existe uma diferença entre os resultados simulados e os experimentais,

sendo de realçar o desvio na frequência obtido nas medições experimentais. Os Gráficos

que representam os diagramas de ganho obtidos no plano E e H são os seguintes:


-20

-15

-10

-5

0

5

10

15

20

-90 -80 -70 -60 -50 -40 -30 -20 -10 0 10 20 30 40 50 60 70 80 90

Ga

in [

dB

i]

Theta [Degree]

EPlane-ENSEMBLE

Eplane-Experimental




4.5. ANÁLISE DE UM CASO DE ESTUDO

As experiências práticas efectuadas, bem como todos os resultados teóricos obtidos, têm

como principal objectivo decompor um problema grande em variadíssimos problemas de

menores dimensões procurando dar um passo de cada vez.

Este subcapítulo procura dar uma ideia mais concreta de uma possível rede de sensores

numa unidade naval. Analisemos a seguinte figura:

1 2 3

456

Figura 75 – Representação para motivos de estudo do piso de um navio

-20

-15

-10

-5

0

5

10

15

20

-90 -80 -70 -60 -50 -40 -30 -20 -10 0 10 20 30 40 50 60 70 80 90

Ga

in [

dB

i]

Theta [Degree]

HPlane-ENSEMBLE

Hplane-Experimental



A figura anterior pretende retratar o piso de um navio, pois não sabemos o navio alvo

deste estudo e para tal foi projectada a possível disposição não correspondendo a

nenhum caso real em concreto. Podemos ver descriminadas 6 áreas distintas numeradas

de 1 a 6, bem como várias caixas azuis - caixas de aquisição - representadas em cada

compartimento interligadas entre si. As caixas dos compartimentos81 1,2 e 3 encontram-

se ligadas a verde e as dos compartimentos 4,5 e 6 encontram-se ligadas a laranja,

pretende-se assim representar dois ramos distintos de uma rede. As duas redes foram

simplificadas não colocando nenhuma ligação entre as duas redes, mas num caso real de

estudo deve existir uma redundância entre elas. A comunicação de dados para o exterior

do navio é feita na parte direita da figura, onde está representado um router e uma

antena para efectuar a comunicação.

Neste caso de estudo cada uma das duas caixas de aquisição presente num

compartimento é constituída por um Arduino Duemilinove com capacidade de

comunicação em Fast Ethernet (100 Mbps), em que os sensores ligados a ele são

alimentados pelas suas saídas de alimentação. A outra caixa de aquisição é constituída

por apenas um Datalogger Dataq alimentando também os sensores através das suas

saídas de alimentação disponibilizadas.

A gama de temperatura de operação vai agora ser determinada com base na

documentação técnica dos sensores e equipamentos utilizados. Os acelerómetros

utilizados operam entre – 20 ºC e os 85ºC (Devices, 2007, p. 3; Semiconductor, 2005, p.

1). O sensor de pressão utilizado MPX5999D opera entre os – 40ºC e os 125ºC

(Semiconductor, 2009, p. 3). O termopar adquirido é do tipo J, e tem a sua gama de

operação entre os 0 ºC e os 750 ºC (ANSI, 1975). O Datalogger Dataq DI-710-EL versão

Ethernet opera entre 0 ºC e 70 ºC (Instruments, 2007, p. 6). O Arduino, considerando a

temperatura de operação do seu microcontrolador ATmega168, opera entre os – 40ºC e

os 85 ºC (ATmel, 2009, p. 1).

A temperatura de operação do sistema deverá situar-se entre os 0 ºC e os 70ºC, pois é

nesta gama de temperaturas que teoricamente falha o equipamento com a gama de

temperatura mais baixa - o Datalogger Dataq DI-710-EL. Mesmo depois de ultrapassar

esta temperatura o sistema continuará a enviar dados, mas estes devem ser

correctamente tratados pois podem corresponder a lixo. A propagação de calor entre

compartimentos espera-se bastante rápida por fenómenos de condução, convecção e

radiação (Çengel e Boles, 2001, p. 106,108 e 109).

81

Nome normalmente utilizado para designar, a bordo de um navio, as divisões existentes.



A propagação de calor entre compartimentos adjacentes pode ser um fenómeno com

uma rapidez bastante elevada, devendo ter em linha de conta as temperaturas de

operação dos equipamentos. O fio utilizado para efectuar as ligações entre unidades para

alimentação de equipamentos ou para transporte de dados deve ser e.g. revestido por

uma manga resistente a altas temperaturas, pelo menos da gama de operação do

equipamento. A falha de um Datalogger provoca a perda da capacidade de adquirir

dados de vários sensores em simultâneo, mesmo que os fios apresentem uma grande

resistência térmica.

Começando pelas alimentações só no piso ideal de estudo (Figura 75) estariam 6

Arduinos alimentados e.g. a 12 V e 6 Dataloggers Dataq, segundo informação do seu site

oficial (Arduino, 2006) a corrente máxima permitida é de 500 mA. O Arduino tem um

mecanismo denominado current protection, que faz com que a alimentação seja cortada

nos casos em que esta corrente é excedida. Num caso limite ia fazer com que cada

Arduino tivesse um consumo de 6 W, o que levaria a aproximadamente 36 W de

consumo. No caso do Datalogger Dataq DI-710-EL o consumo máximo descrito na sua

documentação técnica (Instruments, 2007, p. 6), para o modelo Ethernet utilizado é de

2,5 W, perfazendo um total de 15 W. Sendo o consumo total do sistema simplificado

representado de 51 W (Figura 75).

Se possuirmos uma bateria de automóvel de 12 V com uma capacidade de 50 Ah

(ampere-hora), ou seja, com uma capacidade de 600 Wh para alimentar todo o sistema

descrito anteriormente teríamos teoricamente um tempo de vida de aproximadamente 12

horas, com o sistema permanentemente ligado. Isto em condições ideais e bastante

simplificadas.




Neste capítulo foi efectuada uma abordagem ao equipamento adquirido, indicando o seu

princípio de funcionamento. As modificações que foram efectuadas consideradas mais

importantes foram descritas, desde a simples actualização de firmware até ao seu

princípio de funcionamento.

As modificações ao router adquirido foram também descritas, estas consistiram

basicamente na mudança do firmware de origem para outro com mais funcionalidades -

DD-WRT. Na descrição do princípio de funcionamento do sensor termopar, acelerómetro

e sensor de pressão procurou-se sempre especificar o seu princípio de funcionamento.

Na abordagem efectuada foram abordados especificamente os modelos adquiridos e

como a sua utilização se vai enquadrar no sistema de telemetria.

Os equipamentos de aquisição adquiridos também foram abordados - Datalogger Dataq

DI-710-EL e Arduino Duemilinove - indicando quais os seus prós e contras de utilização e

fazendo a sua comparação dedicando um subcapítulo específico para o efeito.

O agregado planar 4x4 desenhado e construído foi também abordado indicando algumas

vantagens e desvantagens da utilização desta tecnologia, os parâmetros idealizados para

a sua elaboração e resultados de alguns testes práticos efectuados aos seus parâmetros

de funcionamento.

O capítulo foi finalizado com a descrição de um caso de estudo, retratando assim alguns

dos problemas que preliminarmente se espera que existam no caso de um afundamento

de uma plataforma naval – temperatura e alimentação dos equipamentos. A alimentação

deverá ser efectuada recorrendo a baterias que deverão apresentar alguma redundância

entre si, permitindo assim uma boa performance por parte do sistema.

5. CAPÍTULO V

TRABALHO DE CAMPO E RESULTADOS

5.1. INTRODUÇÃO

Este subcapítulo descreve os testes efectuados aos equipamentos adquiridos,

determinando assim a sua performance de forma a aferir se os mesmos se adequam às

necessidades esperadas e previamente idealizadas.

Os testes efectuados podem-se separar em vários campos distintos e objectivos

concretos, sendo os seguintes:

Testes efectuados para aferir os erros existentes na curva de conversão A/D

5apresentada por um ATmega168 presente no Arduino Duemilinove;

Testes à camera de alta-velocidade aferindo a largura de banda necessária para

as suas diversas configurações de operação;

Testes à largura de banda necessária para os equipamentos de aquisição

adquiridos - Datalogger Dataq DI-710-EL e Arduino Duemilinove;

Testes à taxa de amostragem ao nível do utilizador, ou seja, a taxa de

amostragem obtida utilizando o software Matlab;

Testes ao alcance da antena omnidireccional adquirida recorrendo a

embarcações da EN e a testes na Base aérea do Montijo, determinando o seu

alcance máximo e largura de banda;

Testes ao desempenho da camera de alta-velocidade na carreira de tiro da Escola

Naval;

Testes ao desempenho da antena omnidireccional adquirida, recorrendo a

aparelhos de medida da GOAME;

Testes efectuados durante o exercício de disparo de mísseis MILAN.

Os testes anteriores e alguns dos dados apresentados ao longo deste capítulo foram

efectuados em diferentes ambientes, recorrendo a navegações em embarcações da EN,

à monitorização do disparo de mísseis MILAN82 com o apoio da CAF83, à abordagem em

82

MILAN - Missile d’Infanterie Léger Antichar.



bancada de laboratório, a testes na carreira de tiro da Escola Naval, entre outros de

modo a obter assim dados fiáveis sobre o comportamento dos equipamentos. Alguns dos

testes descritos anteriormente não se encontram documentados neste capítulo mas nos

apêndices existentes, de acordo com o exposto no subcapítulo 1.2.3.

Os testes efectuados e respectiva descrição vão ser acompanhados pelo esquema do

aparato experimental utilizado. Por fim, para cada subcapítulo distinto, será efectuado

uma interpretação dos resultados obtidos, o que será um dos aspectos chave deste

capítulo. Assim sendo ir-se-ão basear nestes testes e em todo o trabalho desenvolvido,

que se encontra na sua maioria documentado em apêndice (Apêndice A a H), as

conclusões finais do estudo efectuado.

5.2. CARACTERIZAÇÃO DA CURVA DE CONVERSÃO A/D DE

UM ARDUINO DUEMILINOVE

No sistema de telemetria a desenvolver é necessário adquirir sinais da ordem do milivolt

(mV), em que a inclusão de um grande erro na aquisição pode originar valores totalmente

díspares da realidade.

Como se pretende que os valores obtidos tenham o menor erro possível, apesar de se

poderem aplicar métodos matemáticos para obter resultados fiáveis, efectuou-se a

caracterização da curva de conversão A/D de forma a representar e quantificar o erro

existente.

5.2.1. CONDIÇÕES E OBJECTIVOS DOS TESTES

Os testes foram efectuados recorrendo a um computador portátil equipado com 4 Gbytes

de memória RAM, apetrechado com um Intel® Core™2 Duo T9400 (2,53 GHz) a correr o

Windows 7 Ultimate na sua versão de 32 bits. Foi, ainda, utilizado um osciloscópio

Tektronix TDS 1002B, um gerador de funções modelo Hewlett-Packard 3312A e uma

fonte de alimentação modelo Kaise DF1731SB5A, efectuando assim os testes que vão

ser descrito no subcapítulo seguinte. O Arduino caracterizado foi o modelo Duemilinove

com um microcontrolador ATmega168.

83

A companhia de apoio a fogos é uma companhia pertencente ao corpo de fuzileiros, que tem como principal objectivo assegurar o apoio de combate do batalhão ligeiro de desembarque.

Capitulo V – Trabalho de campo e resultados


Os testes efectuados têm por objectivo tentar quantificar os erros existentes, de modo a

dar uma ideia concreta do erro absoluto existente para cada valor do prescaler,

determinando também o erro de offset e o erro de ganho existentes.

5.2.2. DESCRIÇÃO DOS TESTES EFECTUADOS

Os testes elaborados consistiram na leitura, directamente do osciloscópio, dos valores

provenientes da alimentação USB84, da leitura do valor disponibilizado no pino de 3,3 V e

da leitura do pino de 5 V, existentes no Arduino. Após terem sido efectuadas estas

leituras foi aplicado um sinal de rampa com um valor máximo de 5,21 V (valor de

referência obtido através de medições efectuadas – Tabela 26), possibilitando assim a

leitura do erro absoluto, sendo também determinado o erro de offset e de ganho.

Os dados foram directamente adquiridos da placa de desenvolvimento Arduino através

de uma ligação série, utilizando para isso o software Matlab. Foram adquiridos os dados

e gráficos presentes no osciloscópio através da utilização do software gratuito

OpenChoice™ Desktop85, desenvolvido pela empresa Tektronic.

O procedimento utilizado na determinação de cada um dos erros foi baseado no relatório

técnico elaborado pela ATmel Corporation o AVR120 (Corporation, 2006, p. 4-8) e seguiu

a seguinte metodologia (Anexo A):

O erro absoluto foi determinado utilizando a seguinte metodologia:

Introduzir de um sinal de rampa a variar entre 0 e 5 volts;

Ler e guardar os valores obtidos;

Comparar os valores obtidos com o sinal ideal.

O erro de offset foi determinado utilizando a seguinte metodologia:

Introduzir um sinal de 0 V e ir aumentando o valor de tensão até ocorrer a primeira

transição;

Calcular a diferença entre o valor ideal e o valor absoluto;

A diferença calculada é o erro de offset.

O erro de ganho foi determinado utilizando a seguinte metodologia:

Introduzir um sinal de 0 V;

84

Universal Serial Bus, usado para possibilitar a ligação de periféricos a um computador. 85

Pode ser obtido de através do seu site oficial http://www.tek.com.

http://www.tek.com/



Aumentar a tensão até chegar ao último degrau do conversor A/D (até ao valor

máximo);

Achar o ponto médio do último degrau, baseado nos tamanhos anteriores do

degrau;

Comparar com o valor ideal;

A diferença calculada é o erro de ganho.

5.2.3. ESQUEMÁTICO UTILIZADO

O esquemático utilizado baseou-se no seguinte:

Computador

de Aquisição

Arduino

Osciloscópio

Gerador de

Sinais

Fonte de

Alimentação

Figura 76 – Aparato experimental utilizado nos testes de caracterização do conversor A/D

Foi através do aparato experimental representado na figura anterior e recorrendo à

utilização dos aparelhos de medida consoante a necessidade, que possibilitou a

visualização das formas de onda amostradas recorrendo ao Arduino Duemilinove.

5.2.4. RESULTADOS OBTIDOS

As variações de um conversor A/D com 10 bits de resolução, com um intervalo de

conversão compreendido entre 0 e 5,21 V (valor de referência obtido através de

medições efectuadas – Tabela 26), levam a que exista idealmente uma resolução

representada pela seguinte relação:

(9)



Se substituirmos o valor mínimo por 0 V, o máximo por 5,21 V e o número de bits de

resolução por 10 obtém-se uma resolução de aproximadamente 5,09 mV para cada

degrau de quantização (considerando um conversor A/D ideal). No gráfico abaixo

representado, é possível verificar os níveis de quantização iniciais, e estes idealmente

mantêm-se constantes até se obter o valor de 1023 que corresponderá idealmente a 5,21

V na entrada do conversor A/D.

Pino medido Valor de tensão obtido (V) 5 V 5,21

3.3 V 3,42

Vin 4,71

Tabela 26 – Valores obtidos para os pinos 5V,3,3V e Vin do Arduino Duemilinove

Gráfico 5 – Representação dos dois primeiros níveis de quantização num conversor A/D ideal

Com vista a obter o erro de offset foi alimentado o pino analógico “0” com valores

crescentes de tensão até ocorrer a primeira transição do valor amostrado entre o valor 0

(do binário 0000000000) e o valor 1 (do binário 0000000001), que representa na

realidade qual o valor que é necessário introduzir para existir a primeira transição num

degrau de quantização.

O valor introduzido até ocorrer a primeira transição foi de cerca de 20 mV, tendo sido

obtido um erro de offset de aproximadamente 15 mV. A distribuição dos valores obtida

através da aquisição de 100 pontos recorrendo ao software Matlab foi a seguinte:

Gráfico 6 – Representação gráfica das 100 amostras obtidas com um valor de tensão de 20 mV

0

1

2

3

4

5

0 1 2 3 4 5 6 7 8 9 10111213141516171819202122

0

1

2

3

0 50 100

mV

Valor do conversor A/D


Número de amostras



A maioria das amostras obtidas centrou-se no valor 1 existindo uma intermitência entre o

valor zero e o valor 1, existindo também quatro amostras de valor 2 e uma amostra com o

valor de conversão 3. Os dados obtidos levam a afirmar que nos encontramos com

elevada probabilidade no início do primeiro nível de quantização.

Os valores introduzidos levam a que exista uma anulação de quase três níveis, se o

conversor A/D fosse ideal, como se pode analisar através do seguinte gráfico:

Gráfico 7 – Representação do erro de offset obtido

Após identificado o erro de offset, e de acordo com o referido anteriormente durante a

abordagem teórica ao tema é possível verificar que existe um erro de - 3 LSB neste

conversor A/D. O que faz com que exista um valor de saída do conversor A/D de 0 para

valores inferiores a 20 mV. Para compensar este erro é necessário ter em atenção que

quando o valor apresentado pelo conversor A/D for de 1, estamos na realidade temos

valor de, aproximadamente, 20 mV na entrada e não os 5,09 mV ideais. O que faz com

que o factor de compensação a introduzir seja de aproximadamente 3 LSB (Factor

compensação = Valor obtido – Erro offset). Como o erro de offset é negativo é necessário

somar a cada valor obtido pelo conversor A/D 3 LSB com vista a compensar este erro.

O erro de ganho só pode ser determinado após determinar o erro de offset e o

compensar (Corporation, 2006, p. 7). A tensão de entrada do pino “0” foi aumentada até

ao valor limite do conversor A/D (1023) e verificou-se que existia um erro de ganho de - 3

LSB, pois o valor 1023 foi obtida para uma tensão de 5,21 V (sem aplicar compensação

de offset).

O erro absoluto foi determinado pela introdução de um sinal a variar entre - 1 V e 5,21 V,

com um período de 10 segundos (frequência de 0,1 Hz) no pino analógico “0” do Arduino.

Os valores obtidos foram registados através da porta série, recorrendo ao software

Matlab. A forma de onda utilizada foi a seguinte:

0

1

2

3

4

5

0 1 2 3 4 5 6 7 8 9 1011121314151617181920


mV



Figura 77 – Forma de onda utilizada para determinar o erro absoluto

A onda de entrada se tiver como valor de zero segundos o momento em que a onda

passa no valor zero do eixo vertical, temos que ela demora cerca de 2,5 s a alcançar o

valor de 5,21 V. Esta passados outros 2,5 s volta a interceptar o eixo horizontal tomando

o valor de 0 V, estando os restantes 5 s do seu período em valores negativos que rondam

os -1 V. A banda de interesse pode ser representada através da seguinte figura:

Figura 78 – Forma de onda utilizada para determinar o erro absoluto

O erro absoluto por si só não nos dá a indicação de qualquer factor de compensação a

aplicar pois este, e como foi referido no subcapítulo 2.3.3., inclui os erros de quantização,

erro offset, erro de ganho e erros devido à sua não linearidade.

O erro absoluto não pode ser compensado directamente, a não ser e.g. pela utilização de

tabelas de calibração que têm como inconveniente ocupar demasiada memória ou por

aproximações polinomiais86 (Corporation, 2006, p. 5). Os maiores contributos para o erro

absoluto – erro de offset e o erro de ganho – podem ser compensados individualmente

como foi referido anteriormente neste subcapítulo.

Com um factor de prescaler de 2 e aplicando a forma de onda representada

anteriormente (Figura 78), foi possível efectuar a amostragem do meio ciclo de interesse,

recorrendo ao software Matlab. A forma de onda obtida foi a seguinte:

86

Métodos numéricos utilizados para obter soluções aproximadas de um modelo ou de um sistema exacto.

Tempo (s)

Tensão (V)

0 V

0 s 2,5 s 5 s

Tempo (s)

Tensão (V) 5,21 V



Gráfico 8 – Curva de conversão A/D obtida com um factor de prescaler de 2

A análise do gráfico anterior mostra que a forma de onda apresenta algumas

irregularidades, acrescentando ao gráfico o valor ideal (representado a vermelho), obtém-

se o Gráfico 9.

A diferença entre os valores ideais e os valores obtidos representa o erro absoluto,

existindo neste caso um erro absoluto máximo de aproximadamente 306 mV. As

irregularidades existentes nos valores obtidos devem-se ao valor do relógio de entrada do

conversor A/D ser superior a 1 MHz, valor que de acordo com a documentação técnica

do fabricante é o valor máximo que deve ser utilizado para obter boa performance sem

perda de resolução significativa (Corporation, 2006, p. 10). O relógio de entrada neste

caso (Tabela 27) é de 1,62 MHz, o que é claramente superior ao limite referido

anteriormente.

Gráfico 9 – Comparação da curva de conversão A/D com um factor de prescaler de 2 e a ideal

A comparação foi feita amostrando o mesmo sinal de entrada descrito anteriormente,

mas neste caso para um factor de prescaler de 128. Este teste possibilita determinar se

realmente o factor de prescaler introduzido tem uma influência directa no erro absoluto

0

200

400

600

800

1000

0,0

0

0,3

8

0,7

6

1,1

4

1,5

2

1,9

0

2,2

8

2,6

7

3,0

5

3,4

3

3,8

1

4,1

9

4,5

7

4,9

5

0

200

400

600

800

1000

0 0,5 1 1,5 2 2,5 3 3,5 4 4,5 5


Tempo (s)


Tempo (s)



obtido, sendo que neste factor de prescaler o relógio de entrada no conversor A/D é de

cerca de 0,12 MHz (Tabela 27). Os dados obtidos foram os seguintes (valores obtidos a

azul e ideais representados a vermelho):


A análise do gráfico anterior demonstra que houve uma clara mudança no

comportamento do conversor A/D, com um erro absoluto máximo de aproximadamente

102 mV, existindo agora uma maior precisão (menor erro absoluto) nos dados obtidos

(linha azul praticamente sobreposta à vermelha). O que leva a que tenha de existir um

cuidado na escolha do factor de prescaler para não obter uma curva de conversão A/D

com demasiado erro, mas o que interessa é obter a maior relação entre a velocidade de

conversão (menor factor de prescaler) e a resolução apresentada pelo factor de

prescaler. A relação entre o relógio de entrada do conversor A/D e o factor de prescaler

determinada experimentalmente (ver capítulo 5.4.) pode ser transcrito através da

seguinte tabela:

Factor de Prescaler: Relógio de entrada do conversor A/D (MHz) 2 1,62

4 1,55

8 0,87

16 0,65

32 0,40

64 0,22

128 0,12

Tabela 27 – Valores do relógio de entrada do conversor A/D obtidos experimentalmente

A análise da tabela anterior, e de acordo com o valor máximo do relógio de entrada do

conversor A/D descrito pelo fabricante, leva a afirmar que o factor de prescaler que

satisfaz as especificações é o valor de 8.

0

200

400

600

800

1000

0 0,5 1 1,5 2 2,5 3 3,5 4 4,5 5


Tempo (s)




O gráfico anterior demonstra que a resolução do conversor A/D (representada a azul) não

foi grandemente afectada face à representação ideal (representada no gráfico a

vermelho), sendo o erro absoluto máximo existente neste caso de aproximadamente 204

mV. A mudança do factor de prescaler de 8 para 4 faz com que o relógio de entrada do

conversor A/D passe para valores teoricamente proibitivos. Com vista a analisar qual a

influência deste limiar, foi determinada a diferença entre o valor obtido e o valor ideal,

para um factor de prescaler 4 (Gráfico 12).


Os erros na resolução do conversor A/D aumentam ligeiramente, mas valor do erro

absoluto máximo mantém-se nos 204 mV.

0

200

400

600

800

1000

0 0,5 1 1,5 2 2,5 3 3,5 4 4,5 5

0

200

400

600

800

1000

0 0,5 1 1,5 2 2,5 3 3,5 4 4,5 5


Tempo (s)


Tempo (s)



5.2.5. CONCLUSÕES

A existência variações na tensão de referência do conversor A/D pode originar grandes

erros nos valores das conversões A/D obtidas, o que pode ser bastante limitativo e.g. na

utilização de sensores que trabalhem com variações de tensão de pequena dimensão. A

compensação destes erros em cada Arduino deve ser efectuada com o fim de adquirir

dados analógicos mais precisos, analisando para cada equipamento distinto os seus

valores pois não existem dois equipamentos com características de conversão A/D

rigorosamente iguais.

A determinação do erro absoluto para variados valores de prescaler serviu para

demonstrar que este tem influência na resolução apresentada pelo conversor A/D. O

factor de prescaler que apresentava a melhor relação velocidade de conversão/resolução

é o factor 4, ou seja, sempre que possível e em aplicações em que seja necessária

alguma precisão deve-se privilegiar o uso deste factor de prescaler face a um valor

inferior.

5.3. TESTES DE TELEMETRIA A MÍSSEIS MILAN

Os testes de telemetria efectuados a mísseis MILAN contaram com o apoio da CAF87,

situada na Base de Fuzileiros (BF) dentro das instalações da BNL88, tendo sido

realizados no dia 4 de Dezembro de 2009.

Os testes efectuados resumiram-se à utilização de um aparato experimental que

possibilitou retratar qual o comportamento de um alvo após ser atingido por mísseis

MILAN, recorrendo a uma montagem conveniente. Nestes testes, utilizou-se um alvo

cedido pela CAF, que se encontra representado nas imagens seguintes, contudo a

montagem utilizada com as devidas adaptações pode ser expandida a qualquer tipo de

alvo:

Figura 79 – Alvo utilizado durante o exercício de disparo de mísseis MILAN (visto de trás)

87

Companhia de Apoio de Fogos. Esta companhia é constituída pelos seguintes pelotões: pelotão de Morteiros, pelotão Anti-Carro, pelotão Anti-Aéreo e o pelotão de Reconhecimento. 88

Base Naval de Lisboa, esta encontra-se situada no Alfeite em Almada.



Figura 80 – Alvo utilizado durante o exercício de disparo de mísseis MILAN (visto de lado)

AC

B

D

Figura 81 – Esquema do alvo e disposição dos sensores utilizada

Os mísseis MILAN foram adquiridos pelo Comando do Corpo de Fuzileiros (CCF) em

1996, sendo considerada uma arma portátil de médio alcance. O seu alcance máximo

está fixado nos 1 950 metros com uma duração máxima de voo de 12,5 segundos,

mantendo uma velocidade entre 75 e 210 m/s, de acordo com as informações

disponibilizadas pela CAF provenientes do seu fabricante. A sua característica essencial

é ser um míssil de combate Anti-Carro filoguiado89, pelo que requer um operador treinado

para incrementar a sua probabilidade de sucesso.

Figura 82 – Míssil MILAN

89

O conceito de filoguiado é aqui introduzido para designar um míssil que é conduzido durante o seu voo, recorrendo a um fio que transmite sinais de controlo provenientes da unidade lançadora.




Os principais objectivos dos testes efectuados foram:

Efectuar a monitorização do impacto de mísseis MILAN em exercícios de tiro real;

Provar o conceito de telemetria com o material off-the-shelf adquirido;

Adquirir o know-how necessário para elaborar um sistema de telemetria.

A descrição pormenorizada de todo o exercício, bem como toda a montagem efectuada,

código de aquisição em software Matlab e as lições aprendidas encontra-se descrita no

apêndice E, sendo que os subcapítulos seguintes vão apenas centrar-se em algumas das

conclusões que resultam dos testes efectuados durante a preparação do referido

exercício.


Os testes efectuados basearam-se na interligação do equipamento experimental a

utilizar, no dia do teste, com Arduinos, Datalogger e camera IP em diversas

configurações, tendo em vista analisar qual a largura de banda necessária para a sua

correcta utilização. A camera de alta-velocidade foi também utilizada no aparato

experimental final, sendo o seu comportamento estudado no subcapítulo 5.5.

A quantidade de dados transmitida, bem como alguns parâmetros de download e upload,

foram simultaneamente monitorizados, utilizando o software BitMeter. Em simultâneo

com os testes descritos, foi utilizado o software packet sniffer: Omnipeek e Wireshark

para registar todos os pacotes que circulavam na rede implementada em cada teste

prático. A monitorização efectuada possibilitou ao software Omnipeek gerar um relatório

completo do que se passou na rede, baseado na circulação dos pacotes existente, e foi

este o método em que se baseou grande parte da análise efectuada no próximo

subcapítulo.


Os esquemáticos utilizados nas experiências efectuadas para a preparação do aparato

utilizado durante o exercício de telemetria ao embate dos mísseis MILAN, foram

baseados na aquisição directa por parte de um computador portátil ligado ao

equipamento de recolha. Os equipamentos utilizados foram ligados a um router quando



os testes tiveram de ser efectuados com mais do que um equipamento em simultâneo.

Os esquemáticos dos aparatos experimentais, utilizados nos testes preliminares, podem

ser representados através das seguintes figuras:

Computador de

Aquisição Equipamento

Figura 83 – Aparato experimenta MILAN para apenas um equipamento

Router

Computador

de Aquisição

Equipamento 1

Equipamento 2

Equipamento 4

Equipamento 3

Figura 84 – Aparato experimental MILAN para mais do que um equipamento

5.3.4. RESULTADOS OBTIDOS E SUA INTERPRETAÇÃO

Os dados mais importantes obtidos através do software OmniPeek, Wireshark e BitMeter

vão ser descritos neste subcapítulo, sendo elaborada uma análise final aos dados e aos

comentários expostos na análise dos dados apresentados no subcapítulo seguinte.

Em cada situação de teste é indicada a configuração do aparato experimental utilizado,

representado convenientemente no subcapítulo anterior. Muitos mais testes foram

elaborados, sendo apenas seleccionados aqueles considerados mais significativos e que

trazem algo de novo à temática em estudo.

Método de recolha: Browser “Internet Explorer 8”

Aparato experimental utilizado: Figura 84 Descrição:

2 Arduinos Duemilinove

Protocolo de transferência: HTTP

Tempo de recolha: 21 Segundos Estimativa do valor por cada

60 minutos (3600s)

Total de Bytes recebidos: 12 461 234 Bytes 2 136 211 543 Bytes

Total de Pacotes recebidos: 115 417 Pacotes 19 785 771 Pacotes

Total de Bytes recebidos: (Arduino 1) 5 808 330 Bytes

Total de Pacotes recebidos: (Arduino 1) 54 837 Pacotes



Erros Não se verificaram

Máxima utilização da rede: 5,2 %

Tamanho dos pacotes (Bytes) 64 108 694 Pacotes

512-1023 6 723 Pacotes

Retransmissões: 6 647 Vezes Importância:

Alta

Tabela 28 – Resultados obtidos na leitura de 2 Arduinos (em simultâneo) utilizando um browser



A tabela anterior refere-se à captura durante 21 segundos de todo o tráfego de rede

gerado pela aquisição de dados de 2 Arduinos através de um browser (Internet Explorer

8). É necessário referir que cada Arduino se encontrava a adquirir dados de 6 portas

analógicas, sendo que no total representa a aquisição de 12 portas analógicas distintas.

A aquisição destes canais através de uma rede Ethernet permite velocidades de

transmissão máximas teóricas até 100 Mbps, ou seja, estamos a utilizar 5,2 % da sua

capacidade máxima de transmissão do canal de comunicação. Ao estabelecer uma

simples linha de raciocínio é possível afirmar que ao estabelecer esta ligação, tendo em

conta que 2 Arduinos correspondem aproximadamente a uma utilização de 5%,

poderíamos ligar no máximo 40 Arduinos (o que corresponde a 240 entradas analógicas).

Ao admitir que estamos em circunstâncias ideais e que conseguimos transmitir, utilizando

a norma IEEE 802.11g à taxa máxima teórica disponível por wireless (54 Mbps),

poderíamos sobrecarregar a ligação com a transferência de dados provenientes de 22

Arduinos em simultâneo (132 entradas analógicas).

A análise da tabela anterior demonstra que se todo o conteúdo dos pacotes que circula

na rede correspondesse a dados, o que tal não acontece pois cada pacote enviado tem

cabeçalho e campos de controlo, teríamos gerado cerca de 2 136 MBytes em dados ao

final de uma hora. Se estivéssemos a ler 40 Arduinos, admitindo que o tráfego na rede se

mantinha constante, iríamos gerar cerca de 4 2720 MBytes em dados no mesmo período.

Ao fim de 21 segundos verificaram-se 6 647 retransmissões, o que daria em 3 600

segundos (1 hora) um total de aproximadamente 1 139 486 retransmissões para apenas

dois Arduinos, o que é sem dúvida um factor a ter em conta. A existência de

retransmissões introduz tráfego na rede a mais do que o necessário para serem

transmitidos os dados adquiridos por cada Arduino, isto é, está perante uma baixa

eficiência na transmissão dos dados adquiridos. O grande número de retransmissões

acontece neste caso maioritariamente porque estamos a efectuar pedidos ao servidor

utilizando um browser de internet, que como é óbvio não se encontra optimizado para

este tipo de aplicação.

A grande maioria dos pacotes que circulou na rede, cerca de 95 %, tinham uma

dimensão inferior a 64 Bytes. Os restantes 5% uma apresentaram uma dimensão de 512

a 1 023 Bytes.



Método de recolha: Software “WinDaq”


1 Datalogger

Protocolo de transferência: TCP


60 minutos (3600s)

Total de Bytes recebidos: 188 570 Bytes 28 285 500 Bytes

Total de Pacotes recebidos: 1 706 Pacotes 255 900 Pacotes

Total de Bytes recebidos: (Datalogger) 187 954 Bytes

Total de Pacotes recebidos: (Datalogger) 1 702 Pacotes



Tamanho dos pacotes (Bytes) 64 567 Pacotes

128-255 1 139 Pacotes

Retransmissões: Não se verificaram Importância:

Não aplicável

Tabela 29 – Resultados obtidos na leitura de 1 Datalogger utilizando o seu software proprietário

O teste descrito pela tabela anterior representa a aquisição de dados durante 24

segundos provenientes de um Datalogger Dataq DI-710-EL, através do seu software

proprietário WinDaq. Foi efectuada a aquisição de apenas um canal analógico com uma

taxa de amostragem de 1800 S/s (máxima permitida pelo seu software sem adquirir uma

licença de utilização especial), sendo verificada uma utilização máxima da rede de cerca

de 0,07 %. O que indica que poderíamos transmitir (100 Mbps) dados de cerca de 1 429

canais analógicos e transmitir por wireless (54 Mbps) cerca de 772 canais analógicos à

taxa de amostragem referida. A transferência deste número de canais analógicos não é

possível a nível de software pois está limitado ao número máximo de canais analógicos

de apenas um Datalogger, sendo a taxa de amostragem, dividida pelo número de canais

pretendido (ver subcapítulo 4.2.5.).

É importante referir que durante os 24 segundos em que foi efectuada a monitorização da

rede foram enviados cerca de 0,1 MBytes e, à semelhança do que foi referido

anteriormente, se todo este volume de Bytes correspondesse a dados teríamos ao final

de 3 600 Segundos (1 hora) cerca de 28,28 MBytes em dados.

A aquisição de 1 429 canais analógicos durante uma hora gera 40 412 MBytes, sendo

que a aquisição de 772 canais analógicos gera 21 832 MBytes (admitindo que o fluxo de

pacotes a circular na rede se mantinha constante).

Dos pacotes que circularam na rede durante os 24 segundos monitorizados cerca de 33

% dos pacotes tinha uma dimensão inferior 64 Bytes, sendo que os restantes 67% tinham

uma dimensão compreendida de 128 a 255 Bytes.

Podemos comparar os dados obtidos até agora através da seguinte tabela:



Arduino Datalogger

Transmissão

Wireless (IEEE 802.11g)

Nº de canais Máximo

132 Canais Analógicos 772 Canais Analógicos

Volume de dados 23 496 MBytes 21 832 MBytes

Ethernet (100 Mbps)

Nº de canais Máximo

240 Canais Analógicos 1 429 Canais Analógicos

Volume de dados 42 720 MBytes 40 412 MBytes

Tabela 30 – Número de canais analógicos máximos em função do protocolo de transmissão escolhido

A tabela anterior indica que em condições ideais poderíamos transmitir cerca de mais

1189 canais analógicos recorrendo a Dataloggers em transmissão por Ethernet. Pelo que

a diferença para transmissão wireless é de 640 canais, utilizando Dataloggers face à

utilização de Arduinos, ao considerar valores de envio ideais.

O software BitMeter obteve os valores de download e upload durante a leitura de um

canal analógico a 1 800 S/s, utilizando o seu software proprietário, onde se obteve

durante este teste um pico máximo de download de aproximadamente 10,6 KBytes

(aproximadamente 84,8 Kbits) – ver apêndice H.

Método de recolha: Browser “Internet Explorer 8”


3 Arduinos



60 minutos (3600s)










Máxima utilização da rede: 9 %

Tamanho dos pacotes (Bytes)

64 259 396

65-127 17

256-511 19

512-1023 136

1024-1517 2 783

1518 8 949

Retransmissões: 4 618 Vezes Importância:

Alta

Não resposta do Cliente: 1 064 Vezes Importância:

Alta

Tabela 31 – Resultados obtidos na leitura de 3 Arduinos utilizando um browser

A tabela anterior relatada a captura, durante 65 segundos, de todo o tráfego de rede

gerada pela aquisição de três Arduinos em simultâneo através de um browser (Internet

Explorer 8). Este teste é semelhante ao efectuado com apenas dois Arduinos, em que

cada Arduino se encontra a adquirir dados de seis portas analógicas.



Ao adquirir estes canais através de uma rede Ethernet, que permite velocidades teóricas

de transmissão de 100 Mbps, estamos a utilizar aproximadamente 9% da sua capacidade

máxima de transmissão. Ao estabelecer esta ligação, e tendo em conta que três Arduinos

correspondem a 9% da sua capacidade total, poder-se-ia estabelecer trinta e três

Arduinos (198 entradas analógicas) no máximo. Se considerarmos que estamos em

circunstâncias ideais e que conseguimos transmitir utilizando a norma IEEE 802.11g à

taxa máxima por wireless, poderíamos sobrecarregar a ligação com a transferência de

dados de dezoito Arduinos em simultâneo (108 entradas analógicas).

Podemos aqui constatar, baseado nos testes anteriores, que não existe uma linearidade

entre o número dispositivos na rede e a máxima utilização da rede verificada, pois seria

de esperar um aumento de aproximadamente 2,6% ao contrário dos 3,8% verificados.

Pode-se assim concluir que existe uma diferença de 1,2% na máxima utilização verificada

da rede o que a este nível não é preocupante, pois encontramo-nos a utilizar poucos

dispositivos na rede, embora para um grande número deles, esta não linearidade possa

ser um factor de falha do sistema. Principalmente, se estivermos perante uma

comunicação wireless em que a taxa de transferência do canal de comunicação pode

encontrar-se severamente limitada, em relação ao volume de dados a transmitir.

A análise à tabela anterior indica que se todo o conteúdo dos pacotes que circulam na

rede correspondesse a dados teríamos gerado cerca de 1 892 MBytes em dados ao final

de uma hora. Contudo tal não acontece pois cada pacote enviado tem cabeçalho e

campos de controlo. Se estivéssemos a ler trinta e três Arduinos, iríamos gerar cerca de

20 812 MBytes em dados, admitindo que o tráfego na rede se mantinha constante.

Durante um total de 65 segundos verificaram-se 4 618 retransmissões, o que daria em 3

600 segundos (1 hora) um total de, aproximadamente, 255 766 retransmissões para três

Arduinos o que é, sem dúvida, um factor a ter em conta. Já que iríamos estar a introduzir

tráfego a mais na rede do que o necessário para transmitir os dados adquiridos por cada

Arduino.

Foram também verificadas 1 064 falhas de resposta do cliente, o que levaria a que em 3

600 segundos (1 hora) se fossem verificar, admitindo mais uma vez linearidade no

comportamento da rede, cerca de 58 929 falhas de comunicação entre o cliente e os

servidores (Arduinos), ou seja, estamos perante uma baixa eficiência na transmissão dos

dados adquiridos.

A maioria dos pacotes que circulou na rede teve uma dimensão inferior a 64 Bytes, cerca

de 259 396 pacotes, sendo a segunda maior fatia para pacotes com dimensão superior a



1 518 Bytes com cerca de 8 949 pacotes e a terceira maior fatia com 2 783 pacotes com

dimensões de 1 024 a 1 517 Bytes. Se existir uma falha de envio de um pacote e for

necessária retransmissão, existe uma probabilidade de perto de 96% que esse pacote

tenha uma dimensão inferior a 64 Bytes, uma probabilidade de aproximadamente 1% que

ele tenha uma dimensão entre 1 024 e 1 517 Bytes e uma probabilidade de cerca de 3%

de ser um pacote com uma dimensão superior a 1 518 Bytes. Este factor é importante

pois o pedido de retransmissão de um pacote inferior a 64 Bytes não deve ser encarado

com o mesmo peso de uma retransmissão de um pacote de dimensão superior a 1 518

Bytes, pois obviamente este vai sobrecarregar muito mais a rede de pacotes

teoricamente desnecessários.

Os valores download e upload durante a leitura de três Arduinos, obtidos utilizando o

software BitMeter, corresponderam a um pico máximo de download de aproximadamente

989,5 KBytes (aproximadamente 7 915,9 Kbits) – ver apêndice H.

Método de recolha: Software “IPView Pro”


1 Webcam



60 minutos (3600s)



Total de Bytes recebidos: (Webcam) 10 004 532 Bytes

Total de Pacotes recebidos: (Webcam) 9 847 Pacotes




64 3 288

65-127 11

128-255 33

256-511 35

512-1023 14

1024-1517 189

1518 6 279

Retransmissões: Não se verificaram Importância:

Não aplicável

Tabela 32 – Resultados obtidos na leitura de 1 Webcam utilizando o seu software proprietário

Os dados da tabela anterior representam a captura durante 22 segundos de todo o

tráfego de rede gerada pela aquisição de uma webcam através do seu software

proprietário - IPView Pro. Com uma resolução de vídeo de 640 x 480 e uma taxa de

compressão de vídeo MEDIUM, definidos pelo firmware90 da camera IP utilizada Trendnet

TV-IP100. A compressão de vídeo foi um método utilizado para alcançar alguma

eficiência na transmissão, visto o vídeo em bruto (sem qualquer tipo de compressão)

90

Software que regula o correcto funcionamento e operação de Hardware.



ocupar uma maior largura de banda que o vídeo comprimido (Wu, Hou, Zhu, Zhang e

Peha, 2001, p. 283). Outra técnica que pode ser utilizada é diminuir a frame rate (número

de frames enviados por segundo) que possibilita que menos dados tenham de ser

enviados, ocupando assim uma menor largura de banda (Wu, Hou, Zhu, Zhang e Peha,

2001, p. 284). Mas, logicamente, que ao enviar menos frames por segundo, vai existir

uma menor capacidade de captar fenómenos rápidos como o fenómeno particular em

estudo, que necessita de capturar o maior número de frames possível por segundo.

Ao efectuar alguns cálculos simples, admitindo que o míssil Seasparrow toma uma

velocidade máxima de 4256 km/h (FAC, 1999), o que corresponde a aproximadamente

1182 m/s e que uma simples webcam consegue captar 30 fps (frames per second, ou em

português frames por segundo), vamos ter que

. Assim em cada frame

capturado pela webcam, se o míssil estiver à sua velocidade máxima teórica vai-se

deslocar cerca de 39,4 m, sendo portanto, a captura de um simples frame do

deslocamento do míssil uma questão de sorte, no exemplo apresentado anteriormente.

A transmissão de vídeo é um dos principais obstáculos, estando à primeira vista

descartada a possibilidade de envio dos dados da camera de alta-velocidade via wireless,

pois a mesma precisa de uma rede que permita velocidades de transferência de 1 Gbps e

tal não é possível utilizando a norma IEEE 802.11g. No entanto, pela análise dos dados

apresentados pode-se constatar que a maior taxa de utilização verificada na rede a partir

da webcam foi de cerca de 4,5 %, o que corresponde aproximadamente à aquisição de

dados de dois Arduinos utilizando um browser (perto de 5,2 %).

A Camera IP não verificou qualquer necessidade de retransmissão dos dados enviados,

o que pode ter acontecido pois esta era o único dispositivo ligado na rede. Contudo esta

dúvida irá ser retirada após a análise da última tabela deste subcapítulo, que corresponde

à aquisição de um Arduino, do Datalogger Dataq e de uma webcam.

A grande maioria dos pacotes que circularam na rede tinha uma dimensão superior a

1518 Bytes, sendo a sua percentagem de 64 %, o que corresponde à maior

percentagem, pois os pacotes com uma dimensão superior a 64 Bytes corresponderam a

uma percentagem de 33,4 %. Verificou-se desta forma uma clara circulação de pacotes

de elevadas dimensões pelo que ao surgir uma necessidade de retransmissão vão ser

introduzidos na rede pacotes supostamente desnecessários e de elevadas dimensões, o

que se pode tornar prejudicial ao rendimento da rede.



Recorrendo ao software BitMeter, foi obtido um pico máximo de download de

aproximadamente 0,44 MBytes (aproximadamente 3,5 Mbits) – ver apêndice H.

Método de recolha: Software “Matlab”

e “IPView Pro”

Aparato experimental utilizado: Figura 84

Descrição:

1 Arduino + 1 Webcam + 1 Datalogger Dataq

Protocolo de transferência: HTTP e TCP


60 minutos (3600s)





Total de Bytes recebidos: (Datalogger) 381 776 Bytes

Total de Pacotes recebidos: (Datalogger) 1 930 Pacotes

Total de Bytes recebidos: (Webcam) 8 009 985 Bytes

Total de Pacotes recebidos: (Webcam) 7 836 Pacotes


Máxima utilização da rede: 5 %

Tamanho dos pacotes

64 140 419

65-127 3

128-255 65

256-511 1 229

512-1023 118

1024-1517 325

1518 4 930

Não resposta do cliente 1 Vez Importância:

Alta

Tabela 33 – Resultados obtidos na leitura de 1 Webcam, 1 Datalogger e 1 Arduino

Os dados visíveis na tabela anterior resultam da captura durante 42 segundos, de todo o

tráfego de rede gerado pela aquisição de uma webcam (IPView Pro), de um Datalogger

(WinDaq) e um Arduino (Matlab). A resolução do vídeo adquirido pela Webcam foi 640 x

480 com uma taxa de compressão de vídeo MEDIUM, definidos pelo firmware da camera

IP Trendnet TV - IP100. Por sua vez, o Datalogger encontrava-se a adquirir dados de um

canal analógico com uma taxa de amostragem de 1800 S/s, estando o Arduino a adquirir

dados de seis entradas analógicos (número máximo de entradas analógicas disponíveis).

A aquisição por Ethernet utilizando dois Arduinos, e recorrendo ao software de aquisição

Matlab, possibilitou uma taxa de amostragem de aproximadamente 26 S/s por canal. Esta

baixa taxa de amostragem conseguida deveu-se essencialmente à baixa optimização

demonstrada pelo código em Matlab desenvolvido. Este é um ponto a melhorar em

abordagens futuras, visto que é, evidentemente, condicionante e, de acordo com o

teorema de amostragem, apenas vamos conseguir amostrar sinais com uma frequência



menor ou igual a 13 Hz. Mas este assunto vai ser abordado com mais rigor no

subcapítulo 5.4.

A utilização da rede levada a cabo pela camera IP, através da aquisição pelo seu

software proprietário, é de aproximadamente 4,5% da máxima capacidade da rede. A

capacidade máxima da rede utilizada durante este teste foi de cerca de 5%, o que leva a

que os restantes 0,5% de utilização da rede sejam por parte do Arduino e do Datalogger.

O Datalogger já tinha apresentado valores de aproximadamente 0,07% de utilização da

rede através do seu software WinDaq e, admitindo que a mesma utilização da rede se

mantém, restam 0,43% para a aquisição com o Arduino. Desta forma, utilizando o

software Matlab existe um claro decréscimo da utilização necessária na rede para

adquirir os dados provenientes do Arduino, descendo de 2,6% para 0,43%. Pelo que é,

sem dúvida, uma enorme vantagem e, apesar da baixa taxa de amostragem verificada,

permite ligar um maior número de Arduinos em rede ao recorrer ao software Matlab.

Assim, o Matlab permite facilitar o armazenamento e, posterior, análise dos dados, face à

utilização de um browser que apenas mostra os dados e permite guardá-los em formato

HTML ou em formato de texto (e.g. “.txt”). Outro factor importante, e que ajuda a este

acréscimo de rendimento por parte do software Matlab, é a não existência de

retransmissões.

A circulação verificada na rede de pacotes com dimensão superior a 1 518 Byte, e tendo

em conta o referido anteriormente, terá tido origem na webcam levando a um maior fluxo

de pacotes destas dimensões na rede. Sendo que durante todo o teste se verificou

apenas um erro a ter em conta - a não resposta do cliente - o que leva a uma queda de

performance na rede.

Recorrendo ao software BitMeter foram obtidos os valores de download e upload, onde

se obtiveram durante este teste um pico máximo de download de 2,35 MBytes (perto de

4,7 Mbits) – ver apêndice H.

Nas figuras abaixo estão representados os valores de download e upload durante a

aquisição de um Datalogger e um Arduino, utilizando o software Matlab. Estas figuras

representam o espaço de armazenamento necessário para armazenar os dados

provenientes dos dispositivos de rede enumerados anteriormente.



Figura 85 – Leitura de 1 Arduino e 1 Datalogger utilizando o software BitMeter

Na Figura 85 foram registadas as actividades de download e upload na rede durante

9844 segundos (aproximadamente 2 horas e 44 minutos), tendo-se verificado um

download de 1,8 Gbytes. Na Figura 86 foi registado o comportamento da rede para o

mesmo aparato experimental, utilizando também o software Matlab como método de

recolha, contudo durante um período menor de 4500 Segundos (perto de 1 hora e 48

segundos), tendo-se verificado um download de 1,21 Gbytes.

Figura 86 – Leitura de 1 Arduino e 1 Datalogger utilizando o software BitMeter



5.3.5. CONCLUSÕES

A monitorização do exercício de tiro com mísseis MILAN foi bastante importante, pois

possibilitou um incentivo para efectuar recolha de informação referente ao

comportamento de cada equipamento. Na tentativa de tirar o máximo proveito de cada

oportunidade, todos os testes elaborados foram aqui expostos com vista a retirar algum

sumo do que foi elaborado, pois deve-se aprender com o passado para conseguir

modificar o presente e melhorar assim o futuro.

A descrição do exercício propriamente dito e montagens utilizadas, poderá ser consultado

o apêndice E, no relatório elaborado. Este relatório expressa toda a preparação do

exercício em termos de hardware e de código de aquisição, elaborado para o software

Matlab, sendo o seu ponto mais forte referir todas as dificuldades encontradas e que no

futuro, se houver a necessidade de repetir o exercício, devem ser ultrapassadas.

A análise à utilização de dispositivos de rede reveste-se de uma enorme importância,

pois é necessário saber qual o seu comportamento, quer em termos de largura de banda

necessária para a transmissão dos dados provenientes dos sensores, quer mesmo em

relação ao tamanho dos pacotes enviados. A análise da rede, recorrendo a um software

que permita efectuar packet sniffer como o OmniPeek, possibilita identificar não só os

parâmetros descritos anteriormente, mas também, através da correcta análise dos dados

obtidos, permite identificar problemas que possam estar a surgir na rede. Esses

problemas identificados podem passar da demonstração da ocorrência de inúmeras

retransmissões até à ocorrência de inúmeras falhas de resposta por parte do cliente de

uma comunicação (Sanders, 2007, p. 102 e 110).

Os testes efectuados por Capela, Pessanha, Vieira e Monsanto, à distância de 7,49 km

entre antenas omnidireccionais, com um ganho de 10 dBi, conseguiram obter taxas de

transferência da ordem dos 68 kBps (544 kbps) (Capela, Pessanha, Vieira e Monsanto,

2008, p. 9 e 10). Foi também testada qual a taxa de transferência necessária para

transmitir dados da webcam e do Datalogger utilizando exactamente os mesmos modelos

dos testes descritos anteriormente. Contudo verificou-se, para a leitura de 16 canais

analógicos do Datalogger, a necessidade de ter uma taxa de transferência de 15 kBps

(120 kbps) e para a webcam uma taxa de transferência de 200 kBps (1 600 kbps). Nos

testes, anteriormente descritos, foi efectuada a aquisição de apenas um canal analógico,

com uma taxa de amostragem igual à descrita por Capela, Pessanha, Vieira e Monsanto

nos testes elaborados, tendo sido obtida uma taxa de transferência necessária de 70

kbps (9 kBps). Como a taxa de amostragem do Datalogger se divide pelo número de



canais e não se acrescenta carga de processamento, estes valores vão ser comparados,

apesar do teste efectuado não ser rigorosamente o mesmo. O valor, referido

anteriormente, corresponde à utilização máxima da rede, sendo óbvia uma diferença de

valor de 6 kBps (48 kbps) entre os dois testes efectuados. Esta diferença terá tido origem

numa falta de precisão nos métodos utilizados anteriormente, sendo agora utilizado

software profissional na determinação destes valores.

Nos testes de alcance referidos também se efectuou o envio de imagens da webcam,

recorrendo à sua leitura através de um browser de internet e tendo sido adquirido vídeo

através do firmware da própria camera (Capela, Pessanha, Vieira e Monsanto, 2008, p.

9). Para essa transferência de dados foi necessária uma taxa de transferência de 200

kBps (1 600 kbps), mas utilizando o software de aquisição e gravação IPView Pro foi

obtida uma taxa de transferência de 562,5 kBps (4 500 kbps). A utilização deste software

originou uma diferença de 362,5 kBps na taxa de transferência necessária. Este factor é

de uma enorme importância, pois é preciso ter em consideração que, se não for

encontrada uma alternativa fiável para armazenamento das imagens da camera, serão

necessários 562,5 kBps para a transmissão de vídeo.

De acordo com o referido anteriormente, em que à distância de 7,49 km foi obtido uma

taxa de transferência de 68 kBps (544 kbps), se tivéssemos a utilizar um Arduino para

efectuar a aquisição de dados (e utilizando o software Matlab) seria necessária uma taxa

de transferência de 430 kbps. Assim pode-se afirmar que, à distância citada

anteriormente, apenas poderíamos transmitir dados provenientes de um Arduino

Duemilinove, face à possibilidade de utilização de 7 Dataloggers Dataq DI-710-EL.

Apesar de os Dataloggers serem perto de 16 vezes mais caros por unidade do que os

Arduino, têm sem dúvida um desempenho a nível de rede extremamente elevado, o que

indica que se a alternativa for o uso de Arduino que todo o seu firmware muito

possivelmente tenha de ser reescrito. Esta modificação com certeza não será suficiente,

devendo também existir uma reestruturação das bibliotecas Ethernet existentes até ao

momento em virtude de as mesmas não estarem optimizadas ao nível pretendido. Só

após a conclusão destes passos e não se verificando melhorias significativas na

performance apresentada se deve descartar a possibilidade da sua utilização. Sendo que

uma alternativa será, e sendo a que vai ser adoptada, melhorar o ganho nas antenas de

transmissão possibilitando assim aumentar a largura de banda disponível na

comunicação wireless.



Podemos resumir de uma forma muito simples as taxas de transmissão necessárias,

recorrendo à seguinte tabela:

Equipamento: Taxa de transmissão

necessária - kBps Taxa de transmissão

necessária - kbps Dataq DI-710-EL

(16 Canais Analógicos) 9 72

Webcam (IPView Pro) 562,5 4 500

Arduino Duemilinove (6 canais analógicos)

54 432

Tabela 34 – Resumo dos resultados obtidos experimentalmente

Os testes efectuados são bastante importantes, pois ao colocar um grande número de

dados a circular na rede sem ter uma ideia clara de quais as suas necessidades de

transmissão pode originar erros graves e mesmo impossibilidade de envio (Crovella,

1999, p. 2).

5.4. MATLAB E ARDUINO – CAPACIDADES DE AQUISIÇÃO

No âmbito deste estudo, torna-se necessário efectuar uma abordagem exaustiva sobre

as capacidades de aquisição, nomeadamente do hardware utilizado – Arduino

Duemilinove – e o software usado na aquisição de dados provenientes desta ferramenta

de desenvolvimento – Matlab. Foi também utilizado este software para aquisição de

dados provenientes do Datalogger Dataq adquirido, pois permite a aquisição numa taxa

de amostragem de 4 800 S/s, ao contrário dos 1 800 S/s conseguidos com o software

WinDaq, sem adquirir uma licença de utilização bastante dispendiosa.

Os testes efectuados a este nível pretendem caracterizar o desempenho obtido por um

Arduino Duemilinove equipado com um microcontrolador ATmega168 quando conjugados

com o software Matlab, pois não interessa só a capacidade de amostragem do seu

conversor A/D. Pois pode-se ter um microcontrolador que efectue a aquisição numa

quantidade de tempo aceitável, mas se demora demasiado tempo a enviar esses dados

ou se o software situado na unidade de aquisição também não apresenta uma velocidade

de processamento aceitável, toda a performance do sistema pode ser afectada. O que

fará com que, em certos casos, se possa tornar inútil a informação, dependendo do

fenómeno concreto que se pretende medir e, posteriormente, analisar ou reconstruir.

Esta linha de raciocínio leva-nos a efectuar várias medições de forma a retratar todo o

caminho descrito pelos dados. Pelo que se mediu o tempo necessário desde a aquisição



pelo microcontrolador (conversão do sinal de analógico para digital), respectivo envio,

recepção e leitura pelo software Matlab.

Nos próximos subcapítulos vai-se descrever a montagem utilizada para efectuar este

teste, bem como efectuados os comentários convenientes para a sua correcta

compreensão.


Os objectivos deste teste centram-se, essencialmente, na necessidade de conseguir

quantificar a taxa de amostragem que se consegue obter, recorrendo ao hardware e

software, pois esta influencia directamente o tipo de fenómenos que se conseguem

monitorizar.

Uma vez que a taxa de amostragem está directamente ligada à frequência de Nyquist e

que o fenómeno a monitorizar se prevê bastante rápido, esta abordagem reveste-se de

uma extrema importância.

As experiências práticas foram efectuadas recorrendo a um computador portátil equipado

com uma placa de rede Realtek RTL8168C/8111C (P), um Arduino Duemilinove e

respectivo shield Ethernet (quando a aquisição é efectuada por Ethernet). O computador

utilizado para correr o software de aquisição Matlab e adquirir os dados provenientes do

Arduino foi um computador equipado com 4 Gbytes de memória RAM, apetrechado com

um Intel® Core™ 2 Duo T9400 (2,53 GHz) a correr o Windows 7 Ultimate na sua versão

de 32 bits.

Os testes efectuados destinam-se a comparar a performance do Arduino com o

Datalogger adquirido para o mesmo fim. Mas, além de contemplar a velocidade que o

hardware demora a efectuar tal operação, é necessário acrescentar mais variáveis, que

são: o tempo de envio e o tempo de aquisição que a conjugação entre o hardware e o

software nos disponibilizam. Ao utilizar o software Matlab pelas suas potencialidades no

Mundo do tratamento matemático tornou-se essencial testar a sua performance também

a este nível.


Os testes propriamente ditos foram efectuados de uma maneira bastante simples e

recorrendo a funções de controlo de tempo das bibliotecas presentes no software Arduino



e Matlab, proporcionando assim medidas de tempo fiáveis. Senão se recorresse a estas

funções seria muito complicado medir estes fenómenos, pois a sua duração é da ordem

dos microsegundos ( s). Sendo estes praticamente (senão mesmo) impossíveis de medir

com e.g. um cronómetro com uma alta precisão, mesmo recorrendo a um operador

altamente treinado. Todo o código utilizado está disponível no apêndice H, sendo aqui

retratados apenas os resultados mais importantes para alcançar os objectivos propostos.

O tempo final na aquisição pode ser descrito pelas equações representadas abaixo,

dependendo este tempo, logicamente, do tipo de comunicação utilizado.

(10)

(11)

Como é visível pela análise das equações anteriormente descritas, as diferenças

existentes entre os dois tipos de comunicação são as seguintes:

Tempo de envio no Arduino (comunicação série ou Ethernet);

Tempo de aquisição no Matlab (se adquire dados por série ou Ethernet).

Na comunicação por Ethernet, a ligação é caracterizada por ser full-duplex, não sendo

configurável qualquer parâmetro de taxa de transferência. Contudo o mesmo não se

verifica na comunicação por série, em que a baud rate91 pode ser configurada tomando

vários valores possíveis no Arduino de 300 a 115 200.

Como foi referido anteriormente e de acordo com informação disponível no datasheet do

microcontrolador ATmega168, a primeira conversão A/D demora 25 ciclos de relógio,

enquanto as restantes conversões demoram 13 ciclos de relógio (Atmel, 2009). O relógio

de sistema é dividido por um factor denominado prescaler, sendo este o relógio final que

teoricamente dá entrada no conversor A/D.

Os valores experimentais obtidos para cada uma destas situações, permitiram então

visualizar a diferença existente a este nível. Da mesma forma, como foram obtidos os

tempos da conversão A/D, foram também obtidos os tempos da instrução de envio por

série e de envio por Ethernet. Estes permitiram contabilizar o tempo que vai da aquisição

ao envio, para armazenamento numa unidade de aquisição. Posteriormente e após os

testes terem sido concluídos foi efectuada a medição dos tempos que o software Matlab

demora a ler os dados que lhe são enviados, tanto por série como por Ethernet.

91

Indica o número de símbolos que são transmitidos por segundo, que no caso da comunicação por série apenas podem tomar o valor lógico 0 ou 1.



Ao que foi referido anteriormente falta acrescentar o tempo que o software Matlab

demora a guardar os dados recebidos e.g. numa matriz ou a fazer algum processamento

matemático, mas esse tempo depende da optimização do código utilizado. Esse factor

não vai ser contemplado pois os dados podem ser guardados ou trabalhados de

inúmeras formas, devendo cada utilizador desenvolver o código mais

adequado/optimizado à sua aplicação em concreto.


Os esquemáticos utilizados basearam-se na simples ligação utilizando um cabo de

ligação USB - Universal Serial Bus - para as comunicações série e um cabo UTP92 de

categoria 5 com ficha RJ4593 para comunicações via Ethernet. Os esquemáticos

utilizados foram os seguintes:

Computador

de Aquisição

Comunicação

Série

Arduino

Figura 87 – Esquemático utilizado para os testes ao tempo de conversão A/D e tempo de envio por série

Computador

de AquisiçãoArduino

+

Shield Ethernet

Comunicação

Ethernet

Figura 88 – Esquemático utilizado para os testes ao tempo de envio por Ethernet

A descrição dos resultados obtidos vai ser efectuada no próximo subcapítulo,

determinando assim as taxas de amostragem máximas que realmente se conseguem

obter. Interessando, principalmente, qual a velocidade com que conseguimos recolher as

amostras por software, pois será essa a taxa de amostragem útil que vamos conseguir

obter ao nível do utilizador.

92

Unshielded Twisted Pair é usado na maioria das aplicações de ligação por Ethernet devido ao seu baixo custo comparativamente com a fibra óptica ou o cabo coaxial. 93

Designa o tipo de ficha presente no cabo UTP referido no texto.




Inicialmente mediram-se os tempos reais utilizados pelo microcontrolador na conversão

A/D, efectuando a média de 1000 dos valores (recorrendo ao software Matlab) obtidos

experimentalmente. Ao modificar o factor de divisão do relógio (Prescaler) de entrada do

conversor A/D, obtiveram-se os tempos de amostragem (em microsegundos e segundos),

descritos na seguinte tabela:

Factor de divisão (Prescaler) Tempo gasto na aquisição ( ) Tempo gasto na aquisição (Segundos)

2 8,02 0,000008024

2 8,08 0,000008084

4 8,37 0,000008372

8 14,94 0,000014936

16 19,92 0,000019924

32 32,72 0,000032716

64 60,32 0,00006032

128 112,07 0,000112072

Tabela 35 – Tempos de conversão A/D obtidos experimentalmente

Estes valores podem ser relacionados com a taxa de amostragem que é possível obter,

sendo descrita na Tabela 37 o valor da taxa de amostragem para cada valor de prescaler,

convertendo o valor obtido para MS/s e multiplicando esse valor por um factor de 13

(tempo da conversão A/D), obtemos o relógio de entrada no conversor A/D. Os valores

obtidos foram os seguintes:

Factor de divisão Taxa de amostragem (S/s) Relógio de entrada no ADC (MS/s) - 13 ciclos de relógio

2 124 626,12 1,62

2 123 701,14 1,61

4 119 445,77 1,55

8 669 52,33 0,87

16 501 90,72 0,65

32 305 66,08 0,40

64 165 78,25 0,22

128 8 922,84 0,12 Tabela 36 – Taxas de amostragem obtidas dependendo do valor de prescaler

A diferença entre os valores teoricamente esperados e os obtidos experimentalmente

pode ser expressa através da seguinte tabela:

Factor de divisão Taxa de amostragem (S/s) Taxa de amostragem teórica (S/s) Diferença (S/s)

2 124 626 615 384 490 758

2 123 701 615 384 491 683

4 119 446 307 692 188 246

8 66 952 153 846 86 894

16 50 191 76 923 26 732

32 30 566 38 461 7 895

64 16 578 19 230 2 652

128 8 923 9 615 692

Tabela 37 – Diferença entre a taxa de amostragem obtida experimentalmente. e a teoricamente esperada



Como se pode constatar os valores obtidos do relógio de entrada são bastante inferiores

aos teoricamente esperados, pois se o relógio de sistema é de 16 MHz e se e.g. existir

um factor de prescaler de 2 vamos ter um relógio de entrada no conversor A/D de 8 MHz.

Assim se cada conversão demorar 13 ciclos de relógio, iríamos ter, teoricamente, 615

384 amostras por segundo. Mas experimentalmente verifica-se uma aquisição de apenas

124 626 amostras, ou seja, cerca de menos 490 758 amostras por segundo.

A Tabela 37 demonstra que as maiores diferenças se situam para valores de prescaler

baixos (como seria de esperar), obtendo o valor mínimo nesta diferença para um valor de

prescaler de 128. O que vai de encontro ao referido no relatório técnico elaborado pela

ATmel o AVR120, em que é referido que devem ser utilizadas frequências de relógio de

entrada de 200 kHz para obter uma boa performance (Corporation, 2006, p. 10).

O relatório referido anteriormente também refere que frequência de entrada pode ir até a

um máximo de 1 MHz, sem ocorrer uma quebra significativa na sua performance. Para

um valor abaixo dos 200 kHz com um factor de prescaler de 128, obtemos um relógio de

entrada de 125 kHz e, como foi referido anteriormente, é o que apresenta os valores mais

próximos do teoricamente esperado (diferença de aproximadamente 7% face ao

esperado). Contudo ao analisar a restrição ao relógio de entrada imposta pela ATmel

para a obtenção de uma performance aceitável do conversor A/D, teríamos de

seleccionar um factor de prescaler de 16, com o qual obtemos diferenças de cerca de 26

732 amostras por segundo face ao teoricamente esperado. Verifica-se uma diferença

entre os valores teóricos e os experimentalmente aceitáveis (de acordo com a sua

documentação técnica) de aproximadamente 35%.

Após a abordagem da taxa de amostragem, torna-se necessário referir que o próximo

passo será o envio desses dados, quer seja por série ou por Ethernet. Neste envio é

necessário ter em conta que a comunicação série tem a possibilidade de definir a baud

rate utilizada não acontecendo o mesmo com o protocolo Ethernet que transmite à maior

taxa de transferência disponível (o máximo teórico centra-se nos 100 Mbps). Assim, para

o estudo da comunicação série, foram enviados os dados recorrendo a baud rates de 300

e 115 200, possibilitando assim uma comparação entre os dois extremos da gama de

baud rates disponível.



Factor de divisão Tempo gasto na aquisição (s) Tempo total (s) - 115 200 Tempo total (s) - 300

2 0,000008024 0,000104024 0,032216024

2 0,000008084 0,000104084 0,032216084

4 0,000008372 0,000104372 0,032216372

8 0,000014936 0,000110936 0,032222936

16 0,000019924 0,000115924 0,032227924

32 0,000032716 0,000128716 0,032240716

64 0,00006032 0,000156320 0,032268320

128 0,000112072 0,000208072 0,032320072

Tabela 38 – Tempos totais da aquisição e envio com diferentes taxas de amostragem e baud rates

Os tempos obtidos na conversão A/D e envio por série encontram-se descritos na tabela

anterior, e vão ser transcritos numa variável à qual, para simplificar a compreensão, vai

continuar a tomar o nome de taxa de amostragem.

Factor de divisão Taxa de amostragem (S/s) - 115 200 Taxa de amostragem (S/s) - 300

2 9 613,17 31,04

2 9 607,62 31,04

4 9 581,11 31,04

8 9 014,21 31,03

16 8 626,34 31,03

32 7 769,04 31,02

64 6 397,13 30,99

128 4 806,03 30,94

Tabela 39 – Taxas de amostragem obtidas na leitura e envio de dados por série

A taxa de amostragem efectivamente útil, obtida na aquisição por Matlab, ainda vai ser

inferior ao obtido na tabela anterior. Porém o seu conhecimento é essencial, pois é com

essa taxa de aquisição que vamos poder contar ao domínio do utilizador. Pela análise da

Tabela 39 podemos constatar experimentalmente a clara diferença entre a utilização de

uma baud rate de 300 e de 115 200.

Paralelamente à medição do tempo de conversão A/D e por envio série, foi efectuada a

conversão A/D e o envio por Ethernet. Os valores obtidos podem ser visualizados através

da seguinte tabela:

Factor de divisão Tempo gasto na aquisição (s) Tempo total (s)

2 0,000008024 0,001125254

2 0,000008084 0,001125314

4 0,000008372 0,001125602

8 0,000014936 0,001132166

16 0,000019924 0,001137154

32 0,000032716 0,001149946

64 0,00006032 0,001177550

128 0,000112072 0,001229302

Tabela 40 – Tempos totais da aquisição e envio por Ethernet

Os tempos obtidos na conversão A/D e envio por Ethernet, e partindo da análise da

tabela anterior, foram transcritos numa variável à qual para simplificar a apreensão vai



continuar a tomar o nome de taxa de amostragem (à semelhança do sucedido

anteriormente).

Analisando a Tabela 41 e a comunicação com uma baud rate de 115 200 na Tabela 39, é

possível constatar que se obtêm valores de taxa de amostragem superiores neste caso.

Mas é claro que aos valores obtidos ainda falta acrescentar o tempo que o software de

aquisição Matlab demora a ler os valores enviados. Como se verifica todo o processo de

aquisição desde a conversão A/D até à leitura por parte de e.g. um computador reveste-

se de pormenores que fazem com que a performance que inicialmente no hardware se

torne bastante satisfatória passe rapidamente a valores inaceitáveis ao nível do utilizador

(Matlab). Mas para tirar algumas conclusões é necessário referir concretamente qual a

taxa de amostragem que se vai obter ao nível do utilizador, tendo sido obtidos, nos testes

efectuados, os seguintes resultados:

Factor de divisão Taxa de amostragem (S/s) - Pedido browser

2 888,69

2 888,64

4 888,41

8 883,26

16 879,39

32 869,61

64 849,22

128 813,47

Tabela 41 – Taxas de amostragem obtidas na leitura e envio de dados por Ethernet

Factor de divisão Taxa de Amostragem final (115 200) – S/s

Taxa de Amostragem final (300) - S/s

Taxa de Amostragem final (115200) – MS/s

Taxa de Amostragem final (300) – MS/s

2 93,12 23,34 0,093118 0,023337

2 93,12 23,34 0,093118 0,023337

4 93,12 23,34 0,093115 0,023336

8 93,06 23,33 0,093058 0,023333

16 93,02 23,33 0,093015 0,023330

32 92,90 23,32 0,092905 0,023323

64 92,67 23,31 0,092667 0,023308

128 92,22 23,28 0,092225 0,023280 Tabela 42 – Taxas de amostragem obtidas na leitura, envio de dados por série e leitura Matlab

Factor de divisão Taxa de Amostragem final - S/s Taxa de Amostragem final – MS/s

2 232,11 0,232113

2 232,11 0,232109

4 232,09 0,232094

8 231,74 0,231741

16 231,47 0,231473

32 230,79 0,230790

64 229,33 0,229329

128 226,64 0,226639

Tabela 43 – Taxas de amostragem obtidas na leitura, envio de dados por Ethernet e leitura Matlab



As duas tabelas anteriores indicam que o envio e aquisição por Ethernet se revela mais

eficaz do que o envio por série. As diferenças entre a aquisição por série com uma baud

rate de 115 200 e a aquisição por Ethernet, são descritas na seguinte tabela:

Factor de divisão Diferença entre série (115 200) e Ethernet em S/s

2 138,99

2 138,99

4 138,97

8 138,68

16 138,45

32 137,89

64 136,66

128 134,42

Tabela 44 – Diferenças entre as taxas de amostragem finais por série (115 200) e Ethernet

A diferença entre os tipos de protocolo de comunicação nesta fase, e analisando a tabela

anterior, situa-se próximo das 138 S/s de diferença a favor da comunicação por Ethernet.

Segundo o teorema de Nyquist e, supondo que se selecciona a comunicação por

Ethernet e os dados de apenas uma entrada analógica disponibilizada pelo Arduino,

vamos poder amostrar um sinal de entrada com uma variação máxima de

aproximadamente 116 Hz. Se desejarmos adquirir dados provenientes das 6 entradas

analógicas que o Arduino disponibiliza teríamos de dividir o valor anterior por 6,

permitindo o armazenamento de dados, sem o risco de ocorrer aliasing do sinal de

entrada, com uma variação máxima de aproximadamente 20 Hz.

Ao comparar esta performance com a do Datalogger adquirido cuja taxa de amostragem,

como referido anteriormente, se situa nos 4 800 S/s divididos pelo número de canais,

com a qual iríamos obter uma taxa de amostragem máxima de 300 S/s por canal. O que

nos permitiria amostrar com rigor sinais de uma frequência inferior a 150 Hz. Mas não

podemos, no entanto, esquecer que o custo de aquisição de um Datalogger do modelo

referido anteriormente custa cerca de 16 vezes mais que o custo de aquisição de um

Arduino Duemilinove.

Este subcapítulo pode ser resumido da seguinte forma:

Equipamento Nº de entradas

lidas em simultâneo Taxa de amostragem obtida por canal (S/s)

Frequência máxima do sinal de entrada (Hz)

Arduino Duemilinove (Ethernet)

6 40 20

Arduino Duemilinove (Série – 115 200)

6 16 8

Datalogger Dataq DI-710-EL

16 300 150

Tabela 45 – Resumo dos resultados obtidos



As taxas de amostragem presentes na tabela anterior são as taxas de amostragem

obtidas ao nível do utilizado, dependendo do tipo de software de aquisição escolhido e do

processador em que este está a ser executado.

Como se pôde verificar o principal factor de limitação não é o tempo da conversão A/D do

próprio microcontrolador, mas sim o tempo gasto no envio e aquisição por parte do

software Matlab.

5.4.5. CONCLUSÕES

A melhor opção utilizando a ferramenta de aquisição Arduino e o software Matlab é a

aquisição por Ethernet. Mas apesar desta vantagem em relação à amostragem por série,

mesmo recorrendo a uma baud rate elevada, a variação máxima do sinal de entrada

(sem ocorrer aliasing) situa-se nos 116 Hz (para apenas uma entrada analógica). Se

estivermos a sobrecarregar um Arduino com a sua capacidade máxima (6 entradas

analógicas) a taxa de amostragem cai logo 6 vezes para 20 Hz, o que é um valor baixo

face à especificidade do fenómeno que se pretende registar.

5.5. CÂMARA DE ALTA-VELOCIDADE

A utilização de uma camera de alta-velocidade reveste-se de enorme importância no

contexto deste estudo, pois a elevada velocidade do projéctil a registar carece de uma

elevada frame rate. Ao utilizar uma camera deste tipo, estar-se-á a aumentar

grandemente as possibilidades de conseguir captar imagens do projéctil, para poder

saber exactamente quais os fenómenos originados no embate.

A camera de alta-velocidade utilizada foi o modelo GC 640C da marca Prosilica – camera

IP que estabelece uma ligação por Gigabit Ethernet, que, recorrendo ao seu software

ProStream94 1.3.1, permite a captura e gravação de vídeo, cuja frame rate depende da

dimensão do vídeo. A máxima frame rate utilizável com este modelo situa-se nos 759 fps

para um vídeo com as dimensões 659 x 12395.

94

Site oficial http://www.ProStreamSoft.com. 95

Descrição da resolução em pixels em que o primeiro número é a quantidade de colunas (largura) e o segundo é o número de linhas (altura). Um pixel é caracterizado como o menor elemento num dispositivo de exibição (e.g. monitor), ao qual é possível atribuir uma cor.



Figura 89 – Representação esquemática das dimensões óptimas do vídeo

A recolha de imagens deve ser feita com a melhor relação frame rate/dimensão do vídeo.

Após alguns testes, modificando as opções do software referido anteriormente, facilmente

se encontraram os valores considerados adequados.


Ao possuirmos uma camera de alta-velocidade, sabendo que ela se baseia numa ligação

Gigabit Ethernet, por si só não trás qualquer tipo de informação acerca do seu

funcionamento. Contudo, num meio em que a largura de banda necessária para a

comunicação pode ser limitada, esta análise reveste-se de grande importância.

O objectivo primordial deste teste foi obter a largura de banda necessária para a

comunicação, à medida que se faz variar a frame rate e a dimensão do vídeo na tentativa

de perceber mais aprofundadamente qual o funcionamento desta camera. Ao obter a

melhor configuração possível espera-se que esta seja bastante útil para conseguir

capturar imagens de um míssil Seasparrow a embater numa unidade naval, devido à sua

elevada frame rate.


Os testes efectuados com a camera de alta-velocidade recorreram ao software referido

anteriormente, o ProStream 1.3.1 fazendo variar os parâmetros de operação da camera.

A aquisição de dados que possibilitasse descrever o comportamento da rede foi

efectuada através do software BitMeter e OmniPeek, que por sua vez permitiram a

representação e análise dos dados obtidos.

Numa primeira fase, foram gravados para cada configuração através do software, alguns

segundos de utilização quer no modo live (visualização de vídeo sem guardar) e stream

(visualização e gravação do vídeo). Este método de teste procurou assim aferir quais são

os parâmetros de funcionamento mais adequados, muito à semelhança do efectuado na

preparação dos testes de telemetria a mísseis MILAN – subcapítulo 5.3.

659

123




O esquemático utilizado baseou-se na simples ligação utilizando um cabo UTP de

categoria 5 com ficha RJ45 para comunicações via Gigabit Ethernet. O esquemático

utilizado foi o seguinte:

Computador com capacidade

Gigabit Ethernet

Câmara de

Alta Velocidade

Figura 90 – Aparato experimental utilizado para testes à camera de alta-velocidade

A descrição dos resultados obtidos vai ser efectuada no próximo subcapítulo, procurando

assim aprofundar o funcionamento da camera em rede.


Os testes efectuados podem ser separados em dois grupos distintos:

Análise em live;

Análise em stream.

Os testes para os dois casos anteriores foram efectuados para os seguintes parâmetros

de funcionamento:

Teste 1 Teste 2 Teste 3 Teste 4

Largura: 659 Largura: 659 Largura: 659 Largura: 659

Altura: 493 Altura: 493 Altura: 123 Altura: 123

Frame Rate: 196 Frame Rate: 30 Frame Rate: 759 Frame Rate: 100

Tabela 46 – Configurações utilizadas nos testes efectuados à camera de alta-velocidade

Na configuração de teste 1 foram gravados, aproximadamente, 41,7 s em modo live e,

aproximadamente, 21,8 s em modo stream, utilizando o software BitMeter e o ProStream

1.3.1 para aquisição de imagens da camera.



Em aproximadamente 41,7 s foram recebidos 9,45 kBytes em live, tendo sido recebidos

em aproximadamente 21,8 s, mas em stream, 6,82 kBytes. Assim, se o comportamento

da rede se mantiver constante em toda a transmissão, estaríamos a transmitir 1,8 kbps

(perto de 0,23 kBps) e 2,5 kbps (perto de 0,31 kBps) em live e stream, respectivamente –

ver apêndice H.

Método de recolha: Software “ProStream 1.3.1”


1 Camera de alta-velocidade

Protocolo de transferência: UDP


60 minutos (3600s)


Total de Pacotes recebidos: 209 Pacotes 12 135 Pacotes

Total de Bytes recebidos: (Camera) 8 704 Bytes

Total de Pacotes recebidos: (Camera) 136 Pacotes

Total de Bytes enviados: (Camera) 692 Bytes

Total de Pacotes enviados: (Camera) 2 Pacotes




64 169

128-255 7

256-511 33

Cliente ineficiente 3 Vezes

Importância:

Baixa







60 minutos (3600s)









Tamanho dos pacotes (Bytes) 64 114

256-511 4

Cliente ineficiente 2 Vezes Importância:

Baixa

Tabela 48 – Dados obtidos pelo software OmniPeek em stream na configuração de teste 1

Através da análise às duas tabelas anteriores, em que a principal diferença se centra na

opção de gravar por parte do software, podemos constatar alguns detalhes interessantes.

Apesar de estarmos a utilizar uma ligação com uma capacidade de 1 Gbps, apenas

utilizamos 0,006% da capacidade da rede, o que é sem dúvida uma surpresa, pois à



partida necessitaria de uma largura de banda pelo menos superior à camera IP utilizada

como e.g. durante os testes efectuados aos mísseis MILAN (descritos anteriormente).

A utilização máxima da capacidade de rede obtida pela camera IP foi de 4,5% utilizando

uma ligação máxima teórica de 100 Mbps, o que corresponde a uma utilização máxima

de 4,5 Mbps para a comunicação. Paralelamente, a camera de alta-velocidade utiliza

0,006% de 1Gbps, como referido anteriormente, o que corresponde a uma utilização

máxima de 0,06 Mbps na rede. Estes dados não deixam de ser surpreendentes, pois

possuímos uma camera com um melhor desempenho a nível de frame rate e com

desempenho de rede optimizado em relação à camera IP, o que não seria de esperar

numa análise preliminar.

Na configuração de teste 2 e utilizando o software BitMeter, em, aproximadamente, 45,5

s foram recebidos 10,09 kBytes em live e, por sua vez, em stream foram recebidos 8,74

kBytes em, aproximadamente, 35,4 s. Admitindo que o comportamento da rede se

mantém constante em toda a transmissão, estaríamos a transmitir 1,7 kbps (perto de 0,22

kBps) e 2 kbps (cerca de 0,25 kBps) em live e stream, respectivamente.

Os gráficos obtidos (ver apêndice H) mostram que existe um pico inicial, à semelhança

do que se verificou também para o teste 1. Tendo-se o mesmo verificado em todos os

testes efectuados, pode assim dizer-se que representa o pedido por parte do software

(cliente da ligação) à camera para começar a captar imagens.






60 minutos (3600s)










64 167

128-255 6

256-511 36


Baixa









60 minutos (3600s)










64 112

128-255 5

256-511 1


Baixa


A diferença entre o teste 1 e o teste 2 foi a modificação da frame rate, mantendo a

mesma resolução de vídeo. As taxas de transferência obtidas foram as seguintes:

Nº do teste: Opção de software: Taxa de transferência necessária (kbps)

Teste 1 Live 1,8

Stream 2,5

Teste 2 Live 1,7

Stream 2

Tabela 51 – Estimativa da taxa de transferência necessária nas condições de teste 1 e 2

A tabela anterior indica que a taxa de transferência obtida em live se mantém

aproximadamente a mesma nos dois testes, mas o mesmo não se verificou ao

seleccionar o modo stream, o que neste ponto de estudo é inconclusivo.

A taxa de transferência necessária não é directamente proporcional à frame rate, sendo

necessária a elaboração de novos testes. Estes devem também aferir se a dimensão do

vídeo tem influência directa no número de bytes a circular na rede, para responder a esta

questão elaboraram-se assim mais dois testes, denominados por teste 3 e 4.

Na configuração de teste 3 e recorrendo ao software BitMeter, em aproximadamente 21,6

s foram recebidos 6,3 kBytes em live, tendo sido recebidos em aproximadamente 41,6 s

em stream perto de 9,7 kBytes. Assim, pode-se admitir que o comportamento da rede se

mantém constante, estando em toda a transmissão a transmitir cerca de 2,33 kbps (0,29

kBps) e perto de 1,86 kbps (0,23 kBps) para a transmissão em live e stream,

respectivamente.








60 minutos (3600s)





Total de Bytes enviados: (Camera) 1 074 Bytes





64 128

65-127 1

128-255 6

256-511 14


Baixa







60 minutos (3600s)










64 118

65-127 1

128-255 6

256-511 1


Baixa


Neste teste foi aumentada a frame rate para a máxima permitida por hardware, não se

verificando um aumento da percentagem de utilização da rede. A largura de banda

necessária, dados adquiridos utilizando o software BitMeter, manteve-se na mesma

ordem de grandeza que as obtidas para os testes 1 e 2. Para teste 4 e final resolveu-se

manter a resolução do vídeo alterando a frame rate fazendo com que a mesma diminui-

se para os 100 fps.

Na configuração de teste 4 e recorrendo uma vez mais ao software BitMeter, em

aproximadamente 18,9 s foram recebidos 5,84 KBytes em live e, em stream, durante 18,2

s foram transmitidos 5,84 kBytes. Admitindo que o comportamento da rede se mantém



constante em toda a transmissão estaríamos a transmitir 2,47 kbps (0,31 kBps) e 2,56

kbps (0,32 kBps) para a transmissão em live e stream, respectivamente.






60 minutos (3600s)










256-511 11


Baixa







60 minutos (3600s)

Total de Bytes recebidos: 8 154 Bytes 772 484 Bytes









256-511 1


Baixa


Pela análise da rede dos quatro testes efectuados, quer em live ou stream, recorrendo ao

software OmniPeek, pode-se constar que a grande maioria dos pacotes que circula na

rede tem uma dimensão menor ou igual a 64 Bytes. O que numa ligação de 1 Gbps se

torna irrelevante, sendo os mesmos entregues sem qualquer tipo de erros na rede. Pode-

se também verificar que em todos os testes se observou que o cliente da ligação

(computador de armazenamento) se apresentava ineficiente, mas de acordo com a

análise avançada e apresentada pelo software OmniPeek, este problema apresenta-se

com uma importância baixa.



O fluxo de dados vídeo é enviado para a rede recorrendo ao protocolo UDP –

apresentado como um protocolo que não efectua controlo de erros –, que numa situação

de ligação directa, como o teste efectuado, não apresenta qualquer problema de

fiabilidade na entrega dos dados. Mas, no caso de uma rede de grandes dimensões,

pode apresentar-se como um problema de resolução difícil, pois se existir um nó que

entregue os dados corrompidos ao destino, não existe qualquer tipo de controlo a este

nível.

Através da análise da largura de banda consumida pela camera e pela utilização de uma

ligação Gigabit Ethernet, pode-se constatar que a necessidade da sua utilização não se

prende com o elevado volume de dados a enviar mas, sim, com a velocidade com que

esses dados necessitam de ser enviados. Pois ao capturar 796 imagens por segundo,

tendo em conta que uma webcam permite normalmente a captura de 30 imagens por

segundo, é necessário que a informação seja rapidamente entregue ao seu destino, visto

que este modelo de camera não possui qualquer buffer96 de envio (Prosilica, 2007;

Prosilica, 2008).

As larguras de banda obtidas para cada uma das configurações anteriores foram as

seguintes:

Nº do teste: Opção de software: Taxa de transferência necessária (kbps)

Teste 1 Live 1,8

Stream 2,5

Teste 2 Live 1,7

Stream 2

Teste 3 Live 2,3

Stream 1,86

Teste 4 Live 2,47

Stream 2,56

Tabela 56 – Estimativa dos dados que iriam circular na rede em 60 minutos no teste 1 e 2

Pela análise da tabela anterior, pode-se constatar que existe uma diferença entre a taxa

de transferência necessária para visualizar e gravar (stream) e apenas para visualizar

(live), à excepção dos dados adquiridos no teste 3. Neste teste é indicada uma menor

necessidade de taxa de transferência em stream, mesmo após a repetição do teste para

despistar erros de aquisição, sem no entanto se verificar nenhuma explicação aparente.

Pela análise dos picos obtidos através do software BitMeter, podemos constatar que em

média os pedidos para live causaram um pico na transmissão em média de 26,7 kBytes e

os de stream de 27,05 kBytes. Pelo que se pode concluir que aparentemente o tipo de

96

Pode ser descrito como um pedaço de memória temporária para leitura e escrita de dados.



pedido não tem influência directa significativa na dimensão da largura de banda

necessária para o efectuar.

5.5.5. CONCLUSÕES

Os testes efectuados e descritos no subcapítulo anterior demonstraram que a largura de

banda utilizada se situa sempre nos 0,006 %, para uma ligação de 1 Gbps. Ou seja, não

é directamente influenciada pela frame rate ou pelas dimensões do vídeo pretendido, o

que a ocorrer seria perfeitamente aceitável. Assim pode-se afirmar, à semelhança do que

foi descrito no subcapítulo anterior, que a utilização de uma ligação de 1 Gbps só se

justifica se tivermos em conta a velocidade da ligação necessária, pois ao utilizar uma

camera que captura até 796 imagens por segundo, com o protocolo UDP e sem qualquer

buffer de saída, é necessário garantir que os dados são escoados a uma velocidade

conveniente.

Por último, podemos concluir que em relação à webcam utilizada nos testes MILAN

(descritos anteriormente), a camera de alta-velocidade utilizada possui uma menor

utilização da rede, isto deve-se essencialmente por usar o protocolo UDP em vez de usar

o HTTP. Contudo, o funcionamento da webcam é baseado na leitura pelo seu programa

(IPView Pro) dos dados disponibilizados pelo seu firmware por HTTP, recorrendo

DirectX97. O que faz com que exista uma maior utilização de largura de banda, face à

utilização do protocolo UDP, pois este possui cabeçalhos menores e não efectua o

respectivo controlo de erros (Kozierok, 2005, p. 808).

A camera encontra-se optimizada e com um bom desempenho de rede, mesmo utilizando

a resolução de 659x123 e uma frame rate de 759 imagens por segundo. Se admitirmos

que um míssil do tipo Seasparrow tem uma velocidade de aproximadamente 4 256 km/h -

aproximadamente 1 182 m/s – (FAC, 1999), podemos verificar que entre dois frames

sucessivos o míssil terá andado cerca de 1,56 m/f. Tornando-se quase um golpe de sorte

conseguir captar com sucesso um míssil com esta velocidade, utilizando uma camera

com estas características apesar de o míssil em questão ter um comprimento de 3,7 m.

Mas contudo as probabilidades de o captar com uma camera destas é bastante superior,

pois utilizando a webcam cada frame corresponde a 39,4 m, como foi referido

anteriormente, sendo esta uma performance 25 vezes inferior à obtida utilizando uma

camera de alta-velocidade.

97

Possibilita a comunicação entre software e hardware, possibilitando assim que estes façam uso dos seus recursos.


6. CAPÍTULO VI

CONCLUSÕES E RECOMENDAÇÕES

6.1. INTRODUÇÃO

Nesta dissertação de mestrado foi proposto a elaboração de um sistema off-the-shelf,

capaz de efectuar a monitorização do afundamento de uma plataforma naval. Assim,

durante este trabalho, verificou-se o estado da arte no que concerne às redes de

sensores, procurando entender o seu funcionamento e condições necessárias ao seu

funcionamento. Posteriormente, analisou-se a problemática da conversão A/D e

respectivo teorema da amostragem, fazendo a interligação entre estes dois temas, e a

grande importância que os mesmos apresentam para a correcta retratação do fenómeno

a registar. Foram, também, abordados os protocolos de rede utilizados no sistema

desenvolvido - IEEE 802.3 (Ethernet) e IEEE 802.11g (wireless) -, de forma a entender o

seu modo de funcionamento e conseguir aferir o comportamento esperado.

Foram escolhidos e estudados os Dataloggers - Dataq DI-710-EL e Arduino Duemilinove

- especificando os seus princípios de funcionamento, individualizando sempre tanto

quanto possível para o cenário de estudo. Foi efectuada uma proposta de implementação

do sistema a bordo de um navio imaginado para o efeito, o que possibilitou abordar dois

dos maiores problemas esperados (mas infelizmente não os únicos) – o grande aumento

de temperatura nos diferentes compartimentos e a alimentação dos diferentes

equipamentos. Com vista a comprovar as hipóteses colocadas durante a descrição da

metodologia utilizada, foram efectuados variadíssimos testes aos equipamentos

específicos adquiridos, após apreendidos os fundamentos teóricos essenciais para o

fazer.



6.2. HIPÓTESES E OBJECTIVOS CUMPRIDOS

Os objectivos e hipóteses apresentadas no subcapítulo 1.2.2 são analisados neste

subcapítulo, pois foi com esse objectivo que se desenvolveu todo o trabalho

desenvolvido.

Além do descrito como conclusão ao longo do capítulo V – capítulo dedicado à descrição,

explicação e análise dos testes práticos efectuados considerados mais relevantes e de

toda a teoria abordada –, torna-se necessário efectuar uma reflexão final sobre os

resultados obtidos.

Os testes feitos ao conversor A/D demonstraram que a curva de conversão A/D do

Arduino Duemilinove analisado está longe de ser ideal, sendo esta afectada pelo factor

de prescaler utilizado. Caso se pretenda diminuir o erro existente ao mínimo possível este

deve ser determinado e compensado, analisando cada Arduino como se fosse único, pois

na verdade não existem dois Arduinos com a curva de conversão A/D cem por cento

semelhante. Este teste possibilitou constatar qual o melhor factor de prescaler a utilizar –

factor de elevada importância também – se situa no valor 4, obtendo um erro absoluto

máximo de 204 mV. Deve-se tentar compensar o erro obtido ao máximo possível e caso

não seja na fase de aquisição deve-se aplicar os métodos de tratamento matemático

considerados apropriados, não sendo este erro um factor limitativo na sua utilização.

Dos testes de telemetria no lançamento de mísseis MILAN, além da aprendizagem e

experiência que foi obtida através da participação efectiva, pois foi a primeira vez que foi

autorizada a participação de um grupo de investigação da EN neste tipo de exercício, foi

possível retirar através da sua preparação inúmeras conclusões. A conclusão mais

importante foi conseguir quantificar a taxa de transmissão necessária para os

equipamentos de aquisição e webcam. Onde a taxa de transferência de um Arduino

Duemilinove – 6 canais analógicos – é de 54 kBps (432 kbps), de um Datalogger Dataq

DI-710-EL – 16 canais analógicos – de 9 kBps (72 kbps) e de uma webcam é de 562,5

kBps (4 500 kbps).

O software utilizado para a aquisição de dados do Arduino foi o Matlab, do Datalogger

Dataq foi o Matlab e o seu software proprietário WinDaq e o software utilizado com a

webcam foi o IPView Pro. Verificou-se nos testes efectuados um melhor desempenho do

Dataq face ao Arduino, possibilitando a aquisição de mais entradas analógicas utilizando

uma largura de banda seis vezes inferior. Este factor por si só não é impeditivo da sua

utilização, pois teoricamente numa única ligação por Fast Ethernet – 100 Mbps –

Capitulo VI – Conclusões e recomendações


poderíamos adquirir dados de 231 Arduinos e enviar em simultâneo por IEEE 802.11g –

54 Mbps – dados de 125 Arduinos, admitindo os valores máximos teórico.

Ao utilizar o Arduino tornou-se necessário determinar a sua taxa de amostragem ao nível

do utilizador, nomeadamente, a obtida recorrendo ao software Matlab e fazendo variar os

protocolos de transmissão adoptados – Ethernet e série. Esta taxa de amostragem é a

obtida conjugando o software com o hardware, visto que a taxa de amostragem máxima

obtida pelo Datalogger Dataq ao nível do utilizador ser já conhecida e se situar nos 4 800

S/s para um canal analógico utilizando o software Matlab. Após a análise e comparação

dos dados obtidos nas diversas configurações utilizadas, foi possível constatar que a

utilização do protocolo Ethernet é o mais eficaz com taxas de amostragem de 240 S/s

para um canal analógico. Se a largura de banda necessária pelo Arduino não é impeditiva

para a sua utilização, no caso da taxa de amostragem o mesmo não se verifica, sendo

um claro indicador negativo do desempFunenho da conjugação Arduino + Matlab. O

Arduino apresenta ao nível de hardware taxas de amostragem bastante apreciáveis

perdendo bastante performance no tempo gasto no envio, leitura e armazenamento por

parte do software Matlab. Para contornar esta situação pode-se utilizar a função - fread()

que permite ler byte a byte os dados provenientes da comunicação série ou Ethernet, o

que faz com que o valor máximo possível seja de 255, existindo assim uma clara perda

de resolução. Esta técnica para ser eficaz teria de mapear um valor compreendido entre

0 e 1023 para um valor compreendido entre 0 e 255, mas em contrapartida verifica-se um

acréscimo na taxa de amostragem obtida em série – aproximadamente 430 S/s – e por

TCP/IP – aproximadamente 1 589 S/s. Estes valores foram determinados utilizando a

mesma metodologia descrita no subcapítulo 5.4, e apesar de existir um acréscimo na

taxa de amostragem é importante ter em conta que existe assim uma perda de resolução.

Para determinar se esta perda de resolução é aceitável teria de se recorrer a testes

práticos monitorizando casos reais, estudo que não chegou a ser efectuado.

O desempenho da camera de alta-velocidade adquirida foi também analisado,

determinando assim quais as suas características de funcionamento. Através dos testes

efectuados foi possível verificar que a mesma apenas utiliza 0,006% da capacidade

máxima do canal na transferência de dados. A necessidade de utilizar uma ligação

Gigabit Ethernet enquadra-se com a necessidade de transferir dados com uma grande

rapidez, visto ser utilizado um protocolo UDP - protocolo que não efectua qualquer

controlo de erros - numa camera que não apresenta qualquer buffer de envio. A

necessidade de uma grande taxa de transferência de dados impossibilita, assim o seu

envio por wireless utilizando o protocolo IEEE 802.11g pois este apenas permite



velocidades máximas teóricas de 54 Mbps. Assim deve ser privilegiado o uso de outro

sistema de aquisição à parte, sistema este que poderá também servir de redundância

para os restantes dados, devendo estes ser enviados por wireless, mas,

simultaneamente, armazenados neste sistema redundante aumentando assim as

probabilidades de sucesso na sua obtenção.

Através de todo o trabalho efectuado ficou latente a possibilidade de efectuar telemetria

utilizando equipamento off-the-shelf, pois a tecnologia escolhida e respectivo

equipamento permitem a correcta construção de um sistema adequado às condicionantes

com capacidade de recolha e envio dos dados.

A tecnologia escolhida na comunicação wireless, como foi largamente abordado ao longo

do texto, foi o protocolo IEEE 802.11g. Este possibilita comunicações teóricas até 54

Mbps e encontra-se largamente difundido, tendo sido a partir deste ponto que se efectuou

a escolha do protocolo IEEE 802.3, devido à sua conhecida interoperabilidade. A

possibilidade da sua utilização em longas distâncias ficou ainda comprovada após

efectuados testes de mar, como descritos por Capela, Pessanha, Vieira e Monsanto -

Apêndice A - onde se comprovou que a 7,49 km se podem transmitir dados de um

Arduino Duemilinove - 6 entradas analógicas que corresponde e.g. a dois acelerómetros

de 3 eixos – ou transmitir dados de sete Dataloggers Dataq DI-710-EL – 112 entradas

analógicas que corresponde a e.g. 37 acelerómetros de 3 eixos (Capela, Pessanha,

Vieira e Monsanto, 2008, p. 10). Os resultados obtidos no entanto não se mostraram

suficientes tornando essencial a construção de uma antena direccional com maior ganho,

estando todo o processo de elaboração e construção descrito no apêndice C.

Procurou-se na análise efectuada fazer uma comparação de performance entre o

Datalogger e o Arduino Duemilinove. Esta comparação começou em termos de hardware,

sendo que os três parâmetros considerados mais relevantes são número de entradas

analógicas, taxa de amostragem e custo O número de entradas analógicas de um

Arduino Duemilinove são 6 e de um Datalogger Dataq DI-710-EL são 16, sendo o custo

deste segundo claramente superior ao primeiro. Este factor pode ser facilmente

ultrapassado pela utilização de um Arduino Mega que utiliza um ATmega 1280 que

permite ter 16 canais analógicos a um preço relativamente baixo comparado com o

Datalogger Dataq adquirido. A comparação da taxa de amostragem entre equipamentos,

apesar de o Arduino possuir ao nível de hardware uma boa capacidade de amostragem

em relação ao Dataq, demonstrou que utilizando o software Matlab obtemos taxas de

amostragem bastante inferiores às do Datalogger Dataq.



6.3. RECOMENDAÇÕES E SUGESTÕES

Neste subcapítulo vão ser apresentadas algumas ideias para trabalho futuro nesta área,

sendo a maior parte delas baseadas na resolução de certos problemas que foram

verificados e que necessitam de resolução.

A melhor localização a bordo para colocação dos sensores deve ser estudada, entrando

em linha de conta com a melhor forma de aplicar redundâncias ao nível de alimentação,

de armazenamento de dados e qual a melhor topologia de rede a aplicar. Este estudo

deve ter como principal objectivo aumentar a sobrevivência do sistema em condições

adversas, bem como fazer com que não ocorram erros na transmissão dos respectivos

dados, pois se tal acontecer os pacotes são reenviados podendo ocorrer uma saturação

na rede. Este sistema deve ser adaptado à plataforma naval a afundar especificamente,

de modo a possibilitar a melhor performance possível.

Num futuro próximo dever-se-ia, em vez de adquirir no mercado Dataloggers, apostar na

construção de placas de aquisição low cost, constituídas à base de microcontroladores

que sejam altamente personalizadas à aplicação em concreto. Este processo não se

reveste de grande complexidade e com a especificidade conseguimos ter um aumento de

performance na recolha e envio de dados. Estas placas seriam altamente personalizadas

à aplicação a que se destinam, conseguindo assim baixar o seu custo. Ou seja, se só

precisamos de 3 pinos analógicos numa determinada localização não necessitamos de

ter e.g. 10, este é um claro desperdício de recursos que leva ao encarecimento do

produto final.

A redundância a utilizar em termos de armazenamento de dados, e mesmo para guardar

os dados provenientes da camera de alta velocidade, deve ser estudada sendo a ideia

inicial e que não chegou a ser implementada a utilização de uma bóia ligada fisicamente

a uma certa distância do navio alvo. Esta redundância deve ser idealizada e pensada

começando na bóia, o melhor tipo de cabos a utilizar e a forma como os dados vão ser

conduzidos até à bóia de armazenamento.

O sistema de telemetria poderá também incluir extensómetros pois estes possibilitariam

compreender melhor os efeitos estruturais na plataforma, possibilitando assim retratar as

deformações ocorridas durante o impacto. Caso se pretenda utilizar este tipo de sensores

deve-se estudar o melhor sítio para os implementar, procurando assim colocá-los com o

máximo rigor possível com vista a retirar o maior número de conclusões possíveis.



A utilização do software Matlab demonstrou um fraco desempenho ao nível da aquisição

de dados provenientes do Arduino, devendo estudar a possibilidade de utilização de outro

software. Ao continuar a utilizar o Matlab existe a possibilidade apostar na optimização da

biblioteca de envio do próprio Arduino (quer por série ou por Ethernet), fazendo com que

este envie os dados com maior celeridade.

A nova antena elaborada e construída deve ser alvo de testes de alcance – apêndice C –

procurando assim verificar quais as larguras de banda obtidas a 7,49 km fazendo a

comparação com o uso da antena omnidireccional adquirida. Esta deve ser utilizada,

devido à alta direccionalidade do lóbulo principal da antena elaborada, juntamente com

um sistema de guiamento automático, garantindo que a mesma esteja sempre a apontar

para a direcção de maior ganho.

6.4. LIMITAÇÕES E PROBLEMAS ENCONTRADOS

Sem dúvida uma das grandes limitações encontradas foi a falta de oportunidade de

experimentar o sistema numa situação real, tendo falhado esse que seria um dos

objectivos principais. Ao aplicar o sistema num caso real daria uma outra perspectiva das

necessidades e problemas existentes. Este objectivo não foi concluído pois não foi

lançado qualquer míssil no exercício SWORDFISH 2010 que decorreu entre 21 de Junho

e 30 de Julho de 2010, no entanto os testes realizados demonstraram-se bastante úteis

para aferir o desempenho esperado do sistema. Dos testes efectuados é importante

realçar o exercício de disparo de mísseis MILAN, pois trouxe uma ideia clara das muitas

das dificuldades que se podem encontrar e os muitos ensinamentos que daí foram

retirados, podendo assim retirar daí um certo know-how que em momentos futuros pode

ser determinante.

Deve-se realçar que apesar de tudo foi um passo bastante importante, pois foi a primeira

vez que a Escola Naval participa em testes, durante exercícios de fogo real. Espera-se

assim que estes sejam os primeiros de muitos e que a porta se encontre sempre aberta,

quer para mim, quer para as gerações vindouras, devendo continuar a investir na

participação de alunos da Escola Naval quer em actividades internas de Marinha como

externas (e.g. conferências, cursos, etc.).

Um dos problemas encontrados com a utilização de um Arduino Duemilinove com um

shield Ethernet foi a larga utilização de largura de banda para transmitir os dados

provenientes das suas entradas analógicas, face à largura de banda do Datalogger Dataq



DI-710-EL para transmitir dados das suas 16 entradas analógicas. O que sugere que a

biblioteca Ethernet não se encontra suficientemente optimizada, podendo ser este um

dos caminhos a seguir caso se pretenda utilizar o Arduino e aumentar assim o seu

rendimento na aquisição de dados.

Os sensores adquiridos pretendem estar na gama de valores teoricamente esperada mas

existe uma enorme lacuna de informação nesta temática. Pois apesar de esta não ser

uma prática recente e fazer-se recorrendo a mísseis telemétricos, não se possuem

actualmente dados obtido por esta via na Marinha Portuguesa.

A temperatura de operação do Datalogger e do Arduino, bem como dos cabos de

alimentação de dados é importante, devendo ser montada uma caixa de medição com

uma configuração resistente e que mantenha o seu interior numa temperatura de

operação aceitável. Deve-se também considerar que toda a cablagem utilizada deve ser

e.g. revestida com uma manga resistente a altas temperaturas, fazendo com que a sua

temperatura de operação aumente até pelo menos a temperatura de operação dos

Dataloggers e sensores utilizados.

O fenómeno a monitorizar desenvolve-se num curto espaço de tempo sendo necessária

uma alta taxa de amostragem, mas esta alta taxa de amostragem vai gerar um enorme

volume de dados. A transmissão de um enorme volume de dados é difícil pois existem

limitações óbvias na largura de banda disponível, sendo que uma limitação encontrada foi

não ter disponível material suficiente para simular o sistema final todo montado.


7. BIBLIOGRAFIA

Anastasi, G., E. Borgia, et al. (2004). Wi-Fi Ad Hoc Mode: A Measurement Study. Second IEEE International Conference on Pervasive Computing and Communications (PerCom'04).

Anastasi, G., M. Conti, et al. (2004). IEEE 802.11 Ad Hoc Networks: Protocols Performance and Open Issues, New York, NY, USA.

ANSI (1975). MC96.1 Temperature Measurement Thermocouples.

Arduino. (2006). Retrieved 06 February 2010, from http://www.Arduino.cc/en/Tutorial/DigitalPins.

Arduino. (2006, 14 July 2009). Retrieved 21 July 2009, 2009, from http://www.Arduino.cc.

Arroz, G., J. Monteiro, et al. (2007). Arquitectura de Computadores dos Sistemas Digitais aos Microprocessadores. Lisboa, IST Press.

Asadoorian, P. and L. Pesce (2007). Linksys WRT54G Ultimate Hacking. Burlington, USA, Syngress.

Aspinwall, J. (2003). Installing Troubleshooting and Repairing Wireless Networks. New York, USA, McGraw-Hill.

Aszkler, G. (2005). Acceleration, Shock and Vibration Sensors. Sensor Technology Handbook. J. S. Wilson. Oxford, UK, Newnes.

Atheros (2003). 802.11 Wireless LAN Performance.

ATmel (2009). 8-bit AVR Microcontroller with 8K Bytes In-System Programmable Flash ATmega48/V ATmega88/V and ATmega168/V. San Jose, USA, ATmel Corporation.

Bell, G., J. Gray, et al. (2006). Petascale Computational Systems. Computer, IEEE Computer Society. 39: 110-112.

Bharathidasan, A. and V. A. S. Ponduru (2003). Sensor Networks: An Overview. Potentials.

Burns, K. (2003). TCP/IP Analysis and Troubleshooting Tools. Indianapolis, Indiana, Wiley.

Capela, G. G., N. P. Santos, et al. (2008). Telemetria utilizando a norma IEEE802.11g. Jornadas do Mar. Alfeite, Portugal.

Carlson, A. B., P. B. Crilly, et al. (2002). Communication Systems: An Introduction to signals and noise in electrical. Avenue of the Americas,New York, McGraw-Hill.

Carney, W. (2002). IEEE 802.11g New Draft Standard Clarifies Future of Wireless LAN.

Çengel, Y. A. and M. A. Boles (2001). Termodinâmica. Lisboa, Portugal, McGraw-Hill.

Chakravarthy, V., A. S. Nunez, et al. (2005). TDCS, OFDM, and MC-CDMA: A Brief Tutorial. IEEE Radio Communications, IEEE.

http://www.arduino.cc/en/Tutorial/DigitalPins




Chau, K. H.-L., R. Goehner, et al. (1999). Pressure and Sound Measurement. The Measurement Instrumentation and Sensors Handbook. J. G. Webster, CRC Press.

Chen, Z. N. and M. Y. W. Chia (2006). Broadband Planar Antennas. West Sussex, England, John Wiley & Sons.

Chong, C.-Y. and S. P. Kumar (2003). Sensor Networks: Evolution, Opportunities and Challenges. Proceedings of the IEEE.

Chu, E. (2008). Discrete AND Continuous Fourier Transform. Boca Raton, USA, A CHAPMAN & HALL BOOK.

Corporation, A. (2006). AVR120: Characterization and Calibration of the ADC on an AVR. San Jose, USA.

Corporation, A. (2007). Improving ADC Results Through Oversampling and Post-Processing of Data. Mountain View, USA, Actel Corporation.

Corporation, B.-B. (1993). Programmable Gain Instrumentation Amplifier. Tucson Blvd, U.S.A.

Crovella, R. M. (1999). Sensor Networks and Communication. The Measurement, Instrumentation and Sensors Handbook. J. G. Webster, CRC Press.

Devices, A. (1999). Monolithic Thermocouple Amplifiers with Cold Junction Compensation AD594/AD595. Norwood, USA, Analog Devices.

Devices, A. (2004). Precision +/- 1.7g Single/Dual Axis Accelerometer. Norwood, USA.

Devices, A. (2007). Small and Thin +/- 18g Accelerometer. Norwood, USA.

Dieck, R. H. (1999). Measurement Accuracy. The Measurement Instrumentation and Sensors Handbook. J. G. Webster, CRC Press.

Edwards, J. and R. Bramante (2009). Networking Self-Teaching Guide. Indianapolis, Indiana, Wiley.

Eren, H. (1999). Acceleration, Vibration and Shock Measurement. The Measurement, Instrumentation and Sensors Handbook. J. G. Webster, CRC Press.

FAC. (1999). "RIM-7 Sea Sparrow Missile." Retrieved 16 January 2010, 2010, from http://www.fas.org/man/dod-101/sys/missile/rim-7.htm.

Flickenger, R. (2008). Very Long Distance Wi-Fi Network. NSDR'08, Seattle, Washington,USA.

GmbH, N.-N. (2009). "About DD-WRT." Retrieved 14 November 2009, 2009, from http://www.dd-wrt.com/site/content/about.

Gomez, T. (2001) "OFDM for Mobile Data Communications."

Goralski, W. (2009). The Illustrated Network. Burlington, USA, Morgan Kaufmann.

Gummadi, R., D. Wethwral, et al. (2007). Understanding and Mitigating the impact of RF interference on 802.11 Networks. SIGCOMM'07, Kyoto,Japan.

Hall, D. L. and J. Llinas (1998). An introduction to multi-sensor data fusion. ISCAS '98, Monterey, USA, IEEE.

Hamilton, S. J. A. and D. Hamilton (2007). Validating a Network simulation testbed for army UAVS. Proceedings of the 2007 Winter Simulation Conference.

Hansman, R. J. (1999). Characteristics of Instrumentation. The Measurement, Instrumentation and Sensors Handbook. J. G. Webster, CRC Press: 28.

http://www.fas.org/man/dod-101/sys/missile/rim-7.htm

http://www.dd-wrt.com/site/content/about

Bibliografia


Harman, G. (2005). Pressure Sensors. Sensor Technology Handbook. J. S. Wilson. Oxford, UK, Newnes.

Hayes, M. H. (1999). Schaum´s Outline of Theory and Problems of Digital Signal Processing. Washington DC, USA, McGraw-Hill.

Huang, Y. and K. Boyle (2008). Antennas From Theory to Practice. New Delhi, India, Wiley.

IEEE (2008). IEEE Standard for Information Technology. Part 3: Carrier sense multiple access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications. New York, USA, IEEE: 597.

Igoe, T. (2007). Making Things Talk. Sebastopol, USA, O´REILLY.

Instruments, D. (2007). DI-710 Series User´s Manual. I. DATAQ Instruments. Ohio, USA.

IRIG (2004). Telemetry Standard IRIG 106-04, Range Commanders Council, U.S. Army White Sands Missile Range.

Johansson, T. and Carr-Motycková (2005). Reducing Interference in Ad hoc Networks through Topology Control. DIALM-POMC'05. Cologne, Germany.

Jun, J., P. Peddabachagari, et al. (2003). Theoretical Maximum Throughput of IEEE 802.11g and its Applications. Second IEEE International Symposion on Network Computing and Applications.

Karris, S. T. (2008). Signals and Systems with MATLAB Computing and Simulink Modeling. USA, Orchard Publications.

Kester, W. (2006). ADC Input Noise: The Good, The Bad, and The Ugly. Is No Noise Good Noise? Analog Dialogue, Analog Instruments. 40.

Kozierok, C. M. (2005). The TCP/IP Guide. Vermont, USA.

Kurose, J. F. and K. W. Ross (2004). Computer Networking: A Top-Down Approach, Addison-Wesley Publishing Company.

Lewis, F. L. (2004). Wireless Sensor Networks. Smart Environments: Technology, Protocols and Applications. D. Cook and S. Das. New York, USA, John Wiley.

Liggins, M. E., D. L. Hall, et al. (2009). Handbook of Multisensor Data Fusion Theory and Practice. Boca Raton, USA, CRC Press.

Loewenstein, E. B. (1999). Analog-to-Digital Converters. The Measurement, Instrumentation and Sensors Handbook. J. G. Webster, CRC Press.

Lozano-Nieto, A. (1999). Telemetry. The Measurement, Instrumentation and Sensors Handbook. J. G. Webster, CRC Press.

Maillux, R. J. (2005). Phased Array Antenna Handbook. Norwood, USA, Artech House.

Mendes, C. and C. Peixeiro (2005). Limites Fundamentais em Antenas Impressas Pequenas. Jornadas de Engenharia de Electrónica e Telecomunicações e de Computadores 2005. Lisboa, Portugal.

Metcalfe, R. M. and D. R. Boggs (1976). Ethernet: Distributed Packet Switching for Local Computer Networks. Communications of the ACM 19: 395-404.

Moscibroda, T. and R. Wattenhofer (2005). Minimizing Interference in Ad Hoc and Sensor Networks. DIALM-POMC'05. Cologne, Germany.

Navega, S. (2002). Principios essenciais do Data Mining. Anais da Infoimagem, Cenadem, São Paulo, Brasil.



Nyquist, H. (1924). Certain Factors Affecting Telegraph Speed, American Institute of Electrical Engineer.

Olexa, R. (2005). Implementing 802.11, 802.16 and 802.20 Wireless Networks. New York, USA, Elsevier.

Parziale, L., D. T. Britt, et al. (2006). TCP/IP Tutorial and Technical Overview. Redbooks. IBM. Poughkeepsie, NY, IBM.

Pollock, D. D. (1993). Thermocouples Theory and Properties. USA, CRC Press.

Press, W. H., S. A. Teukolsky, et al. (1992). Numerical Recipes in C. Melborne, Australia, Cambridge University Press.

Prosilica (2007). GC640 User Manual Burnaby, Canada, Prosilica.

Prosilica (2008). GC640 / 640C. Technical Documentation. Burnaby, Canada.

Sanders, C. (2007). Pratical Packet Analysis Using Wireshark to Solve Real-World Network Problems. San Francisco, USA, NO STARCH PRESS.

Santos, A. (2007). "Servomotores." Retrieved 31 July 2009, 2009, from http://www.esen.pt/on/file.php/45/Cerqueira/Servo_Motor.pdf.

Santos, N. P. (2008) Introdução ao Arduino. Revista PROGRAMAR 39-44

Santos, N. P. (2009) "Arduino e a Aquisição de dados." Revista PROGRAMAR, 24-26.

Sarmento, M. (2008). Guia Prático sobre a Metodologia Científica para Elaboração, Escrita e Apresentação de Teses de Doutoramento, Dissertações de Mestrado e Trabalhos de Investigação Aplicada. Lisboa, Portugal, Universidade Lusíada de Lisboa.

Semiconductor, F. (2005). +/- 1.5g - 6g Three Axis Low-g Micromachined Accelerometer MMA7260Q. Denver, Colorado.

Semiconductor, F. (2009). MPX5999D Integrated Sillicon Pressure Sensor On-Chip Signal Conditioned, Temperature Compensated and Calibrated. Muenchen, Germany: 7.

Semiconductor, N. (1980). An introduction to the Sampling Theorem. Application Note.

Semicondutor, F. (2009). MPX5999D Integrated Sillicon Pressure Sensor On-Chip Signal Conditioned, Temperature Compensated and Calibrated. Muenchen, Germany: 7.

SENA (2002) "Introduction to Ethernet Technical Tutorial."

Seybold, J. S. (2005). Introduction to RF Propagation. New Jersey, USA, John Wiley & Sons.

Shannon, C. E. (1948). "A Mathematical Theory of Communication." The Bell System Technical Journal 27: 379-423.

Shiffman, D. (2008). Learning Processing - A beginner´s Guide to Programming Images, Animation, and Interaction. Burlington, USA, Morgan Kaufmann.

Smith, S. E. (2010). "What is garbage in garbage out?". Retrieved 12 of June, 2010, from http://www.wisegeek.com/what-is-garbage-in-garbage-out.htm.

Society, I. C. (2008). Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Spercifications. New York, USA.

Sousa, D. J. d. S. and N. C. Lavinia (2006). Conectando o PIC 16F877A Recursos Avançados. São Paulo, Brazil.

http://www.esen.pt/on/file.php/45/Cerqueira/Servo_Motor.pdf

http://www.wisegeek.com/what-is-garbage-in-garbage-out.htm

Bibliografia


Vasegui, S. V. (2006). Advanced Signal Processing and Noise Reduction. Wiltshire, England, Wiley.

Vassis, D., G. Kormentzas, et al. (2005). The IEEE 802.11g Standard for High Data Rate WLANs. IEEE Network, IEEE Communications Society. 19: 21-26.

Vitturi, S. and D. Miorandi (2005). Hybrid Ethernet/IEEE 802.11 Networks for Real-Time Industrial Communications. Emerging Technologies and Factory Automation, Catania.

Walke, B. H., S. Mangolg, et al. (2006). IEEE 802 Wireless Systems. West Sussex, England, John Wiley & Sons.

Week, B. (1999). 21 ideas for the 21st century. Business Week.

Wilson, J. (2005). Sensor Technology Handbook. Oxford, UK, Newnes.

WIZnet (2006). W5100 Datasheet. Gyeonggi-Do, Korea.

Wu, D., Y. T. Hou, et al. (2001). Streaming Video over the Internet: Approaches and Directions. IEEE Transactions on Circuits and Systems for Video Technology, IEEE.

Xu, S. and T. Saadawi (2001). Does the IEEE802.11 MAC Protocol Work Well in Multihop Wireless Ad Hox Networks? IEEE Communications Magazine, IEEE Communicatios Society.

Zimmermann, H. (1980). OSI Reference Model - The ISO Model of Architecture for Open Systems Interconnection. IEEE TRANSACTIONS ON COMMUNICATIONS. Padova, Italy, IEEE Communications Society. 28: 425 - 432.

Zyren, J. (2001). IEEE 802.11g Explained, Wireless Networking, Intersil Corporation.