Joel Nuno Silva Alves BIOSWIM - Implementação de rede de ...

BIOSWIM - Implementação de rede
de sensores (BAN) em fato de natação
Joel Nuno Silva Alves
UMinho | 2010
Universidade do Minho
Escola de Engenharia
Joel Nuno Silva Alves
BIOSWIM - Implementação de rede
de sensores (BAN) em fato de natação
Outubro de 2010

Universidade do Minho
Escola de Engenharia
Joel Nuno Silva Alves
BIOSWIM - Implementação de rede
de sensores (BAN) em fato de natação
Dissertação de Mestrado
Ciclo de Estudos Integrados Conducentes ao
Grau de Mestre em Engenharia Electrónica Industrial e Computadores
Trabalho efectuado sob a orientação de
Professor Doutor André Paulo de Almeida Whiteman
Catarino
Co-Orientador:
Professor Doutor João Monteiro
Outubro de 2010

Albert Einstein
"A mente que se abre a uma nova ideia jamais volta ao seu tamanho original."

Agradecimentos
Durante o desenvolvimento deste projecto, várias foram as pessoas que ajudaram e
colaboraram na realização desta dissertação. A todos gostaria de expressar os mais sinceros
agradecimentos, no entanto gostaria de destacar algumas pessoas.
Em primeiro lugar agradeço ao meu orientador, Professor Doutor André Paulo de Almeida
Whiteman Catarino, toda a colaboração, dedicação e competência demonstrada ao longo deste
projecto.
Em segundo lugar agradeço ao Professor Doutor Hélder Manuel Teixeira Carvalho, a
dedicação singular a este projecto, sendo todas as sugestões, esclarecimentos e ensinamentos
que me dedicou bastante úteis para o desenvolvimento desta dissertação.
Agradeço à Universidade do Minho em geral, todas as condições que me foram
proporcionadas ao longo do curso, em especial ao departamento de Electrónica e ao
departamento de Têxtil, o apoio e as facilidades que concederam para a realização desta
dissertação.
Agradeço também aos meus colegas de curso que me acompanharam ao longo destes
últimos anos, pela amizade, companheirismo e cumplicidade que demonstraram.
Agradeço ainda à minha família e amigos, todo o apoio não só nos últimos anos, como ao
longo de toda a minha vida.
Por último, mas não menos importante gostaria de agradecer a atenção, força e
compreensão dedicada ao longo deste projecto, especialmente quando tudo parecia correr mal, à
minha companheira Cláudia Carneiro.
III

Resumo
Esta dissertação descreve o trabalho de desenvolvimento de uma rede de sensores sem
fios, a utilizar por um sistema de monitorização de sinais biomédicos, a ser integrado num fato
de natação. O sistema deverá medir vários parâmetros de desempenho, biomecânicos,
fisiológicos e químicos, para posteriormente ser feita uma análise global do comportamento do
indivíduo testado, bem como sinalizar comportamentos anormais.
Para a comunicação de dados foi implementada uma rede de área corporal (Body Area
Network - BAN). O sistema é composto por uma rede sem fios em duas versões, uma baseada
na especificação 802.15.4, e outra no protocolo de mais alto nível Zigbee, desenvolvidos com
base no microcontrolador JN5148, a ZBPro stack da Jennic e o kernell RT JenOs da Jennic. O
sistema adquire, processa e envia os sinais dos sensores que serão ligados à rede
posteriormente. É composto também por uma aplicação gráfica em computador que representa
os sinais graficamente, faz o controlo dos nós sensores em termos de taxa de amostragem e faz
o registo e apresentação dos erros que possam surgir na comunicação.
Para efeitos de demonstração, foi utilizado um sensor específico de temperatura
timpânica, do tipo termistor, para medir a temperatura timpânica do atleta ao longo da
actividade desportiva, tendo sido desenvolvido o respectivo circuito condicionador para o sensor
de temperatura, ligado ao dispositivo nó sensor na rede sem fios.
O sistema final foi testado com os dispositivos em diferentes posições, bem como com
vários nós sensores a comunicar em simultâneo. Para cada uma das posições relativas entre
dispositivos foi medido a qualidade do sinal e registado a frequência de erros de comunicação.
A implementação com o protocolo Zigbee mostrou-se capaz de adquirir e enviar sinais
dos sensores a uma frequência de 7 kAmostras/s (correspondendo a uma taxa final líquida de
84 kbps) com uma percentagem de perdas de tramas abaixo dos 4%. Este sistema demonstrou
também que suporta a comunicação simultânea de pelo menos três nós sensores, a 3000
amostras por segundo (36 kbps), com uma percentagem de perdas inferior a 4%.
Palavras-chave:
Rede de área corporal, BAN, Zigbee, 802.15.4, E-têxteis, Temperatura Timpânica.
IV

Abstract
This dissertation describes the development of a wireless sensor network used by a
biomedical signal monitoring system to be integrated in a swimsuit. The system will measure
various biochemical, physiological and chemical performance parameters, to allow a global
analysis of the behavior of the subject, as well as to signal abnormal behavior.
Data communication consists of a body area network (BAN) materialized as a wireless
network in two versions, one based on the 802.15.4 specification and another on the higher-level
Zigbee protocol, developed using the Jennic JN5148 microcontroller, Jennics ZBPro stack and
JenOs RT kernell. The system acquires, processes and sends signals from the sensors that will
be connected. It is also composed of a graphical application on a computer that graphically
represents the signals, controls the sensor nodes in terms of sampling rate and makes the
recording and presentation of the errors that arise in communication.
For demonstration purposes, a specific sensor for tympanic temperature measurement,
of the thermistor type, was used, to measure this variable during sports activity. A specific
conditioning circuit was developed and connected to a device node in the wireless sensor
network.
The final system was tested with the devices in different positions, as well as several
sensor nodes communicating simultaneously. For each of the relative positions of the devices the
signal quality and frequency of communication errors were recorded.
The version implemented on basis of the Zigbee protocol was able to acquire and send
sensor signals at a frequency of 7 kSamples/s (corresponding to a final net rate of 84 kbps) with
a percentage of lost frames below 4%. It was also shown that the system supports simultaneous
communication of three sensor nodes at 3 kS/s (36 kbps) each, with a percentage of losses of
less than 4%.
Keywords:
Body Area Networks, BAN, Zigbee, 802.15.4, Electronic Textiles, Tympanic Temperature.
V

Conteúdo
1 Introdução e Objectivos .................................................................................... 1
1.1 O projecto BIOSWIM ....................................................................................................... 2
1.2 Objectivos do trabalho .................................................................................................... 4
1.3 Cronologia ...................................................................................................................... 5
1.4 Organização da Tese ...................................................................................................... 6
2 Estado da Arte e Fundamentos Teóricos .......................................................... 8
2.1 Monitorização de pessoas com e-têxteis .......................................................................... 8
2.2 Sinais biométricos ........................................................................................................ 12
2.2.1 Sensores de temperatura timpânica .................................................................. 12
2.3 Redes de área corporais (BAN) ..................................................................................... 13
2.4 Protocolos de comunicação sem fios de curto alcance .................................................. 17
2.4.1 802.15.4 ....................................................................................................... 19
2.4.2 Zigbee ........................................................................................................... 21
2.4.3 Bluetooth ....................................................................................................... 27
3 Desenvolvimento .............................................................................................. 34
3.1 Especificação de requisitos ........................................................................................... 34
3.2 Estruturação geral do sistema e hardware ..................................................................... 35
3.2.1 Estrutura geral ............................................................................................... 35
3.2.2 Hardware de comunicação .............................................................................. 38
3.3 Implementação com protocolo Zigbee ........................................................................... 41
3.3.1 Arquitectura da rede de sensores sem fios ......................................................... 42
3.3.2 Estrutura do Firmware ..................................................................................... 45
3.3.3 Aquisição de sinal e preparação para a transmissão............................................ 61
3.3.4 Processamento no Coordenador e envio para a UART .......................................... 63
3.4 Implementação com protocolo 802.15.4 ....................................................................... 67
3.4.1 Arquitectura da rede de sensores sem fios ......................................................... 68
3.4.2 Estrutura do firmware...................................................................................... 68
3.4.3 Aquisição de sinal e preparação para a transmissão............................................ 73
3.4.4 Processamento no Coordenador e envio para a UART ......................................... 74
VI

3.5 Estrutura do software em computador........................................................................... 74
3.5.1 Aplicação Gráfica ............................................................................................ 75
3.5.2 Recepção de dados ......................................................................................... 76
3.5.3 Extracção de tramas ....................................................................................... 77
3.5.4 Contagem de erros ......................................................................................... 78
3.5.5 Visualização de dados ..................................................................................... 79
3.5.6 Envio de comandos......................................................................................... 80
3.6 Hardware analógico ...................................................................................................... 81
3.6.1 Sensor de Temperatura Timpânica ................................................................... 81
3.6.2 Circuito electrónico ......................................................................................... 82
4 Resultados ........................................................................................................ 88
4.1 Protótipos implementados ............................................................................................ 88
4.2 Testes .......................................................................................................................... 89
4.2.1 Testes do sistema ........................................................................................... 89
4.3 Plano experimental ....................................................................................................... 91
4.4 Resultados e Análise ..................................................................................................... 93
4.5 Resultados Gerais ....................................................................................................... 102
4.6 Problemas e Soluções ................................................................................................ 102
5 Conclusões ...................................................................................................... 104
5.1 Trabalho Futuro .......................................................................................................... 106
Anexos:
Anexo 1 ........................................................................................................................ 1
Anexo 2 ........................................................................................................................ 2
Anexo 3 ........................................................................................................................ 4
Anexo 4 ........................................................................................................................ 5
Anexo 5 ........................................................................................................................ 6
VII

Lista de Figuras
FIGURA 1: CRONOGRAMA DO PROJECTO. .............................................................................................................. 5
FIGURA 2: WEARABLE MOTHERBOARD - GEORGIA TECH INSTITUTE. ............................................................................... 9
FIGURA 3: ROUPA INTERACTIVA [3]. .................................................................................................................. 10
FIGURA 4: PELE PARA ROBÔS FEITA DE SENSORES ORGÂNICOS [5] [6]. ........................................................................ 11
FIGURA 5: CORTE VERTICO-TRANSVERSAL DO OUVIDO DIREITO [11]. ............................................................................ 13
FIGURA 6: SENSORES DE TEMPERATURA TIMPÂNICA. .............................................................................................. 13
FIGURA 7: VELOCIDADE DE TRANSMISSÃO VS CONSUMO DE ENERGIA [14] DATA: 23/04/2008. ......................................... 14
FIGURA 8: PROJECTO HUMAN++ DESENVOLVIDO NA BÉLGICA [14]. ............................................................................ 16
FIGURA 9: ÁUDIO SEM FIOS. ........................................................................................................................... 16
FIGURA 10: SAPATILHAS GERADORAS DE ENERGIA. PROJECTO SHOES GENERATORS ......................................................... 17
FIGURA 11: POSICIONAMENTO DAS TECNOLOGIAS DE COMUNICAÇÃO SEM FIOS, ADAPTADO DE [18]. ..................................... 18
FIGURA 12: ARQUITECTURA PROTOCOLAR DO PROTOCOLO 802.15.4, ADAPTADO DE [22]. ................................................ 20
FIGURA 13: TOPOLOGIAS DE REDE. A: MALHA, B: ESTRELA, C: ÁRVORE, ADAPTADO DE [43]. ..................................... 22
FIGURA 14: PILHA PROTOCOLAR ZIGBEE, ADAPTADO DE [25]. ................................................................................... 23
FIGURA 15: ESTRUTURA SUPERFRAME [24]. ....................................................................................................... 24
FIGURA 16: MODOS DE TRANSMISSÃO DE DADOS. ................................................................................................. 25
FIGURA 17: FORMATO DA MENSAGEM ZIGBEE [26]. ......................................................................................... 26
FIGURA 18: (A): PICONETS PONTO A PONTO, (B): PONTO A MULTIPONTO, ADAPTADO DE [30]. ............................................. 29
FIGURA 19: DOIS EXEMPLOS DE SCATTERNET, ADAPTADO DE [30]. ............................................................................ 30
FIGURA 20: ESTADOS OPERACIONAIS PARA DISPOSITIVOS BLUETOOTH. ........................................................................ 32
FIGURA 21: SISTEMA AQUISIÇÃO DE SINAL/REDE/APLICAÇÃO GRÁFICA. ....................................................................... 35
FIGURA 22: ESTRUTURA GERAL DO SISTEMA CONCEBIDO. ........................................................................................ 36
FIGURA 23: LOCALIZAÇÃO DO TRABALHO NO PROJECTO BIOSWIM. ............................................................................ 36
FIGURA 24: KIT DE DESENVOLVIMENTO DE REDES DE COMUNICAÇÃO SEM FIOS DA JENNIC. ................................................. 38
FIGURA 25: ARQUITECTURA DO MICROCONTROLADOR JN5148 DA JENNIC. ................................................................... 39
FIGURA 26: MÓDULOS DE DESENVOLVIMENTO DA JENNIC. ....................................................................................... 39
FIGURA 27: DEBUG POR SOFTWARE ATRAVÉS DO HYPERTERMINAL DO WINDOWS.............................................................. 40
FIGURA 28: ARQUITECTURA DO SOFTWARE ZIGBEE PRO DA JENNIC, ADAPTADO DE [36].................................................... 42
FIGURA 29: DINÂMICA DO SOFTWARE ZIGBEE PRO DA JENNIC. ................................................................................. 42
FIGURA 30: TOPOLOGIA DE REDE EM ESTRELA. ..................................................................................................... 43
FIGURA 31: FUNCIONAMENTO GERAL DA APLICAÇÃO IMPLEMENTADA COM O PROTOCOLO ZIGBEE. ......................................... 46
FIGURA 32: TRAMA DE DADOS E TRAMA DE COMANDOS. .......................................................................................... 47
FIGURA 33: ESTADOS DO NÓ CONTROLADOR E NÓ SENSOR NA GESTÃO DA REDE ZIGBEE. ................................................... 48
VIII

FIGURA 34: ARQUITECTURA DA APLICAÇÃO DO COORDENADOR. ................................................................................. 49
FIGURA 35: CONFIGURAÇÃO PORMENORIZADA DO RTOS DO SISTEMA OPERATIVO JENOS DO COORDENADOR. ................ 51
FIGURA 36: FLUXOGRAMA DO PROGRAMA PRINCIPAL DO FIRMWARE DO COORDENADOR (FORMAÇÃO DA REDE ZIGBEE). ................. 52
FIGURA 37: FLUXOGRAMAS DO PROGRAMA PRINCIPAL DO FIRMWARE DO COORDENADOR (RECEPÇÃO DE DADOS). ....................... 54
FIGURA 38: ARQUITECTURA DA APLICAÇÃO DO DISPOSITIVO FINAL. ............................................................................. 56
FIGURA 39: CONFIGURAÇÃO PORMENORIZADA DO RTOS DO SISTEMA OPERATIVO JENOS DO DISPOSITIVO FINAL. ............. 58
FIGURA 40: FLUXOGRAMA DO PROGRAMA PRINCIPAL DO FIRMWARE DO DISPOSITIVO FINAL (PROCURA DE REDE ZIGBEE). ............... 59
FIGURA 41: FLUXOGRAMAS DO PROGRAMA PRINCIPAL DO FIRMWARE DO DISPOSITIVO FINAL (AQUISIÇÃO E ENVIO DE DADOS). ......... 60
FIGURA 42: CONSTRUÇÃO DAS TRAMAS NO NÓ SENSOR (PROTOCOLO ZIGBEE)................................................................ 62
FIGURA 43: TRAMA DE DADOS COMPLETA (ZIGBEE)................................................................................................ 62
FIGURA 44: TRAMA DE COMANDOS COMPLETA (ZIGBEE). ......................................................................................... 63
FIGURA 45: ENCAIXE DO ARRAY DE AMOSTRAS DE 12 BITS NUM ARRAY DE 8 BITS. ........................................................... 64
FIGURA 46: IMPLEMENTAÇÃO DO BIT STUFFING NUMA SEQUÊNCIA DE BITS A ENVIAR. ....................................................... 66
FIGURA 47: ALGORITMO DO MECANISMO DE CONTAGEM DE TRAMAS PERDIDAS E REPETIDAS. ............................................... 67
FIGURA 48: ARQUITECTURA DO SOFTWARE 802.15.4 STACK DA JENNIC. ..................................................................... 68
FIGURA 49: FLUXOGRAMA DO PROGRAMA PRINCIPAL DO FIRMWARE DO COORDENADOR (802.15.4). ..................................... 70
FIGURA 50: MÁQUINA DE ESTADOS DO DISPOSITIVO FINAL. ....................................................................................... 71
FIGURA 51: FLUXOGRAMA DO PROGRAMA PRINCIPAL DO FIRMWARE DO DISPOSITIVO FINAL (802.15.4). ................................. 72
FIGURA 52: CONSTRUÇÃO DAS TRAMAS NO NÓ SENSOR (PROTOCOLO 802.15.4). .......................................................... 73
FIGURA 53: TRAMA DE DADOS COMPLETA (802.15.4). .......................................................................................... 74
FIGURA 54: APLICAÇÃO GRÁFICA. .................................................................................................................... 75
FIGURA 55: DIAGRAMA DE BLOCOS DA APLICAÇÃO GRÁFICA. ..................................................................................... 76
FIGURA 56: RECEPÇÃO DE DADOS DA APLICAÇÃO GRÁFICA (EXTRACTO DO BLOCK DIAGRAM DO LABVIEW). ............................... 77
FIGURA 57: DIAGRAMA DE BLOCOS DA SUBVI EXTRACT FRAMES (EXTRACÇÃO DE TRAMAS). ................................................ 78
FIGURA 58: ATRIBUIÇÃO DO CLUSTER DE ERROS (NODE LIST) AO INDICADOR. ................................................................ 79
FIGURA 59: VISUALIZAÇÃO DE DADOS. ............................................................................................................... 80
FIGURA 60: ENVIO DE COMANDOS (EXTRACTO DO BLOCK DIAGRAM DO LABVIEW). ........................................................... 81
FIGURA 61: SENSOR DE TEMPERATURA TIMPÂNICA. ............................................................................................... 82
FIGURA 62: CURVA CARACTERÍSTICA DE UM TERMISTOR NTC, ADAPTADO DE [37]. .......................................................... 83
FIGURA 63: AMPLIFICADOR INVERSOR COM SENSOR NA MALHA DE REALIMENTAÇÃO. ......................................................... 83
FIGURA 64: CIRCUITO CONDICIONADOR PARA SENSOR DE TEMPERATURA TIMPÂNICA. ........................................................ 84
FIGURA 65: TENSÃO DE SAÍDA (VOUT) EM FUNÇÃO DA TEMPERATURA. ............................................................................ 86
FIGURA 66: CIRCUITO CONDICIONADOR DE SENSOR DE TEMPERATURA TIMPÂNICA. ........................................................... 88
FIGURA 67: PROTÓTIPOS IMPLEMENTADOS. ........................................................................................................ 89
FIGURA 68: TESTE DA AQUISIÇÃO E TRANSMISSÃO DE DADOS. ................................................................................... 90
FIGURA 69: PLANO EXPERIMENTAL PARA TESTAR O PROTÓTIPO IMPLEMENTADO............................................................... 91
FIGURA 70: PERDAS DE TRAMAS NA CONFIGURAÇÃO DISPOSITIVOS JUNTOS. ................................................................... 94
IX

FIGURA 71: PERDAS DE TRAMAS NA CONFIGURAÇÃO DISTÂNCIA DE 10 METROS............................................................... 95
FIGURA 72: PERDAS DE TRAMAS NA CONFIGURAÇÃO DISTÂNCIA DE 10 METROS SEPARADOS POR UMA PAREDE. ......................... 95
FIGURA 73: PERDAS DE TRAMAS NA CONFIGURAÇÃO FRENTE E ATRÁS DO CORPO. ............................................................ 96
FIGURA 74: PERDAS DE TRAMAS NA CONFIGURAÇÃO FRENTE E ATRÁS DOS PÉS. .............................................................. 96
FIGURA 75: PERDAS DE TRAMAS COM 2 NÓS EM COMUNICAÇÃO. ............................................................................... 97
FIGURA 76: PERDAS DE TRAMAS COM 3 NÓS EM COMUNICAÇÃO. ............................................................................... 98
FIGURA 77: PERDAS DE TRAMAS COM 2 NÓS EM COMUNICAÇÃO COM CONECTOR SMA. .................................................... 98
FIGURA 78: QUALIDADE DO SINAL (LQI)............................................................................................................. 99
FIGURA 79: PERDAS DE TRAMAS EM TODAS AS CONFIGURAÇÕES NO MODO LOW POWER. ................................................. 100
FIGURA 80: PERDAS DE TRAMAS EM TODAS AS CONFIGURAÇÕES NO MODO HIGH POWER. ................................................ 100
FIGURA 81: PERDAS DE TRAMAS COM VÁRIOS NÓS SENSORES NA REDE. ..................................................................... 101
Anexos:
FIGURA 82: MODELO PROTOCOLAR DA PILHA ZIGBEE................................................................................................ 1
FIGURA 83: PILHA DE PROTOCOLOS BLUETOOTH E PRINCIPAIS FUNÇÕES DE CADA CAMADA, ADAPTADO DE [29]. ................ 2
FIGURA 84: GRUPOS DA PILHA DE PROTOCOLOS BLUETOOTH. ..................................................................................... 3
FIGURA 85: CONFIGURAÇÃO PORMENORIZADA DO ZPS (PARÂMETROS DE REDE). ............................................................... 4
FIGURA 86: BLOCK DIAGRAM DA SUBVI EXTRACT FRAME. .......................................................................................... 5
FIGURA 87: PROTÓTIPO IMPLEMENTADO COMPLETO. ................................................................................................ 6
X

Lista de Tabelas
TABELA 1: PARÂMETROS A AVALIAR NO PROJECTO BIOSWIM...................................................................................... 4
TABELA 2: COMPARAÇÃO DOS PROTOCOLOS ZIGBEE E BLUETOOTH, ADAPTADO DE [20]. ................................................... 19
TABELA 3: BANDAS DE RADIOFREQUÊNCIA DO PROTOCOLO 802.15.4 E PROTOCOLO ZIGBEE, ADAPTADO DE [22]. ..................... 21
TABELA 4: TIPO DE DISPOSITIVOS LÓGICOS NUMA REDE ZIGBEE.................................................................................. 22
TABELA 5: NÍVEIS DE POTÊNCIA DE TRANSMISSÃO. ................................................................................................ 29
TABELA 6: TAXAS DE TRANSMISSÃO PARA OS PACOTES USADOS EM CONEXÕES ASSÍNCRONAS (ACL), ADAPTADO DE [32].............. 31
TABELA 7: CARACTERÍSTICAS PRINCIPAIS DO MICROCONTROLADOR JN5148 DA JENNIC. ................................................... 41
TABELA 8: CONFIGURAÇÃO DO RTOS DO SISTEMA OPERATIVO JENOS ......................................................................... 45
TABELA 9: DESCRIÇÃO DAS FUNÇÕES DO FIRMWARE DO NÓ CONTROLADOR NO PROTOCOLO ZIGBEE ...................................... 54
TABELA 10: DESCRIÇÃO DAS FUNÇÕES DO FIRMWARE DO NÓ SENSOR NO PROTOCOLO ZIGBEE. ........................................... 60
TABELA 11: COMANDOS E SUAS FUNÇÕES. ......................................................................................................... 63
TABELA 12: DESCRIÇÃO DAS FUNÇÕES DO FIRMWARE DO NÓ CONTROLADOR NO PROTOCOLO 802.15.4. ............................... 70
TABELA 13: DESCRIÇÃO DAS FUNÇÕES DO FIRMWARE DO NÓ SENSOR NO PROTOCOLO 802.15.4. ....................................... 73
TABELA 14: VALORES DA RESISTÊNCIA DO SENSOR NTC SENSÍVEL À TEMPERATURA.......................................................... 82
TABELA 15: VALORES DA SAÍDA (VOUT) DO CIRCUITO CONDICIONADOR EM FUNÇÃO DA TEMPERATURA. ...................................... 86
TABELA 16: POSIÇÃO RELATIVA DOS DISPOSITIVOS. ................................................................................................ 92
XI

Lista de Funções
FUNÇÃO 1 : NÚMERO DE AMOSTRAS ZIGBEE ........................................................................................................ 62
FUNÇÃO 2: DIVISOR PARA A FREQUÊNCIA DE AMOSTRAGEM DO ADC ............................................................................ 63
FUNÇÃO 3: NÚMERO DE AMOSTRAS 802.15.4 .................................................................................................... 64
FUNÇÃO 4: NÚMERO DE POSIÇÕES DO ARRAY PAYLOAD NO PROTOCOLO ZIGBEE ............................................................. 73
FUNÇÃO 5: POTÊNCIA DISSIPADA PELO TERMISTOR ................................................................................................ 85
FUNÇÃO 6: CORRENTE ELÉCTRICA QUE ATRAVESSA O TERMISTOR ............................................................................... 85
FUNÇÃO 7: TENSÃO NO PONTO INTERMEDIÁRIO V3 DO CIRCUITO CONDICIONADOR ........................................................... 85
FUNÇÃO 8: GANHO 1 DO CIRCUITO CONDICIONADOR .............................................................................................. 85
FUNÇÃO 9: GANHO 2 DO CIRCUITO CONDICIONADOR .............................................................................................. 85
FUNÇÃO 10: TENSÃO DE SAÍDA DO CIRCUITO CONDICIONADOR ................................................................................. 85
FUNÇÃO 11: SENSIBILIDADE DO CIRCUITO CONDICIONADOR .............................................................................................. 87
FUNÇÃO 12: RESOLUÇÃO GERAL DO SISTEMA ................................................................................................................. 87
XII

Lista de Acrónimos
ACL Asynchronous Connection-Less
Conexão assíncrona no protocolo Bluetooth.
ADC Analog to Digital Converter (Conversor Analógico - Digital)
Converte um sinal analógico numa palavra binária. A resolução do conversor
ditará o número de bits da palavra binária resultante.
AIB APS Information Base
Grupo de elementos de configuração do ZPS da Jennic.
APDU Application protocol data unit
Pacote de dados da camada de aplicação do protocolo Zigbee.
API Application Programming Interface
Conjunto de rotinas e padrões estabelecidos por um software para a utilização
das suas funcionalidades.
APS Application Support Sub-Layer
Sub-camada da camada de aplicação da pilha protocolar Zigbee.
ASK Amplitude Shift Keying
Tipo de modulação de sinal que consiste em alterar o nível de amplitude da
onda portadora.
BAN Body Area Network (Redes de área corporal)
Sistema composto por dispositivos distribuído pelo corpo humano que
comunicam entre si.
BIOSWIM Body Interface System based on Wearable Integrated Monitorization
Sistema de Interface Corporal Integrada em Vestuário para Monitorização de
Sinais.
BPSK Binary Phase Shift Keying
Tipo de modulação de sinal onde a informação do sinal digital é transmitida na
fase da onda portadora.
BSN Body Sensor Network (Rede corporal de sensores)
Sistema composto por dispositivos conectados com sensores distribuído pelo
corpo humano que comunicam entre si.
CAP Contention access period
Intervalo de tempo inicial no processo de Superframe.
CRC Cyclic Redundancy Check
Técnica de protecção de dados.
DAC Digital-to-Analog Converter
Converte uma palavra binária num sinal analógico. O resultado pode ser em
corrente como em tensão.
XIII

DBG Debug (Depuração)
Processo de encontrar e reduzir defeitos numa aplicação de software ou
hardware.
DH Data High rate
Pacotes de transporte de grandes quantidades de dados no protocolo Bluetooth.
DM
Data Medium rate
Pacotes de transporte de médias quantidades de dados no protocolo Bluetooth.
DSSS Direct-Sequence Spread Spectrum
Tipo de modulação de sinal onde os bits de informação são multiplicados por
uma sequência de espalhamento espectral.
EMG Electromyography
Técnica para avaliar e guardar a actividade eléctrica produzida nos músculos do
corpo humano.
FA Frequência de Amostragem
FFD Full Function Device
Tipo de dispositivo físico nas redes sem fios de construção complexa.
FHSS Frequency Hopping Spread Spectrum
Tipo de modulação de sinal onde a informação do sinal digital é transmitida na
frequência da onda portadora num padrão pseudo-aleatório.
GFSK Gaussian Frequency Shift Keying
Tipo de modulação de sinal onde a informação do sinal digital depois de passar
por um filtro Gaussiano é enviada na frequência da onda portadora.
GTS Guaranteed Time Slots
Intervalo de tempo final no processo de Superframe.
IDE Integrated Development Environment
Ambiente integrado para desenvolvimento de software.
IEEE Institute of Electric and Electronic Engineers
Grupo de desenvolvimento que actua sobre a tecnologia das redes sem fios.
ISM Industrial, Scientific, Medicine
Bandas de rádio frequência reservadas internacionalmente para aplicações
industriais, científicas e Médicas.
JTAG Join Test Action Group
Protocolo usado para testes e debug de hardware.
LabVIEW Laboratory Virtual Instrument Engineering Workbench
Plataforma e ambiente de desenvolvimento para linguagem de programação
gráfica da National Instruments.
LQI Link Quality Indicator
Valor de 8 bits que indica a qualidade do sinal entre dois dispositivos emissor e
receptor.
MCPS MAC Common Part Sublayer
Interface responsável pelo envio e recepção de dados no protocolo 802.15.4.
XIV

MISC Minimal Instruction Set Computer
Grupo de elementos de configuração do ZPS da Jennic.
MLME MAC Layer Management Entity
Interface de gestão da rede usado para todos os comandos da camada MAC do
protocolo 802.15.4.
NPDU Network Protocol Data Unit.
Pacote de dados da camada de rede do protocolo Zigbee.
NTC Negative Temperature Coefficient
Termístores cujo coeficiente de variação de resistência com a temperatura é
negativo: a resistência diminui com o aumento da temperatura.
O-QPSK Quadrature Phase Shift Keying
Tipo de modulação de sinal onde dois bits são codificados como um só símbolo
na onda portadora.
PC Personal Computer
Máquina capaz de variados tipos de tratamento automático de informação ou
processamento de dados.
PCB Printed Circuit Board
Placa de circuito impresso
PDA Personal Digital Assistant
PDM Persistent Data Manager
Módulo que trata do armazenamento dados da aplicação Zigbee em memória
não-volátil.
PDUM Protocol Data Unit Manager
Módulo que faz a gestão dos pacotes de mensagens.
PHP Hypertext Preprocessor
Linguagem de programação para gerar conteúdo dinâmico na World Wide Web
(WWW).
PWRM Power Manager
Módulo que faz a gestão energética de dispositivos.
RF Rádio-Frequência
Radiações eletromagnéticas com frequência das ondas de rádio.
RFD Reduced Function Device
Tipo de dispositivo físico nas redes sem fios de construção simples.
RSSF Redes de Sensores Sem Fios
SCO
Synchronous Connection-Oriented
Conexão síncrona no protocolo Bluetooth.
SI Sistema Internacional
Conjunto de definições, ou sistema de unidades, que tem como objectivo
uniformizar as medições.
XV

SMA SubMiniature version A
Conector coaxial de rádio frequência.
UART Universal Asynchronous ReceiverTtransmitter
Dispositivo de hardware utilizado para comunicação série a maiores distâncias e
com sincronização feita por software.
USB Universal Serial Bus
Protocolo criado com o objectivo de interligar de uma forma simples e
normalizada os dispositivos periféricos ao computador.
VI Virtual Instrument
Subrotina na linguagem gráfica do Labview.
WiFi Wireless Fidelity
Marca registada da Wi-Fi Alliance, que é utilizada por produtos certificados que
pertencem à classe de dispositivos de rede local sem fios.
WiMax Worldwide Interoperability for Microwave Access
Protocolo de redes sem fios para WMANs.
WLAN Wireless Local Area Network
Rede local sem fios.
WMAN Wireless Metropolitan Area Network
Rede metropolitana sem fios.
WPAN Wireless Personal Area Network
Rede pessoal sem fios.
WWAN Wireless Wide Area Network
Rede sem fios de longo alcance.
ZPS ZigBee PRO Stack
Pilha protocolar Zigbee.
XVI

Lista de Símbolos
Ω Ohm
A Ampere
bps Bits por segundo
dB Decibéis
G Giga
Hz Hertz
K Kilo
m Metro
M Mega
V Volts
W Watt
XVII

1 Introdução e
1
Objectivos
A área da monitorização do corpo humano surgiu há muito tempo e têm sido objecto de
estudo ao longo de muitos anos. Existem vários métodos e formas de efectuar a monitorização
de sinais importantes para determinado desempenho ou comportamento de um indivíduo. No
caso das aplicações de monitorização, onde os sinais são adquiridos automaticamente por
sistemas electrónicos, existem igualmente diversas formas de processar e transferir os dados.
Uma delas é efectivamente as redes de dados, onde há troca de informação entre dois ou mais
dispositivos, e a informação principal flui pelos vários nós (dispositivos na rede) até um terminal
destino. O meio de comunicação pode ser, fio condutor, ou o próprio ar envolvente entre os
dispositivos emissores e receptores, no caso das redes sem fios. Em ambos os casos das redes
com e sem fios, têm-se verificado uma grande evolução nos últimos anos, com várias aplicações
em diferentes áreas. O trabalho efectuado nesta dissertação, insere-se na área da monitorização
do corpo humano e usa redes sem fios para transmitir informação.
A dissertação é desenvolvida no âmbito do projecto BIOSWIM (Body Interface System
based on Wearable Integrated Monitorization) o qual tem como propósito medir vários sinais do
corpo humano durante a prática de um exercício físico pré-determinado. Para fazer essa
monitorização é necessário um sistema que engloba uma rede de área corporal para fazer a
transmissão dos vários sinais. A dissertação em concreto tem como objectivo a criação dessa
rede sem fios para ser integrada no fato de natação, no desenvolvimento de uma aplicação
gráfica para controlar a rede e visualizar os sinais dos sensores e no desenvolvimento de um
sensor de temperatura timpânica para teste da rede.

2
Introdução e Objectivos
De seguida será apresentado o projecto BIOSWIM, os seus principais objectivos e
requisitos, as principais metas desta dissertação e a estrutura deste documento.
1.1 O projecto BIOSWIM
O BIOSWIM é um projecto proposto pela Universidade do Minho, na qual participam
outras instituições como a Faculdade de Ciências do Desporto e de Educação Física, o INESC-
Norte e o Centro de Ciência e Tecnologia Têxtil. O principal objectivo deste projecto é a
incorporação de um sistema de monitorização num fato de natação. Este sistema pretende
monitorizar vários parâmetros de desempenho, biomecânicos, fisiológicos e químicos para
diferentes fins. Uma vez concebido um protótipo, este poderá ser utilizado na área da saúde e
bem-estar, em particular no desporto de alto rendimento, no desporto de reabilitação e no
desporto de lazer. Será composto por sensores de diversas naturezas e com objectivos distintos
que permitirão obter de uma vez só a informação que é obtida separadamente. Pretende-se que
essa informação seja visualizada em tempo real, podendo ser posteriormente analisada para
quantificar os parâmetros monitorizados e caracterizar comportamentos do indivíduo.
Requisitos
Neste projecto pretende-se também estudar a possibilidade de uma verdadeira
integração de sensores em materiais têxteis, usando as suas propriedades para fins como a
transmissão de dados ou a alimentação dos sistemas de medida. A integração dos sensores nas
peças de vestuário influencia a forma como estas são fabricadas, o que leva a uma importante
investigação sobre estes processos de integração de sensores nos têxteis. Atendendo às
características têxteis, pretende-se que o fato seja completamente integral, revestindo o corpo do
nadador desde o pescoço até às extremidades distais dos antebraços e pernas. Deve apresentar
características elásticas de forma a torná-lo aderente ao corpo do atleta e exercer uma pequena
compressão do seu volume. Deve oferecer duas características térmicas: uma que facilite as
trocas térmicas não constrangidas com a água e outra que preserve o calor interior.

Capítulo - 1
Ao nível da rede de comunicação sem fios, o principal requisito é ter uma boa relação
taxa de transmissão de dados/consumo de energia, combinado simultaneamente a uma boa
capacidade de adaptação a diferentes configurações de rede.
A taxa de transmissão de dados deverá ser suficiente para o fluxo de dados de todos os
sensores que medem os diferentes parâmetros, sem que ocorram atrasos na recepção de
dados. Existem sensores que necessitam de frequências de amostragem na ordem dos 1KHz
como é o caso dos sensores EMG (Electromiografia) os quais medem a actividade eléctrica nos
músculos. Outros sensores, como o de medição de temperatura timpânica, exigem frequências
de amostragem mais baixas, pois o valor da grandeza física tem uma variação mais lenta.
Quanto ao consumo de energia, o sistema deverá funcionar, no mínimo, durante uma sessão de
treino de natação, tendo autonomia para fazer a monitorização de todos os sinais durante esse
período. A capacidade de adaptação também é importante para este sistema, porque existe
sempre o problema do terminal central da rede que recebe todos os dados, não ter capacidade
suficiente para atender todos os sinais provenientes dos dispositivos que fazem aquisição de
sinal. Neste caso, era necessário ponderar a implementação de outras soluções, como a
implementação de uma rede com fios ou adição de mais terminais receptores de dados na rede
sem fios.
Parâmetros a avaliar pelo BIOSWIM
O projecto BIOSWIM compromete-se a avaliar vários parâmetros importantes para o
estudo do comportamento humano no desporto (Tabela 1). Entre eles estão parâmetros de
desempenho relacionados com a performance desportiva do atleta como o tempo, distância e
velocidade de nado; parâmetros biomecânicos, ou seja, informação relacionada com os
movimentos mecânicos dos membros do corpo e da cabeça; parâmetros fisiológicos, como a
actividade eléctrica dos músculos (electromiografia) ou a frequência cardíaca
(electrocardiografia), que são parâmetros bastante influentes no desempenho do atleta, e por
último, o BIOSWIM preconiza ainda a avaliação de três parâmetros bioquímicos com base no
suor do corpo do atleta.
3

Parâmetros de
desempenho
Tempo de nado
Número de piscinas
/ distância de nado
Velocidade média
de nado (entre
partida e chegada)
Tabela 1: Parâmetros a avaliar no projecto BIOSWIM
4
Introdução e Objectivos
Parâmetros biomecânicos Parâmetros fisiológicos Parâmetros
Número de ciclos
Frequência gestual
Velocidade instantânea de
deslocamento
Pressão palmar na mão
Pressão dorsal na mão
Diferencial de pressão
Posição angular do cotovelo
Posição angular do pulso
Posição angular da cabeça
Electromiografia (em
diferentes músculos)
Electrocardiograma
Frequência cardíaca
Frequência ventilatória
Volume de ar corrente
Ventilação pulmonar
Temperatura timpânica
Gasimetria capilar
bioquímicos
Iões
Lactato
Amónia
Muitos destes parâmetros são de difícil medição, e têm o problema acrescido de serem
medidos num ambiente hostil como a água juntamente com o cloro das piscinas, que influencia
os valores adquiridos pelo sistema. Por todas estas razões é necessário estudar vários tipos de
soluções e utilizar os mais diversos tipos de sensores de modo a se obter um protótipo eficiente.
1.2 Objectivos do trabalho
Os objectivos deste trabalho são a concepção de um sistema de recolha de dados/sinais
analógicos dentro do fato de natação, com o condicionamento, aquisição e transmissão dos
dados para um controlador central e/ou uma estação de processamento remota. Este sistema
deverá integrar a alimentação eléctrica para os sensores, e interligar sensores de natureza
distinta. A solução deverá ser capaz de funcionar de modo autónomo durante um determinado
período de tempo. No trabalho deverão ser considerados os diferentes tipos de sensores a
utilizar, energia consumida, e sua interligação ao sistema de aquisição, bem como redes de
comunicação sem fios com protocolos e especificações diferentes.

Capítulo - 1
Finalmente, deverá ser concebido, montado e testado um protótipo. O protótipo começará
pelo desenvolvimento e miniaturização das funções mais básicas do sistema, ou seja,
condicionamento, aquisição de sinal e alimentação eléctrica, para posteriormente integrar esse
hardware com os módulos de comunicação. Este trabalho resultará em módulos genéricos
multifuncionais para implementação de sensores sem fios e numa aplicação gráfica para
apresentar os dados recolhidos pelos nós sensores. Como demonstração, será desenvolvido de
raiz o condicionamento de sinal para um sistema de medição de temperatura timpânica.
1.3 Cronologia
No decorrer do trabalho foram cumpridos prazos, estabelecidos anteriormente para o
bom funcionamento do projecto. O projecto foi iniciado no mês de Outubro de 2009, quando
foram definidos os objectivos e principais contornos do trabalho. Para se ter um pouco da noção
do trabalho efectuado ao longo do tempo, pode ser observado o cronograma da Figura 1.
Figura 1: Cronograma do projecto.
No inicio do trabalho foi feita uma pesquisa nas áreas de monitorização do corpo
humano, e-têxteis e Body Area Networks, para se fixarem as primeiras ideias de como se iria
desenvolver um sistema integrado num fato de natação para monitorizar os diferentes sinais
provenientes do corpo humano.
5

6
Introdução e Objectivos
Depois de definidos todos os requisitos do sistema, foram escolhidos os módulos de
comunicação, bem como o protocolo de rede sem fios com o qual se iria trabalhar. Ainda no
mês de Outubro foi encomendado o kit de desenvolvimento para a rede de comunicação,
momento em que se iniciou o estudo do ambiente de desenvolvimento, da estrutura do software
e das API’s (Application Programming Interface) da Jennic.
Em Novembro foi recebido o kit de desenvolvimento, momento em que foi iniciada a
programação e implementação da rede sem fios com o protocolo Zigbee.
Depois da primeira versão do firmware da rede sem fios, no final de Fevereiro, foi
iniciado o desenvolvimento da aplicação gráfica no computador, e da interface entre o dispositivo
coordenador e a recepção de dados da aplicação gráfica.
Uma vez terminada a primeira versão da aplicação gráfica e rede sem fios com o
protocolo Zigbee, e com o intuito de melhorar os resultados, foi iniciado o desenvolvimento de
uma rede sem fios com o protocolo de mais baixo nível 802.15.4. No início de Junho, terminado
este desenvolvimento, foi realizado o circuito condicionador para o sensor de temperatura
timpânica.
No final de todo o trabalho realizado foram testados todos os elementos que compõem o
sistema de monitorização, e procederam-se a algumas alterações para optimização e correcção.
1.4 Organização da Tese
Este documento descreve todo o trabalho desenvolvido na pesquisa e projecto de um
sistema protótipo capaz de monitorizar e controlar sensores integrados num fato de natação.
Após a introdução segue-se a fundamentação teórica, no segundo capítulo, onde são
apresentados sistemas e-têxteis, sensores de temperatura timpânica e redes de comunicação
sem fios de curto alcance. São descritas as características que interessam a este projecto, bem
como os requisitos na utilização destas tecnologias.
No terceiro capítulo é apresentado o desenvolvimento, onde é mostrado todo o trabalho
efectuado neste projecto. Começa-se por descrever a arquitectura do firmware da aplicação da
rede sem fios implementada com o protocolo Zigbee e posteriormente com a especificação
802.15.4. Seguidamente é apresentado o software da aplicação gráfica, implementado no

Capítulo - 1
ambiente de desenvolvimento LabView. Por fim, e para completar o projecto é descrito o
desenvolvimento ao nível do hardware para o sensor de temperatura timpânica.
No quarto capítulo são mostrados os testes e resultados em termos do desenvolvimento
e performance do sistema. É feita uma análise dos mesmos e da relação entre eles, bem como
uma discussão dos problemas e soluções implementadas ao longo do projecto.
Finalmente, no quinto capítulo são apresentadas todas as conclusões deste trabalho.
Foram ainda adicionadas algumas informações importantes associadas ao projecto, que seguem
em anexo a esta dissertação.
7

2 Estado da Arte e
Fundamentos Teóricos
2.1 Monitorização de pessoas com e-têxteis
Os e-têxteis surgem da fusão entre as tecnologias dos materiais têxteis e sistemas
electrónicos. São também conhecidos como têxteis electrónicos ou frequentemente chamados
de roupa inteligente e permitem a incorporação de sistemas computacionais, electrónica digital
ou analógica, nas fibras têxteis [1].
Esta tecnologia tem sido objecto de estudo, devido à recente evolução da tecnologia de
informação, à miniaturização dos sistemas electrónicos e à exigência do público consumidor.
Existem alguns sistemas electrónicos inseridos na roupa que podem ser confundidos com e-
têxteis, mas neste caso terão que ser projectados para se adequar às características dos tecidos
como estiramentos ou rasgos [2].
A tecnologia dos e-têxteis deverá ser constituída por materiais de baixo custo e
descartáveis para serem compatíveis com as roupas comuns. No entanto, a diferença das
propriedades físicas dos e-têxteis e os componentes electrónicos, acrescida ainda da
necessidade de ter baixos consumos de energia, reduzem um pouco a capacidade de
processamento e armazenamento destes sistemas [2].
8

Capítulo - 2
Aplicações
Actualmente, os e-têxteis estão aplicados nas mais diversas áreas como a saúde e a
segurança. Nestas áreas os e-têxteis aumentam a autonomia dos pacientes com sistemas de
auxílio miniaturizados e permanentes, previnem situações de alto risco, visto os pacientes
estarem, constantemente e em tempo real, conectados com hospitais, ajudam no dia-a-dia, na
prevenção contra hábitos incorrectos (posturas, prevenção contra acidentes caseiros).
Existem também aplicações militares para monitorizar sinais vitais (batimento cardíaco,
frequência respiratória), comunicar com base central em caso de emergência, monitorizar o
território e condições climáticas, fazer identificação em combate, camuflar com adaptação da cor
do fato ao meio envolvente. Veja-se o protótipo Wearable Motherboard, apresentado na Figura 2,
desenvolvido pelo Georgia Tech Institute que para além de monitorizar vários sinais vitais, ainda
identifica se o militar foi atingido por alguma arma de fogo [1].
Figura 2: Wearable Motherboard - Georgia Tech Institute.
A área de jogos e multimédia adoptou também esta tecnologia, com a utilização dos e-
têxteis para aumentar o realismo da interacção dos jogos com o ser humano (interacção
sensorial, visual e auditiva com o mundo virtual). Existem roupas interactivas com fins práticos
ou de entretenimento com displays, leitores de mp3 ou interacção com PDAs (Figura 3).
9

Figura 3: Roupa interactiva [3].
10
Estado da arte e Fundamentos teóricos
O desporto sempre esteve associado às inovações tecnológicas. A monitorização
constante para os desportos considerados de alto risco revela-se muito importante, uma vez que
a actividade muscular do corpo humano é levada ao extremo. É aqui que se insere o projecto
BIOSWIM, na monitorização de sinais biométricos na prática de natação.
Os e-têxteis têm vários problemas relacionados com as suas características que diferem
bastante das características dos sistemas electrónicos. Em geral, o grande problema dos e-
têxteis é a integração de componentes electrónicos, fios e fibras condutoras nos produtos têxteis,
como os tecidos ou malhas. Esta integração deverá manter as características condutoras dos
fios ou do conjunto de fibras e manter a flexibilidade do tecido de modo a poder ser vestido e
garantir o funcionamento dos sistemas. Um outro problema igualmente importante é a
manutenção do e-têxtil. Fazendo parte de uma peça de vestuário, será sujeito a procedimentos
de limpeza tradicionais como lavagem, secagem, procedimentos esses nada amigáveis para os
sistemas electrónicos.
Nos e-têxteis onde sensores são integrados sensores no tecido, podem ser utilizados
dispositivos emissores e receptores para estabelecerem as comunicações entre eles. Nestes
sistemas são usadas redes de sensores sem fios (RSSF), que permitem a não utilização de fibras
condutoras para a comunicação entre dispositivos, o que se revela uma vantagem. Esta solução
tem consumos de energia maiores do que as redes com fios, o que leva a outras investigações
sobre a obtenção de energia através do corpo humano, para o sistema se tornar autónomo.
Perspectivas Futuras
Existe a necessidade de novas tecnologias como novos equipamentos electrónicos que
se adaptem às necessidades dos e-têxteis como o baixo consumo de energia, e que tenham

Capítulo - 2
baixo custo de fabricação. Existe a necessidade de novos tipos de fibras condutoras com
propriedades físicas adaptadas e novas antenas, facilmente integráveis aos tecidos. A ausência
de fios é altamente atractiva para os e-têxteis, porém estes sistemas ainda possuem um
consumo de energia considerável.
Actualmente, estão a ser estudadas algumas soluções que minimizam alguns dos
problemas actuais dos e-têxteis. São eles os transístores orgânicos que possuem alta
flexibilidade e resistência física compatíveis com os e-têxteis, fabricados com técnicas de
sputtering 1 . Sensores orgânicos são também uma nova solução. São construídos sobre uma
material flexível que constitui um tecido sensível à pressão e temperatura. Veja-se o exemplo da
Figura 4, em que foi construída uma mão robótica com revestimento a sensores orgânicos na
tentativa de imitar a pele humana. No entanto tem ainda poucos sensores quando comparados
com o dedo humano (16/cm 2 ), enquanto que a pele humana tem 1500/cm 2 [4].
Figura 4: Pele para robôs feita de sensores orgânicos [5] [6].
Estão ainda a ser considerados nanotubos de carbono com moléculas cilíndricas de
carbono formadas quando “folhas” de carbono se fecham. Podem ter propriedades metálicas ou
semi-condutoras, são leves, flexíveis, têm estabilidade térmica e são quimicamente inertes [7].
Os e-têxteis estão cada vez mais próximos do nosso quotidiano, têm uma velocidade de
crescimento surpreendente, num mercado extremamente promissor (desde recém-nascidos a
idosos). Induz o surgimento de novas técnicas e tecnologias e um enorme avanço na interacção
homem/máquina.
1 Técnica de injecção contínua de átomos num material alvo por bombardeamento de partículas
energéticas.
11

2.2 Sinais biométricos
12
Estado da arte e Fundamentos teóricos
A biometria é a ciência que estuda as características físicas ou comportamentais dos
seres vivos. Este termo é recentemente associado à medida de características físicas ou
comportamentais das pessoas como forma de identificá-las individualmente [8]. Um dos sinais
biométricos, que será medido pelo projecto BIOSWIM é a temperatura timpânica.
2.2.1 Sensores de temperatura timpânica
A temperatura corporal é um sinal vital e pode ser indicador do estado de saúde de um
paciente. O corpo consegue manter a temperatura dentro de uma gama de segurança, apesar
das grandes variações que se fazem sentir fora do corpo.
Durante um exercício físico, parte do calor que é gerado a nível muscular, é transportado
para os tecidos mais profundos, o que aumenta a temperatura corporal central [9]. Num
exercício de elevada intensidade, a produção de calor corporal (energia) pode exceder os
1000W, o que poderá promover o aumento de um grau por cada cinco a oito minutos, caso não
se registem mudanças nos mecanismos de dissipação de calor [10]. Assim na prática de
exercício intenso, o aumento da temperatura corporal provoca fadiga muscular, o que influencia
a performance do atleta. Por estes motivos é determinante acompanhar a temperatura corporal
dos atletas na prática desportiva.
Esta medição pode ser efectuada em várias partes do corpo, sendo a medição no
tímpano uma forma bastante rápida e eficaz quando medida correctamente [11]. Outra grande
vantagem da medição da temperatura no tímpano é a sua proximidade ao hipotálamo, o órgão
que controla a temperatura corporal, o que torna as medições mais precisas (Figura 5).

Capítulo - 2
Figura 5: Corte vertico-transversal do ouvido direito [11].
Existem vários tipos de sensores de temperatura timpânica com princípios de
funcionamento, grau de precisão e exactidão diferentes (Figura 6).
Figura 6: Sensores de temperatura timpânica.
Um tipo de sensores comum são os que medem a temperatura directamente em
contacto com o tímpano, este tipo de sensores são classificados de invasivos. Outro tipo de
sensores bastante usado actualmente em termómetros digitais é o dos sensores infra-vermelhos.
O princípio de funcionamento deste sensor consiste na medição da energia da radiação infra-
vermelha emitida pela membrana timpânica e de tecidos vizinhos [11]. Ambos os sensores têm
um grau de eficácia superior a outros sensores de temperatura corporal.
2.3 Redes de área corporais (BAN)
Uma rede de área corporal (em inglês Body Area Networks) é um sistema distribuído
composto por dispositivos, conectados por um meio de comunicação e alimentados por baterias,
localizado no corpo humano [12]. Um tipo de redes de área corporais é as redes de sensores
corporais (Body Sensor Networks – BSN), onde as redes são constituídas por sensores junto dos
dispositivos que englobam a rede. Nestas redes, o nó sensor é geralmente composto por uma
13

14
Estado da arte e Fundamentos teóricos
unidade de processamento, memória, interfaces, sensores, rádio transmissor e receptor, e fonte
de alimentação [13].
Desenvolvimento das redes corporais de sensores
A tecnologia BAN é uma tecnologia emergente, que surge como um produto natural da
combinação entre as redes corporais existentes e a engenharia biomédica. Existem muitas
aplicações para as BANs, sendo os casos mais comuns a monitorização médica, monitorização
desportiva, áudio sem fios, integração em dispositivos móveis e vídeo pessoal. Cada uma destas
aplicações tem requisitos específicos em termos de largura de banda, velocidade de
transmissão, potência ou distância de sinal. O IEEE (Institute of Electric and Electronic
Engineers) 802.15 é o grupo de desenvolvimento para Wireless Personal Area Networks (WPAN),
onde se situam as BANs e tem desenvolvido aplicações com boa relação consumo de energia e
taxa de transmissão de dados. A Figura 7 descreve a posição ideal das BANs no espectro da
relação consumo de energia/taxa de transmissão de dados (adaptado de [14]).
Figura 7: Velocidade de transmissão vs Consumo de energia [14] data: 23/04/2008.
Como se pode verificar, a gama de dispositivos BAN pode variar muito em termos de
largura de banda e consumo de energia, no entanto tem maioritariamente consumos de energia
bastante baixos e uma taxa de transmissão de dados média/baixa, quando comparados com
outros sistemas de comunicação sem fios.

Capítulo - 2
Características e funcionamento
As redes corporais de sensores (BSN) têm algumas características que são comuns a
várias aplicações. Uma das características é a tolerância a alguns tipos de falhas, devido à
grande probabilidade de ocorrerem problemas na rede. Outra característica é o consumo de
energia que muitas vezes é um problema, geralmente nas aplicações em que é necessário o
funcionamento por longos períodos de tempo. Nestes casos, os sensores podem esgotar a
energia da fonte de alimentação e deixar de funcionar correctamente. Pode acontecer também
que os dispositivos deixem de funcionar, por causa de falhas de comunicação entre dois ou mais
nós, e neste caso é necessário utilizar mecanismos de redundância que tratem estes problemas
[15].
Uma rede de sensores sem fios tem o seu tempo de vida dependente da qualidade de
serviço e energia disponível. Para aumentar esse tempo de vida podem-se seguir vários
caminhos, um deles é precisamente utilizar sensores que usam energias renováveis para se
alimentarem, como por exemplo a energia solar, embora estas fontes sejam limitadas. Outra
solução é a obtenção de energia através do próprio corpo humano onde é aplicada a rede sem
fios [15].
Projectos actuais
As redes de sensores no corpo humano têm diversas aplicações e existem actualmente
vários projectos que estão em desenvolvimento ou que foram implementados actualmente.
Existem aplicações na área da monitorização médica, onde os pacientes podem ser
monitorizados 24 horas por dia pelo sistema. É o caso do projecto Human++ desenvolvido na
Bélgica, onde um dispositivo na rede tem a capacidade de comunicar com qualquer outro
dispositivo [14]. Um dispositivo central pré-definido é designado para todas as comunicações, e
publica informações sobre todos os serviços (Figura 8). Podem ser avaliados parâmetros como a
temperatura corporal, oximetria, pressão sanguínea, níveis de glicose ou funções respiratórias.
15

Figura 8: Projecto Human++ desenvolvido na Bélgica [14].
16
Estado da arte e Fundamentos teóricos
Outro projecto sobre as redes de monitorização do corpo humano é uma investigação
levada a cabo na universidade do Dallas nos Estados Unidos da América recorrendo à utilização
das BANs para avaliar o equilíbrio do corpo humano. Este sistema interpreta as actividades
musculares baseado em sensores de inércia e de electromiografia, enquanto se executam
movimentos [16].
Existem outras aplicações, nomeadamente em áudio sem fios, onde um dispositivo
áudio pode comunicar com outros dispositivos na rede como PDA’s (Personal Digital Assistant),
telemóveis ou computadores (Figura 9).
Limitações das Redes de Área Corporais
Figura 9: Áudio sem fios.
Um dos maiores problemas das redes de sensores para monitorização do corpo humano
continua a ser o tempo de funcionamento dos dispositivos, que é determinado principalmente
pelo consumo da energia armazenada pelas baterias. Isto deve-se ao facto da evolução da
capacidade de armazenamento de energia das baterias não ter acompanhado a evolução dos

Capítulo - 2
demais dispositivos computacionais. Para lidar com a limitação imposta pelas baterias,
actualmente existem duas principais abordagens: a adequação do software e do hardware para o
uso racional da energia eléctrica e a extracção da energia necessária do meio no qual o nó
sensor é utilizado. A primeira abordagem é a mais utilizada, no entanto a segunda abordagem
tem evoluído de forma significativa. Em alguns sistemas e-têxteis a energia pode ser obtida pelo
uso de transdutores que convertem energia mecânica, por exemplo, obtida dos movimentos do
corpo humano, em energia eléctrica, necessária para a alimentação dos circuitos electrónicos.
Um exemplo disso é o sistema shoes generators apresentado na Figura 10, onde é gerada
energia eléctrica até 60 mW (miliwatts) de potência [17].
Figura 10: Sapatilhas geradoras de energia. Projecto Shoes Generators, desenvolvido por MIT Media Laboratory [17].
Na próxima secção serão abordados os protocolos de comunicação sem fios de curto
alcance, visto estes estarem na base de todas as redes corporais de sensores e constituírem um
elemento fundamental no funcionamento dos mesmos.
2.4 Protocolos de comunicação sem fios de curto
alcance
As várias alternativas e protocolos para a comunicação sem fios, têm-se revelado
bastante importantes no desenvolvimento tecnológico, mais concretamente no ramo das
telecomunicações. No início deste projecto foram considerados dois protocolos distintos, Zigbee
e Bluetooth, que têm ambos características importantes para a aplicação, no entanto têm
também alguns pontos menos favoráveis para este caso.
17

18
Estado da arte e Fundamentos teóricos
Foram ainda considerados outros protocolos de comunicação de curto alcance como
demonstrado na Figura 11, em que se compara a relação entre o alcance (range) e a taxa de
transmissão de dados (data rate) dos diferentes protocolos.
Figura 11: Posicionamento das tecnologias de comunicação sem fios, adaptado de [18].
Para este tipo de aplicações, os protocolos que mais se adequam são o Zigbee e o
Bluetooth visto terem consumos de energia mais baixos que os restantes. O ZigBee foi
desenvolvido para monitorização de sistemas, enquanto o Bluetooth é mais apropriado em
aplicações que requerem uma maior taxa de transmissão de dados, como por exemplo as redes
Ad-hoc ou sistemas para transmissão de áudio ou de dados ponto a ponto.
Na Tabela 2 são comparados estes dois protocolos segundo algumas características
importantes para a aplicação como o alcance, a taxa de transmissão de dados, consumo de
energia, ou número de dispositivos por rede. Verifica-se, por exemplo, que o Zigbee tem um
menor consumo de energia, alta flexibilidade e a possibilidade de junção de 65000 nós na rede,
por outro lado o Bluetooth tem taxas de transmissão de dados mais elevadas [19], o que é
importante para o sistema suportar vários nós sensores na rede a comunicarem sem perderem
dados.

Capítulo - 2
Tabela 2: Comparação dos protocolos Zigbee e Bluetooth, adaptado de [20].
Característica Zigbee
(IEEE 802.15.4)
Frequência de Operação 868 MHz, 902-928 MHz,
Alcance
Projectado
Kits especiais ou ambiente externo
2,4GHz ISM
10-100 m
Até 400 m
19
Bluetooth
(IEEE 802.15.1)
2,4 GHz ISM
10 m
Acima de 100 m
Potência Nominal de Transmissão (-25) - 0 dBm 0 - 10 dBm
Taxa de transmissão máxima 250 Kbps 1 Mbps
Número de canais RF 1/10; 16 79
Tipo de Modulação BPSK (+ ASK), O-QPSK GFSK
Propagação DSSS FHSS
Latência (típica)
Junção de novo slave
Acesso ao canal
30 ms
5 ms
Perfil de Alimentação Anos
Requer alimentação do slave
optimizada
Segurança 128 bits AES e definível na
camada de aplicação
20 s
2 ms
Dias
Funcionalidades adhoc
maximizadas
64 bits, 128 bits
Complexidade Simples Complexo
Topologias de Rede Malha, Estrela e Árvore Adhoc piconets
Número de dispositivos por rede 2-65000 8
Protecção de dados 32-bit CRC 16-bit CRC
Flexibilidade Muito alta Média, dependente do perfil
De seguida irá ser abordado cada um destes protocolos de forma mais pormenorizada,
de modo a se perceber melhor o seu funcionamento.
2.4.1 802.15.4
A especificação 802.15.4, normalizada pelo IEEE, foi introduzida para preencher um
nicho de mercado que os protocolos Bluetooth e 802.15.3 não satisfaziam. Na sua forma mais

20
Estado da arte e Fundamentos teóricos
básica, este protocolo permite uma comunicação de 10 metros com taxas de transmissão de
dados de 250 kbps.
Este protocolo define uma estrutura baseada em camadas, que distribuem entre si
diferentes tarefas. Essa estrutura é baseada no modelo de referência de comunicação em rede
OSI (Open Systems Interconnection) estabelecido pela ISO (International Standard Organization),
onde foram definidas, primeiramente, duas camadas (Figura 12). A camada física − Physical
Layer (PHY) − é a camada mais baixa da pilha protocolar e é implementada em hardware. Tem
como função codificar os bits que são enviados, descodificar os que são recebidos e receber
informação fornecida pela camada MAC, como por exemplo informação sobre o tráfego do canal,
qualidade da conexão ou potência do sinal recebido. A camada de acesso ao meio − Medium
Access Control (MAC) – controla o acesso ao canal de rádio. Nesta camada são gerados e
reconhecidos os endereços dos outros dispositivos da rede, é feita a verificação das sequências
das tramas controlo (frame check), e sincronização de tramas no modo de transmissão non-
beacon (explicado na secção seguinte) [21].
Figura 12: Arquitectura protocolar do protocolo 802.15.4, adaptado de [22].
Este protocolo especifica uma rede de comunicação sem fios caracterizada pela baixa
taxa de transmissão de dados, curto alcance, baixo consumo de energia, custo reduzido e
simplicidade. É com base neste protocolo, que foi criado o Zigbee.
Como muitas das características e processos de funcionamento do 802.15.4 são iguais
ao protocolo Zigbee, estas serão explicadas na secção seguinte, juntamente com o que o Zigbee
acrescenta.

Capítulo - 2
2.4.2 Zigbee
O protocolo Zigbee nasceu da necessidade de uniformizar os protocolos para garantir a
interoperabilidade entre os sistemas e foi criado pelo grupo Zigbee Alliance.
Considerações técnicas
O protocolo base do Zigbee, o 802.15.4 foi designado para operar em bandas de
radiofrequência isentas de licenciamento, internacionalmente conhecidas como bandas ISM
(Industrial, Scientific, Medicine), que variam de acordo com o local geográfico (Tabela 3).
Bandas RF
Tabela 3: Bandas de radiofrequência do protocolo 802.15.4 e protocolo Zigbee, adaptado de [22].
Gama de Frequência
(MHz)
Taxa de transferência de
dados (Kbps)
21
Número de canais Área geográfica
868 MHz 868.3 20 0 (1 canal) Europa
925 MHz 902-928 40 1-10 (10 canais) América, Austrália
2400 MHz 2405-2480 250 11-26 (16 canais) Global
A principal característica do Zigbee é o baixo consumo de energia permitindo aos
dispositivos entrar em modo “sleep” quando não têm tarefas a efectuar.
Os dispositivos físicos podem ser:
FFD (Full Function Device) – podem funcionar em qualquer topologia da rede,
desempenhando a função de coordenador da rede e consequentemente ter acesso a
todos os outros dispositivos. São dispositivos de construção mais complexa;
RFD (Reduced Function Device) – são limitados a uma configuração com topologia em
estrela, não podendo actuar como coordenador da rede, apenas comunicar com este.
São dispositivos de construção mais simples.
Às duas classes anteriores de dispositivos físicos correspondem três tipos de dispositivos
lógicos: Coordenador (Coordinator), Router e Dispositivo final (End Device), e têm as funções
descritas na Tabela 4.

Dispositivo
Coordenador
Tabela 4: Tipo de dispositivos lógicos numa rede Zigbee.
Tipo de dispositivo físico
associado
(IEEE)
FFD
Router FFD
Dispositivo final RFD ou FFD
22
Estado da arte e Fundamentos teóricos
Função
Forma a rede, atribui endereços.
Existe apenas um por rede.
Permite que mais nós se juntem à rede, ao aumentar o
seu alcance físico. Pode também efectuar funções de
controlo ou monitorização. A sua existência é opcional.
Efectua acção de controlo ou monitorização através do
dispositivo que lhe esteja associado (sensor, controlador,
actuador…).
O protocolo Zigbee permite três topologias de rede distintas, a configuração em estrela
(Star), árvore (Tree) e em malha (Mesh) (ver Figura 13).
Na topologia em estrela um dispositivo actua como coordenador de rede, assumindo um
papel central e de comunicação directa com todos os nós sensores. Toda a informação da rede
passa pelo nó coordenador (ver Figura 13b). Na topologia em malha os dispositivos tipo FFD
(Coordenador/Routers) são livres de comunicar com outro dispositivo FFD. Isto permite a expansão da
rede física da rede, ficando assim com maior alcance. O coordenador regista toda a entrada e saída de
dispositivos, mas não tem um papel tão preponderante em termos de fluxo de informação como na
configuração em estrela (ver Figura 13 a). Por último, na topologia em árvore, em semelhança com a
configuração em malha também são usados dispositivos Router. No entanto, nesta topologia efectua-se a
distribuição de dados e mensagens de controlo numa estrutura hierárquica, onde o Coordenador assume
o papel de nó “nuclear” da rede (ver Figura 13 c)[23].
Figura 13: Topologias de rede. A: Malha, B: Estrela, C: Árvore, adaptado de [43].

Capítulo - 2
Todos estes nós que constituem a rede, possuem uma arquitectura protocolar composta
por camadas que comunicam entre si através de Pontos de Acesso ao Serviço (SAP). A pilha
protocolar ZigBee é formada pela camada física (PHY) e camada de controlo de acesso ao meio
(MAC), especificadas conforme o protocolo 802.15.4. É constituída ainda pela camada de rede
(NWK) e pela camada de aplicação (APL), que contém as sub-camadas Aplication Suport Sub-
Layer (APS), ZigBee Device Object (ZDO) e Aplication Framework (AF). Na estrutura também são
adicionados os objectos de aplicação definidos pelo utilizador (ver Figura 14) [24]. A seguir
consta uma breve descrição das funções de cada camada.
Figura 14: Pilha protocolar Zigbee, adaptado de [25].
As duas camadas mais baixas da pilha protocolar são a camada física, e a camada MAC.
Estas camadas foram definidas pelo protocolo 802.15.4 e já foram explicadas na secção
referente a este protocolo.
A camada de rede (NWK) é, hierarquicamente, a primeira camada que é definida no
protocolo ZigBee, e tem a responsabilidade de iniciar ou terminar uma ligação de um dispositivo
à rede, descobrir novos dispositivos na vizinhança (e o armazenamento de informação relativa
aos mesmos) e atribuir endereços. É ainda nesta camada que estão presentes os mecanismos
de descoberta de caminhos e encaminhamento de informação assim como de configuração de
novos dispositivos.
Quanto à camada de aplicação (APL), contém as sub-camadas APS, ZDO e a AF. Esta
camada pretende assegurar uma correcta gestão e suporte para as diversas aplicações[25].
23

Características operacionais
24
Estado da arte e Fundamentos teóricos
O protocolo Zigbee define mecanismos de acesso e de gestão de canal. O mecanismo
que utiliza é o CSMA-CA, onde um nó verifica a ausência de tráfego no canal antes de iniciar
uma transmissão, com o objectivo de diminuir a possibilidade de colisões. Quando um canal é
encontrado e determinado como livre, o nó inicia a transmissão; sempre que ele suspeitar de
ocorrência de colisão, então pára imediatamente de transmitir e espera um tempo aleatório
antes de tentar novamente.
Existem dois modos operação da rede, modo beacon (sinalizado) e modo non-beacon
(não sinalizado). No modo beacon os Routers transmitem periodicamente uma sinalização
(beacons) a confirmar a sua presença aos outros nós da mesma rede, sendo que os restantes
nós só necessitam de estar activos no momento da sinalização. Tal permite mantê-los no modo
sleep entre sinalizações, com evidente vantagem em termos de consumo energético. Neste
modo existe uma estrutura de superframe (ver Figura 15), que é utilizada quando é necessária
ter uma garantia que o dispositivo acedeu ao canal. O superframe inicia com um beacon e é
seguido por 16 intervalos de tempo iguais. Os primeiros nove intervalos (CAP - Contention
access period) podem ser usados por qualquer dispositivo, e os sete intervalos seguintes
(denotados como GTS - Guaranteed Time Slots) são reservados e podem ser alocados por um
dispositivo através de um pedido [23].
Figura 15: Estrutura Superframe [24].
No modo non-beacon, a maioria dos dispositivos mantém os seus receptores
permanentemente activos, sendo o consumo energético mais significativo, podendo tornar
necessárias fontes de alimentação mais robustas.
Ao nível do endereçamento, o protocolo 802.15.4 especifica dois tipos de endereço:

Capítulo - 2
Endereços de rede de 16 bits: é atribuído a um nó quando se integra na rede e
é único para cada nó na rede.
Endereços de 64 bits: Cada nó contém um endereço único permanente de 64
bits que o identifica na rede.
Quanto ao modo de transmissão de dados, existem dois tipos de transmissão: directa
em que a transferência de dados é feita do dispositivo de rede para o coordenador e indirecta
em que a transferência de dados é no sentido inverso, ou seja do coordenador para o dispositivo
de rede. Como já foi referido a transmissão pode ser feita no modo beacon ou non-beacon e o
envio de acknowledgements é opcional, sendo importante para garantir a entrega das tramas no
dispositivo de destino (ver Figura 16)[25].
Figura 16: Modos de Transmissão de dados. A-Directa com beacon activo, B: Directa com beacon inactivo, C:Indirecta.
A transmissão de dados é efectuada no envio da mensagem Zigbee, que é constituída
pelos dados a transmitir pelo dispositivo emissor, e pelo overhead acumulado das camadas que
compõem a pilha protocolar. Na Figura 17 está demonstrado o formato e como são construídas
as tramas ao longo das camadas, desde a camada de aplicação do utilizador até à camada
física.
25

Figura 17: Formato da mensagem Zigbee [26].
26
Estado da arte e Fundamentos teóricos

Capítulo - 2
O protocolo Zigbee é utilizado nas mais variadíssimas aplicações em diferentes áreas,
como por exemplo a domótica - para ligar/desligar lâmpadas ou outros dispositivos, abrir/fechar
portas, janelas; a saúde, na monitorização de sinais vitais do corpo humano para prevenção de
doenças ou fazer diagnósticos; monitorização de veículos, como a aquisição de dados dos vários
sensores hoje presentes nos automóveis ou outros meios de transporte; Na agricultura é
também uma área onde o Zigbee é utilizado para medir por exemplo a humidade dos terrenos
de áreas elevadas [22].
2.4.3 Bluetooth
A tecnologia Bluetooth surgiu em 1994, como uma das tecnologias de comunicação
sem fios para substituir os tradicionais fios de conexão entre dispositivos electrónicos. Baseado
no padrão 802.11 do IEEE, utiliza para transmissão de dados, ondas de rádio frequência e
busca promover uma solução de baixo custo e de consumo de energia para transmissão de
dados e voz. A tecnologia Bluetooth reúne soluções para as Wireless Personal Area Network
(WPANs), para alcances até 10 metros, mas pode atingir os 100 metros se utilizar circuitos
electrónicos com maior potência [27].
Características principais
O protocolo Bluetooth pretende estabelecer um padrão mundial na operatividade entre
diferentes dispositivos electrónicos. Para sustentar este objectivo a tecnologia assenta nalguns
pontos-chave essenciais:
Curto alcance: existe uma enorme variedade de dispositivos electrónicos que necessitam
de comunicação de curto alcance, como por exemplo computadores, telemóveis,
impressoras, PDAs, e outros;
Baixo consumo: como está implementado para curtos alcances não são necessárias
grandes potências de transmissão (0 a 10 dBm).
Baixo custo: A Bluetooth Special Interest Group (SIG) estabeleceu um limite máximo de 5
dólares para o custo final de um terminal Bluetooth;
Taxa de transmissão de dados elevada: Tem uma taxa de transmissão de dados elevada
quando comparada com outras tecnologias de comunicações de curto alcance (1 Mbps);
27

28
Estado da arte e Fundamentos teóricos
Especificação livre: A especificação para comunicações Bluetooth desenvolvida pelo
grupo SIG está disponível publicamente e com o intuito de estimular a sua utilização e
aceitação mundial.
Considerações técnicas
Os dispositivos Bluetooth operam na banda ISM de 2,4 GHz, que está disponível
mundialmente, sendo destinada para usos gerais em aplicações industriais, científicas e
médicas (ISM), tal como o Zigbee. Existem ainda outras fontes de RF que ocupam esta banda de
ISM como por exemplo alarmes de carro, telefones sem fios e até fontes de ruído aleatório como
microondas ou lâmpadas de vapor de sódio. Esta partilha de banda contribui significativamente
para a presença de sinais que interferem no sinal Bluetooth, tornando a banda ISM num meio
pouco estável ou confiável. Para enfrentar este meio hostil, esta tecnologia emprega algumas
técnicas como o Frequency Hopping Spread Spectrum (FHSS), que divide o espectro total de
operação em pequenas bandas ou canais [28].
No processo de transmissão de dados por FHSS, os dados são divididos em pequenos
pacotes, e são transmitidos sequencialmente. Após a transmissão de um pacote, o dispositivo
Bluetooth selecciona um outro canal para a transmissão do próximo pacote, efectuando o
chamado hopping de frequência. A sequência de hopping usada pela tecnologia Bluetooth é
aleatória e realiza 1600 hops (saltos) por segundo. Assim dispositivos que compartilham a
mesma banda reduzem a possibilidade de colisões, pois têm sequências de hopping diferentes.
Esta sequência de hopping torna também as conexões mais seguras, uma vez que os receptores
têm que conhecer a sequência para receber os pacotes e reconstruir a mensagem. Em termos
de modulação é utilizada a técnica Gaussian Frequency Shift Keying (GFSK), que consiste em
atribuir frequências diferentes para a onda portadora, em função do bit que é transmitido,
passando os pulsos correspondentes aos bits transmitidos por um filtro Gaussiano [29].
O protocolo Bluetooth especifica três níveis diferentes de potência de transmissão como
se pode verificar na Tabela 5.

Capítulo - 2
Classe
Tabela 5: Níveis de potência de transmissão.
Potência
29
Alcance
1 100 mW (+20dBm) 100 m
2 2,5 mW (+4 dBm) 25 m
3 1 mW (0 dBm) 10 m
Estas classes de potência possibilitam diferentes alcances para os dispositivos
Bluetooth. A classe 3 tem alcances até 10 metros, enquanto a classe 1 atinge os 100 metros.
Os dispositivos Bluetooth podem operar como Master (mestre) ou como Slave (escravo).
Um dispositivo Master pode comunicar simultaneamente com sete dispositivos Slaves no
máximo, sendo que estes dispositivos só podem comunicar directamente com o Master. O
conjunto formado pelo Master-Slave é denominado piconet. Todos os dispositivos, numa piconet
obedecem a uma mesma sequência de hopping de frequência, definida pelo Master da piconet.
A Figura 18 ilustra as duas situações de conexão possíveis dentro de uma piconet: conexões
ponto a ponto e conexões ponto a multiponto.
Figura 18: (a): Piconets ponto a ponto, (b): ponto a multiponto, adaptado de [30].
A área de cobertura de uma piconet é definida pelo raio de alcance do dispositivo
mestre. Áreas de cobertura maiores ou redes com maior número de dispositivos podem ser
obtidos através da união de piconets, o que se designa scatternet (Figura 19).

Figura 19: Dois exemplos de Scatternet, adaptado de [30].
30
Estado da arte e Fundamentos teóricos
Na scatternet da Figura 19 (a), o dispositivo em comum actua como Master numa
piconet e como Slave na outra. Na scatternet da Figura 19 (b), o dispositivo em comum opera
como Slave nas duas piconets. A conexão de duas piconets numa scatternet é feita através de
um dispositivo que pertence simultaneamente às duas piconets, dividindo o seu tempo de
operação entre elas. O dispositivo em comum não pode operar como Master nas duas piconets
uma vez que os Slaves são sincronizados à sequência de hopping do dispositivo Master da
piconet. Por definição, todos os dispositivos com um mesmo Master precisam pertencer a uma
mesma piconet [31].
Entre dispositivos Bluetooth existem dois tipos de conexões que podem ser estabelecidas
entre um Master e um Slave: conexões síncronas e assíncronas. Nas conexões assíncronas ou
Asynchronous Connection-Less (ACL), a transmissão é feita a uma cadência não regular,
baseando-se na troca de pacotes, e são as primeiras a serem estabelecidas entre dois
dispositivos. A transmissão de dados é feita por pacotes DH (Data High rate) ou por pacotes DM
(Data Medium rate) que transportam menor quantidade de dados como o próprio nome indica.
A Conexão síncrona ou Synchronous Connection-Oriented (SCO), só pode ser criada a
partir de uma conexão ACL estabelecida anteriormente. Um dispositivo Master pode estabelecer
até 3 conexões SCO para um mesmo Slave, ou diferentes dispositivos Slaves. As Conexões SCO
realizam uma transmissão regular de dados a uma taxa constante e igual para ambos os
sentidos. As conexões SCO foram projectadas para a transmissão de áudio e estabelece um
canal bidireccional e simétrico de 64 kbps. Isto corresponde a um canal de áudio digital com
taxa de amostragem fixa em 8 kHz e resolução de 8 bits. O protocolo Bluetooth permite até 3
conexões síncronas simultâneas por dispositivo, atingindo uma taxa máxima para transmissão
de voz de 384 kbps.
A tecnologia Bluetooth permite uma taxa máxima de transmissão de 1 Mbps. No
entanto, por causa do overhead gerado pelos diversos protocolos do Bluetooth, a taxa efectiva

Capítulo - 2
máxima de transmissão é de 723,2 kbps. Para conexões Bluetooth assíncronas, as taxas
máximas de transmissão podem ser diferentes para cada sentido do tráfego dos dados,
dependendo do tipo de pacote que utilizam (ver Tabela 6).
Tabela 6: Taxas de transmissão para os pacotes usados em conexões assíncronas (ACL), adaptado de [32].
Tipo do
Pacote
utilizado
Taxa máxima com
Transmissão simétrica
(kbps)
Taxa de transmissão
assimétrica directa
(kbps)
31
Taxa de transmissão
assimétrica inversa
(kbps)
DM1
108,8
108,8
108,8
DH1 172,8 172,8 172,8
DM3 258,1 387,2 54,4
DH3 390,4 585,6 86,4
DM5 286,7 477,8 36,3
DH5 433,9 723,2 57,6
Visando garantir a interoperabilidade de dispositivos Bluetooth de diferentes fabricantes,
o Special Interest Group (SIG) definiu uma pilha (stack) de protocolos para a tecnologia
Bluetooth. A pilha de protocolos provê regras de como os softwares aplicativos devem proceder
para encontrar dispositivos Bluetooth, como devem descobrir os serviços disponíveis e como
utilizar esses serviços. A pilha de protocolos Bluetooth é organizada em diversas camadas, com
níveis crescentes de abstracção. O número de camadas utilizadas em cada aplicação é variável,
e depende do nível lógico de software que se deseja para o dispositivo Bluetooth. Inclusive,
algumas das camadas mais altas da pilha de protocolos são específicas para determinadas
aplicações, como aplicações de telefonia. A pilha de protocolos definida pela especificação
Bluetooth [33], pode ser consultada no anexo 2, juntamente com a descrição da função de cada
camada da pilha.
Considerações operacionais
Nesta Secção, são descritos os aspectos funcionais da tecnologia Bluetooth incorporados
pelo grupo de protocolos de transporte da pilha de protocolos. Todos esses aspectos são
configurados via software, uma vez que os módulos mais recentes já incorporam todo o grupo de
protocolos de transporte nos circuitos integrados. No texto, os termos em inglês observados com

32
Estado da arte e Fundamentos teóricos
maior frequência na especificação Bluetooth serão mantidos, pois ainda não existe padronização
na tradução para português.
A Figura 20 mostra os principais estados operacionais de conexão para dispositivos
Bluetooth. Quando o dispositivo já pertence a uma piconet, o seu estado corresponde a
“conectado”. No estado Stand-By (espera), o dispositivo não pertence a nenhuma piconet, nem
se encontra em processo de formação de uma piconet ou união com uma já existente. O estado
Stand-By é o estado operacional padrão para um dispositivo Bluetooth.
Figura 20: Estados operacionais para dispositivos Bluetooth.
Para dois dispositivos Bluetooth se conectarem, é necessário que estejam dentro da
distância de alcance. Este estabelecimento de conexão passa por duas fases. Primeiramente, o
dispositivo Master entra no modo Inquiry (investigação), onde procura dispositivos visíveis de
uma determinada classe. Para um dispositivo Slave estar visível, é necessário habilitar o modo
Inquiry Scan (procura de dispositivos). Através do Inquiry, o dispositivo mestre obtém uma lista
dos dispositivos da classe especificada de interesse que estão dentro do seu alcance e seus
respectivos endereços. Cada dispositivo Bluetooth possui um endereço de 48 bits único no
mundo. Após escolher com qual dispositivo fará a conexão, o dispositivo Master entra em modo
Paging (convocação). Neste modo, o dispositivo mestre requisita a conexão ao dispositivo
escravo, utilizando para isso o endereço de 48 bits deste dispositivo Slave obtido no modo
Inquiry. O dispositivo Slave pode ser configurado para responder ou não às convocações do
dispositivo Master. Para responder, precisa estar com o modo Page Scan (procura por
convocações) habilitado [34].
Os estados intermediários Inquiry e Page implementam conceitos de “identificabilidade”
e “conectabilidade” para dispositivos Bluetooth. Os dispositivos escravos podem ser
configurados de modo a não responderem às procuras de identificação vindos de dispositivos
em modo Inquiry, tornando-se invisíveis. Os dispositivos Bluetooth também podem ser
configurados de modo a não responderem às solicitações de conexão provenientes de

Capítulo - 2
dispositivos em modo Page. Nestes casos, tais dispositivos não podem receber conexões,
somente iniciá-las. Ainda mais, em ambas as situações de Inquiry e Page, os dispositivos
Bluetooth podem ser configurados para responderem somente aos dispositivos de determinada
classe. Nestas condições, uma conexão não pode ser criada à força por um dispositivo estranho,
nem por um de classe distinta daquela na qual se encontra configurado.
Os dispositivos Bluetooth têm mecanismos para reduzir ao máximo o consumo de
energia, de forma a maximizar a autonomia destes sistemas. Estes mecanismos consistem
basicamente na desactivação do circuito de transmissão de radiofrequência, quando os
dispositivos não estão a transmitir.
Este sistema de aquisição deverá funcionar num ambiente pouco favorável aos sistemas
electrónicos e que pode ser um obstáculo para a comunicação sem fios. Deverá ter-se em conta
o meio de comunicação físico que pode impor adaptações ou novas abordagens relativamente
aos protocolos utilizados, ainda que seja uma questão que está fora do âmbito deste trabalho.
Na próxima secção será descrito todo o desenvolvimento do trabalho realizado ao longo
desta dissertação.
33

3 Desenvolvimento
3.1 Especificação de requisitos
Como já foi referido anteriormente, esta dissertação tem como objectivo monitorizar o
corpo de um atleta na prática de natação, através de vários sensores integrados num fato de
natação. Para fazer a aquisição dos sinais provenientes dos sensores, foi implementada uma
rede Zigbee com módulos da Jennic, equipados com o microcontrolador JN5148. Para fazer
testes relacionados com o desempenho da rede foi ainda desenvolvido um sensor para medir
temperatura timpânica.
Os principais requisitos para este trabalho são os seguintes:
Possibilidade de integração num fato de natação;
Consumo reduzido de energia;
Possibilidade de ligação de vários dispositivos à rede com sensores acoplados;
Miniaturização dos módulos de aquisição de sinal;
Alcance baixo entre os dispositivos de aquisição e o nó central (low power);
Taxas de transmissão de dados de 64 kbps, correspondente a frequências de
amostragem na ordem dos 5 kHz (necessário para sinal de EMG).
Medição dos parâmetros sem prejudicar o desempenho do atleta.
Quanto aos sensores, inicialmente foi pensado um circuito de condicionamento de sinal
para o sensor de temperatura timpânica, com o conjunto sensor/circuito a obter resoluções na
ordem dos 0.2 ºC com medições de temperatura na gama de 35 ºC a 43 ºC.
34

Capítulo - 3
3.2 Estruturação geral do sistema e hardware
3.2.1 Estrutura geral
O sistema geral é constituído por um dispositivo coordenador (nó controlador) e vários
dispositivo finais (nós sensores) que constituem a rede Zigbee, à qual está ligado o sistema de
aquisição de sinal e a aplicação gráfica. O sistema de aquisição de sinal é composto por um
sensor de temperatura timpânica acoplado do circuito de condicionamento de sinal que por sua
vez se liga ao respectivo dispositivo final da rede Zigbee/802.15.4. A aplicação gráfica que é
executada num computador está ligada via UART-USB ao coordenador da rede. Este sistema
pode ser mais facilmente entendido com a visualização da
Figura 21.
Figura 21: Sistema Aquisição de sinal/Rede/Aplicação gráfica.
A medição das grandezas físicas, como é o caso da temperatura, é feita pelo sensor que
transmite o sinal ao circuito de condicionamento de sinal para fazer o processamento analógico
onde posteriormente é adquirido pelo ADC (Analog to Digital Converter) do microcontrolador que
constitui o dispositivo final. Os valores analógicos medidos são convertidos para valores digitais e
são processados para serem enviados ao nó central da rede, o coordenador, que por sua vez
envia os dados para o computador para serem vizualizados na aplicação gráfica (Figura 22).
35

Integração no projecto BIOSWIM
Figura 22: Estrutura geral do sistema concebido.
36
Desenvolvimento
O trabalho realizado é apenas uma parte do projecto BIOSWIM, como se pode verificar
na Figura 23. Como foi dito anteriormente neste projecto foram estabelecidos os objectivos de
avaliação de vários parâmetros que serão medidos todos em simultâneo e em tempo real, num
protótipo final do sistema. O número de nós estará dependente do volume de dados adquiridos
por unidade de tempo que exige a grandeza medida. Existem parâmetros que necessitam de
frequências de amostragem baixas e que podem ser adquiridos e processados pelo mesmo
dispositivo final, enquanto parâmetros de grandezas que têm variações mais rápidas no tempo
exigem um dispositivo final exclusivo, para processar e enviar toda a informação adquirida.
Figura 23: Localização do trabalho no projecto BIOSWIM.

Capítulo - 3
Propriedades do sistema de rede
Cada nó sensor terá acoplado um ou mais sensores, que podem ser de tipos diferentes
necessitando de taxas de amostragem que podem ser igualmente diferentes. Por esta razão é
necessária uma gestão equilibrada dos sensores a ligar a cada nó para que sensores de
natureza distinta possam ser adquiridos pelo mesmo nó sensor e enviados ao coordenador e por
sua vez à aplicação gráfica. A seguir será feito um resumo das principais características e
funcionalidades deste sistema de rede.
Funcionalidades do coordenador:
Controlo do número de nós sensores que acedem à rede;
Modos de transmissão High power e Low power;
Fixação das frequências de amostragem dos nós sensores (até um máximo de 10
kAmostras/s);
Comunicação bidireccional com o computador;
Visualização da qualidade do sinal de cada nó sensor;
Funcionalidade de contagem de tramas perdidas/repetidas.
Funcionalidades do nó sensor:
Modos de conversão do ADC: Single shot e Contínuo;
Modos de transmissão High power e Low power;
Dois modos de operação: Modo Sleep e Modo activo.
As propriedades do sistema de rede Zigbee e 802.15.4 são semelhantes, pois as duas
aplicações foram construídas para funcionarem com a mesma aplicação gráfica, e para terem as
mesmas características. No entanto diferem no tamanho das tramas de dados, onde na
aplicação Zigbee são constituídas por 82 bytes e na aplicação 802.15.4 por 98 bytes.
Logicamente que o processamento difere um pouco entre as duas aplicações, pois o modo de
disposição das amostras nas tramas é diferente. Estes temas serão abordados nos próximos
subcapítulos.
37

3.2.2 Hardware de comunicação
38
Desenvolvimento
Para fazer a selecção do hardware de comunicação foram considerados alguns
requisitos importantes para o projecto BIOSWIM. O requisito mais importante é o tamanho dos
módulos de comunicação, visto que serão integrados no fato de natação. Outro requisito é o
consumo de energia, pois como o sistema é alimentado por baterias, e terá que ser autónomo,
não pode ter consumos de energia elevados pois esgotariam rapidamente a energia acumulada
nas baterias. Os módulos de comunicação sem fios deverão ser flexíveis ao nível da
programação, de modo ao sistema poder-se adaptar a várias configurações e aplicações
específicas. Por último, mas não menos importante é o custo dos módulos. Os terminais de rede
sem fios com os protocolos Bluetooth, Zigbee ou 802.15.4 têm preços relativamente baixos. Por
todas estas razões foram escolhidos os módulos de desenvolvimento da Jennic (Figura 24).
Figura 24: Kit de desenvolvimento de redes de comunicação sem fios da Jennic.
Este kit de desenvolvimento tem algumas vantagens para este tipo de aplicações. Foi
desenvolvido para iniciantes à programação de redes sem fios, e admitem diferentes protocolos,
tendo algumas application notes desenvolvidas. Os módulos de desenvolvimento têm o
microcontrolador JN5148 da Jennic, que possui algumas características essenciais para o
desenvolvimento deste projecto. Na Figura 25 está representada a arquitectura do
microcontrolador destes módulos de desenvolvimento, em diagrama de blocos.

Capítulo - 3
Figura 25: Arquitectura do microcontrolador JN5148 da Jennic.
O kit de desenvolvimento é composto por cinco placas construídas pela Jennic que
possibilitam várias funções como a alimentação do microcontrolador, carregamento de firmware
ou teste das aplications notes. Nessas placas podem-se conectar os módulos de
desenvolvimento que são constituídos pelo módulo de comunicação transmissor/receptor rádio
e pelo microcontrolador JN5148 que está integrado na placa PCB (Printed Circuit Board) e tem
um cristal externo. Existem dois tipos de módulos: High Power e Low Power. Os módulos Low
Power podem ter uma antena com conector SMA (SubMiniature version A), ou ter a antena
integrada directamente na placa PCB. Na Figura 26 pode ver-se os dois tipos de módulos, e a
diferença entre os módulos Low Power com e sem conector SMA.
Figura 26: Módulos de desenvolvimento da Jennic.
39

Ambiente de desenvolvimento e Debugger
40
Desenvolvimento
Os módulos de desenvolvimento da Jennic utilizam o ambiente de desenvolvimento
Eclipse. Esta plataforma multi-linguagem de programação inclui um ambiente de
desenvolvimento integrado (IDE) e um sistema extensível plug-in. Foi desenvolvido
principalmente em Java e permite desenvolver aplicações em diversas linguagens de
programação: Java, C/C++, COBOL ou PHP [35].
O debug destes módulos de desenvolvimento pode ser feito por hardware, através de
uma interface de hardware JTAG (Join Test Action Group), ou pelo hyperterminal do Windows. O
debug por hardware consiste em conectar a interface JTAG ao computador através da porta série
e ao dispositivo da Jennic. É descarregado um pequeno programa de comunicação para o
dispositivo que depois envia a informação de debug (variáveis/referências temporais na
execução do algoritmo) para o computador. O debug por software consiste em enviar a
informação de debug pela porta UART do dispositivo, para serem visualizados no hyperterminal
do sistema operativo Windows (Figura 27).
Características gerais
Figura 27: Debug por software através do hyperterminal do Windows.
As características principais dos módulos de desenvolvimento da Jennic são
enumeradas na Tabela 7.

Capítulo - 3
Tabela 7: Características principais do microcontrolador JN5148 da Jennic.
Transmissor
• 2.4GHz IEEE802.15.4 compliant
• Time of Flight ranging engine
• 128-bit AES security processor
• MAC accelerator with packet formatting,
CRCs, address check, auto-acks, timers
• 500 & 667kbps data rate modes
• Integrated sleep oscillator for low power
• On chip power regulation for 2.0V
to 3.6V battery operation
• Deep sleep current 100nA
• Sleep current with active sleep timer
1.25μA
• Rx current 17.5mA
• Tx current 15.0mA
• Receiver sensitivity -95dBm
• Transmit power 2.5dBm
Para desenvolver a rede de comunicação sem fios, foram considerados dois protocolos
diferentes de modo a poderem comparar-se as performances de comunicação: o Bluetooth e o
Zigbee. O protocolo Zigbee tem uma excelente relação taxa de transmissão de dados, consumo
de energia, o que levou em conjunto com as características dos módulos de desenvolvimento, à
escolha deste protocolo para a aplicação. Mais tarde, com o objectivo de melhorar o
desempenho da rede criada com este protocolo, foi implementada outra solução com o
protocolo 802.15.4. Como já foi referido anteriormente neste documento, o 802.15.4 é a base
do Zigbee, diferindo basicamente nas últimas camadas do modelo OSI, onde o Zigbee
acrescenta camadas de rede e de aplicação. Em termos práticos, na comunicação com o
protocolo 802.15.4 as tramas têm um overhead menor que no Zigbee e o tamanho máximo do
Payload é maior. Na próxima secção será descrito o conteúdo deste desenvolvimento.
3.3 Implementação com protocolo Zigbee
Os módulos de desenvolvimento da Jennic foram construídos para aplicações com o
protocolo Zigbee. Para dar suporte às aplicações o software foi construído para que se possam
interligar os vários módulos especificados no modelo OSI e os módulos próprios da Jennic. No
41
Microcontrolador
• Low power 32-bit RISC CPU, 4 to 32MHz clock speed
• Variable instruction width for high coding efficiency
• Multi-stage instruction pipeline
• 128kB ROM and 128kB RAM for bootloaded program
code & data
• JTAG debug interface
• 4-input 12-bit ADC, 2 12-bit DACs, 2 comparators
• 3 application timer/counters,
• 2 UARTs
• SPI port with 5 selects
• 2-wire serial interface
• 4-wire digital audio interface
• Watchdog timer
• Low power pulse counters
• Up to 21 DIO

42
Desenvolvimento
próximo subcapítulo é apresentada a arquitectura da rede de sensores sem fios, com uma breve
explicação sobre toda a dinâmica da construção da rede Zigbee.
3.3.1 Arquitectura da rede de sensores sem fios
A aplicação feita pelo programador encontra-se na camada de aplicação do software
Zigbee PRO da Jennic. Essa aplicação inicia outros módulos como o Jennic Operating System
(JenOS), o Zigbee PRO Stack (ZPS) ou os periféricos integrados, através das Aplication Program
Interfaces (APIs) disponibilizadas pela Jennic (Figura 28).
Figura 28: Arquitectura do software Zigbee PRO da Jennic, adaptado de [36].
O software Zigbee PRO da Jennic permite a construção de um sistema dinâmico multi-
tarefa, onde várias funções são executadas em “simultâneo”, por via de eventos que vão
surgindo ao longo do processo e comandam a maioria das funções e tarefas. Todo este processo
tem início quando o sistema JenOS inicia o módulo Real-Time Operating System (RTOS) onde se
criam as tarefas, eventos, interrupções ou timers (Figura 29).
Figura 29: Dinâmica do software Zigbee PRO da Jennic.

Capítulo - 3
O RTOS quando é executado inicia um processo de ocorrência de eventos, que podem
invocar as tarefas, interrupções ou comunicações entre tarefas criadas. Como se pode verificar
no exemplo da Figura 29, as mensagens 1 e 2 vindas do Zigbee PRO Stack (ZPS) activam as
tarefas 1 e 3 respectivamente. A tarefa 3 pode também ser activada pelo timer 2, enquanto o
timer 1 é iniciado na tarefa 1. A tarefa 2 é activada por software na tarefa 3. As funções envio,
recepção e tratamento de dados podem ser construídas dentro destas tarefas, ou podem ser
independentes, tendo neste caso que serem executadas por software.
O JenOS inicia também outros módulos relacionados com a comunicação Zigbee que
estão representados na Figura 28, como o Protocol Data Unit Manager (PDUM) que faz a gestão
dos pacotes de mensagens, ou o Persistent Data Manager (PDM) que trata do armazenamento
de dados da aplicação Zigbee em memória não-volátil. Os periféricos integrados como ADCs,
DACs, UARTS ou Timers são também acedidos pela camada de aplicação através das
respectivas aplicações de interface (API’s).
O algoritmo que relaciona os vários módulos representados na Figura 28 pode ser
construído no editor JenOS Configuration Editor, enquanto os parâmetros de rede, como tempos
relacionados com a transmissão e outros parâmetros importantes para a comunicação, são
configurados no ZPSconfig.
Perfil da Rede Zigbee e características
A rede Zigbee implementada tem uma topologia de rede em estrela, com o coordenador
de rede a assumir um papel central e de comunicação directa com todos os dispositivos finais.
Toda a informação em circulação na rede passa pelo nó coordenador.
Figura 30: Topologia de rede em estrela.
43

44
Desenvolvimento
Algumas das escolhas seguintes foram tomadas, com o objectivo de aumentar a taxa de
transmissão de dados entre os nós sensores e o nó controlador, como manter os nós sensores
sempre em modo activo, estando esta característica directamente ligada ao modo de operação
de rede, non-beacon, que não permite que o nó sensor entre em modo sleep. O envio de
acknowledgements é opcional, e pelo mesmo motivo citado em cima, optou-se por não enviar
acknowledgements, pois o seu envio atrasa um pouco as velocidades de transmissão de dados.
Todas as outras características, como o método de acesso à rede, procura de rede ou método
de retransmissão de trama, são comuns a todas as aplicações Zigbee.
Estruturação Geral
Como foi dito anteriormente, o software Zigbee PRO stack da Jennic permite a
configuração de parâmetros de rede no ZPSconfig e a configuração do sistema operativo no
JenOS configuration editor. A seguir é feito um resumo dos parâmetros configurados no
ZPSconfig e os principais blocos do algoritmo construído para o JenOS, para se obter uma
melhor compreensão do funcionamento da rede Zigbee.
A configuração do ZPS, permite ajustar os parâmetros de rede de acordo com a
aplicação que se quer construir. Neste caso optou-se por um tamanho do pacote de dados da
camada de aplicação (APDU - application protocol data unit) de 82 bytes para as tramas de
dados dos sensores e 10 bytes para as tramas de comandos. Foram activados os canais de 11
a 26 para o dispositivo final e o canal 13 para o coordenador. O número de pacotes de dados
da camada de rede do protocolo Zigbee (NPDUs - Network Protocol Data Unit) é também
importante, uma vez que a trama de dados construída na aplicação vai ser dividida nesta
quantidade de pacotes para ser enviada ao coordenador, o que influencia a velocidade de
transmissão. São também configurados alguns tempos, como o tempo entre o envio das frames
(3 ms), e parâmetros relacionados com a gestão da rede, como o número de falhas antes de
um dispositivo final se juntar novamente à rede (5 falhas). Estas configurações podem ser vistas
em maior pormenor no anexo 3.
Na Tabela 8 estão os principais elementos da configuração do RTOS do sistema
operativo Jennic. Nas Figuras 35 e 39 pode-se encontrar o diagrama desta configuração para
cada um dos dispositivos.

Capítulo - 3
Tarefas (Tasks):
Timers:
Tabela 8: Configuração do RTOS do sistema operativo JenOS
Coordenador Dispositivo final
o APP_taskControllerNode;
o APP_taskLogData;
o APP_taskComandControl;
o APP_tmrLogData;
Mensagens entre tarefas:
o APP_msgSensorEvent;
o APP_msgComandEvent;
o APP_msgZPSEvent;
Interrupções;
Callbacks;
45
Tarefas (Tasks):
Timers:
o APP_taskSensorNode;
o APP_taskSampleSensors;
o APP_taskAmostragem;
o APP_taskFreqAmostControl;
o APP_tmrAmostragem;
o APP_tmrRestart;
Mensagens entre tarefas:
o APP_msgComandEvent;
o APP_msgZPSEvent;
Interrupções;
Callbacks;
Foram implementadas todas estas funções no sistema operativo JenOS que serão
explicadas em pormenor na secção seguinte. O diagrama de blocos de todas estas funções
encontra-se no Anexo 3 e 4 para o coordenador e dispositivo final respectivamente. É importante
referir que as interrupções, callbacks e mensagens inter-tarefas provenientes de eventos da pilha
Zigbee, estão previamente implementadas no Template fornecido pelo fabricante dos módulos
de experimentação, em ambos os dispositivos de rede coordenador e dispositivo final, e são
comuns à maioria das aplicações Zigbee, pelo que já se encontravam desenvolvidas.
3.3.2 Estrutura do Firmware
Antes de ser explicada a estrutura do firmware, e como os eventos, tarefas e funções se
relacionam entre si, será feita uma breve explicação sobre o funcionamento geral de todo o
sistema da rede Zigbee desenvolvida, em termos mais práticos.

Geral
Figura 31: Funcionamento geral da aplicação implementada com o protocolo Zigbee.
46
Desenvolvimento
O sistema contém como já foi citado anteriormente, dois dispositivos de rede, o
coordenador e o dispositivo final, sendo a rede sem fios constituída por um só coordenador (nó
controlador) e vários dispositivos finais (nós sensores). Nestes dispositivos finais, pretende-se
que o firmware seja geral e igual para todos, sem prejuízo de poderem posteriormente ser
introduzidas alterações de acordo com as necessidades e características dos sensores a eles
ligados.
Uma vez iniciados os dispositivos, estes executam processos de rede para criação da
rede Zigbee e estabelecimento da conexão, e que serão explicados na próxima secção. Depois
da criação da ligação entre os dispositivos começa a transferência de dados, que flui
principalmente dos dispositivos finais para o coordenador. O coordenador apenas envia
comandos aos dispositivos finais.
Nos dispositivos finais, o sinal do sensor é convertido pelo ADC num sinal digital à
frequência desejada pelo utilizador. A frequência é determinada por um timer que activa a tarefa
de aquisição de amostras “APP_taskAmostragem”. As amostras vão sendo adquiridas
sucessivamente e guardadas num array enquanto o sistema está no modo “Monitorização”.
Quando o array é totalmente preenchido é construída a trama e enviada ao coordenador. As
tramas contêm o Node ID, que identifica o dispositivo final que enviou, e o número de trama
para controlar as tramas perdidas e repetidas.

Capítulo - 3
O coordenador recebe as tramas e a zigbee stack activa automaticamente a tarefa
“APP_taskLogData” que processa a trama recebida. A trama recebida é processada,
implementando-se funções relacionadas com a disposição das amostras na trama, que serão
explicadas mais tarde. Depois deste processamento é implementada a técnica de sincronização
de dados Bit stuffing que também será explicada na secção seguinte. Uma vez terminado todo o
processamento, o array que contém os dados da trama recebida é enviado pela UART ao
computador para depois serem também processados e apresentados os sinais através da
aplicação gráfica.
Depois de enviar os dados ao computador, o coordenador verifica se recebeu algum
comando da aplicação gráfica. Em caso afirmativo, irá processá-lo e enviá-lo ao dispositivo final a
que se destina. Terminado o envio do comando, ou de imediato, caso não haja comandos a
enviar, o coordenador fica a aguardar por mais dados em modo “E_Network_Screen”. O
coordenador repete este ciclo de cada vez que recebe uma trama de dados, verificando se
recebeu comandos mesmo que não tenha recebido tramas dos nós sensores.
Os comandos enviados pelo PC ao coordenador podem ser:
Start : para iniciar a aquisição de dados num dispositivo final;
Stop : para parar a aquisição e envio de sinais do dispositivo final;
Set Frequency : para mudar a frequência de aquisição do ADC.
As tramas enviadas entre os dispositivos têm tamanhos pré-definidos e estão
representadas na Figura 32. A trama de dados é constituída pelo Node ID, número de trama e
pelos dados dos sensores. A trama de comandos é composta pelo tipo de comando, Node ID e o
divisor para frequência de amostragem.
Figura 32: Trama de dados e trama de comandos.
Este Node ID serve para identificar o nó sensor que envia a trama, tanto no coordenador
como na aplicação gráfica. O número de trama serve para identificar a trama na sequência de
47

48
Desenvolvimento
tramas transmitidas. Na trama de comandos o tipo de comando identifica o comando que foi
recebido e o divisor indica ao dispositivo final o valor da frequência de amostragem. Estes
parâmetros serão novamente abordados na secção seguinte.
Registo dos nós sensores
Os nós sensores são registados no coordenador da primeira vez que enviam uma trama
de dados. Quando o coordenador recebe uma trama, este lê o endereço de rede do nó sensor e
verifica na estrutura que guarda o Node ID e respectivo endereço de rede se este já está
registado (função APP_u8EnviaSensorNodeID). Se não estiver regista-o prosseguindo com a
transmissão, se já tiver sido registado então continua a transmissão de tramas normalmente.
Este Node ID é fixo e é definido no firmware dos nós sensores
Esta aplicação implementada com o protocolo Zigbee é bastante dinâmica e minuciosa,
pelo que será mais aprofundada nos capítulos seguintes.
Pilha Zigbee
Até o nó controlador estar preparado para receber dados dos nós sensores, passa por
alguns estados necessários para criar a rede Zigbee. O mesmo acontece com o nó sensor que
procura a rede formada para iniciar a comunicação. Na Figura 33 estão representados esses
estados, que todos os nós sensores executam, dependendo do dispositivo de rede.
Figura 33: Estados do Nó controlador e Nó sensor na gestão da rede Zigbee.
O nó controlador inicia a criação da rede, passando a configurar os parâmetros de rede.
Depois disso a rede é formada e fica em modo de espera até que algum nó sensor lhe envie um
request para se juntar à rede. O nó sensor inicia o processo de procura de redes existentes.

Capítulo - 3
Depois de encontrada a rede, estabelece contacto para se juntar e começar a monitorizar os
sensores e a enviar dados ao coordenador.
Arquitectura da aplicação do Nó Controlador (coordenador)
Como foi explicado anteriormente, para construir o firmware é necessário criar o
algoritmo para o RTOS do sistema operativo JenOS. Neste algoritmo é preciso definir os eventos
que irão desencadear mensagens, que por sua vez irão activar as tarefas de leitura, envio e
processamento de dados. Na Figura 34 pode-se visualizar a dinâmica dos eventos
implementados e as tarefas que activam, para o dispositivo coordenador.
Figura 34: Arquitectura da aplicação do Coordenador.
Como se pode verificar na Figura 34, a arquitectura do firmware do coordenador é
constituída apenas por tarefas e mensagens. Na camada ZPS, quando ocorre um evento, este dá
origem a uma mensagem que activa a tarefa correspondente. Nessa tarefa é lido o evento que
surgiu e processada a função correspondente.
No caso do coordenador tem-se a mensagem “APP_msgZPSEvent” que activa a tarefa
“APP_taskControllerNode” e indica que a Zigbee Stack recebeu eventos relacionados com a
gestão da rede como por exemplo a indicação que se juntou um novo dispositivo final à rede ou
que a mensagem Zigbee foi enviada com sucesso. A mensagem “APP_msgSensorEvent” activa
a tarefa “APP_taskLogData”, e surge quando o coordenador recebe uma trama de um
dispositivo final.
Na Figura 35 encontra-se a configuração no JenOS Configuration Editor do sistema
operativo JenOS do coordenador. Nesta imagem pode-se visualizar a duas tarefas (azul)
descritas no parágrafo anterior e as respectivas mensagens (verde) que as activam. Os restantes
blocos da área cinzenta denominada de ZBPro e as callbacks têm funções de gestão da rede e
49

50
Desenvolvimento
como já foi dito em cima, estão previamente implementadas no Template fornecido pelo
fabricante dos módulos de comunicação e são usadas para construir as aplicações.

Figura 35: Configuração pormenorizada do RTOS do sistema operativo JenOS do coordenador.
51

52
Desenvolvimento
De seguida serão explicados os algoritmos do firmware do coordenador e posteriormente será
feita uma descrição das funções e tarefas que integram o firmware.
Na Figura 36 e Figura 37 pode-se ver o algoritmo geral do firmware. Este algoritmo divide-se em
diferentes fluxogramas sem ligação entre si porque como foi explicado em cima, quando o
sistema inicia o módulo de RTOS, este executa um sistema multitarefa, em que algumas tarefas
são activadas automaticamente pelos eventos recebidos pelo dispositivo, ou por software, e
enquanto o sistema executa uma determinada função pode ser executada uma outra enquanto a
primeira permanece em stand-by.
Algoritmia
O algoritmo do sistema começa no fluxograma A da Figura 36, o coordenador inicia o
módulo de RTOS, sistema multitarefa em que podem ser executadas várias tarefas em
“simultâneo”. Depois de iniciar o RTOS, executa um ciclo infinito até ocorrerem eventos. Quando
o se inicia o RTOS, este activa a tarefa “APP_taskControllerNode” que cria a rede, depois é
configurada a UART para enviar dados ao PC e o dispositivo permanece em modo
“E_Network_Screen” para a recepção dos dados.
Figura 36: Fluxograma do programa principal do firmware do coordenador (formação da rede Zigbee).
Depois da rede criada, quando o dispositivo recebe tramas, estas activam a tarefa
“APP_taskLogData” (Figura 37). Esta tarefa implementa o coordenador da rede que recebe
tramas de dados contendo os dados das medidas dos sensores provenientes dos dispositivos

Capítulo - 3
finais. Quando um dispositivo final envia a primeira trama de dados ao controlador, é registado o
seu endereço de rede (MAC adress) e o seu Node ID, que é um valor de 0 a 255 para identificar
o nó sensor nesta aplicação. Depois do registo efectuado os nós sensores podem começar a
enviar mais tramas de dados, que serão guardadas num array no nó controlador. Ocorrem
depois dois processos:
um para disposição das amostras dos sensores na trama de envio ao computador;
(função “Enc2_3”, ver explicação na Tabela 9);
um segundo para efeitos de sincronização da transferência de dados entre o
coordenador e o computador (função “Bitstuffing”, ver explicação na pág. 65).
A trama resultante é então enviada ao computador e verifica-se se foi recebida alguma
trama de comandos na UART, por parte do computador. A função de leitura da porta UART
contém uma flag que indica se o coordenador recebeu tramas de comandos, mesmo que os nós
sensores não estejam a transmitir dados, o coordenador pode receber comandos e enviá-los aos
nós sensores. Caso o nó controlador tenha recebido uma trama de comandos, esta é
processada, verificando-se o Node ID que ela contém e enviando-a ao dispositivo final
correspondente.
53

Figura 37: Fluxogramas do programa principal do firmware do coordenador (recepção de dados).
54
Desenvolvimento
Para executar os blocos representados no algoritmo, o firmware é constituído por tarefas
e funções. Algumas destas funções fazem parte de uma tarefa e só são executadas quando a
tarefa é activada. A seguir são explicadas de uma forma geral, as funcionalidades principais de
cada tarefa e cada função.
Tabela 9: Descrição das funções do firmware do Nó Controlador no protocolo Zigbee (continua na página seguinte).
Tipo de função Funções
Configuração e
iniciação
Processamento de
tramas
APP_vLogInitialise
uart_config(*)
Desm4_3
Descrição
Inicializa o contador de dispositivos finais na
rede e invoca a função uart_config.
Configura a UART com um baudrate de
115200 bps, sem paridade e com 1 stop bit
para o envio de dados ao computador.
Faz a extracção das amostras do sinal do
sensor. As amostras são de 12 bits, no entanto
a trama recebida é um array de 16 bits em
cada posição. As amostras são enviadas na
trama justapostas de forma a que, cada 3
posições transporta 4 amostras de 12 bits.
(4 amostras x12 = 48 bits)
(3 posições x16 = 48 bits)

Capítulo - 3
Sincronização
Comunicação
UART
Registo
Comandos
Enc2_3
Bitstuffing(*)
55
Coloca as amostras de 12 bits num array de 8
bits em cada posição (ao contrário da função
anterior em que o array tinha 16 bits em cada
posição). Sendo assim cada 3 posições do
array transporta 2 amostras de 12 bits.
(2 amostras x 12 = 24 bits)
(3 posições x 8 = 24 bits)
Implementa a técnica de sincronização de
dados Bit stuffing (ver pág. 65).
BytetobitArray(*) Converte um array de bytes num array de bits.
bittoByteArray(*) Converte um array de bits num array de bytes.
envia_uart(*)
recebe_uart(*)
ZipComand
APP_u8EnviaSensorNodeID
APP_u8SensorNodePosition
APP_u8EnviaSensorNodeADDR
EnviaFreqAmost
(*) Funções que são utilizadas também na aplicação com protocolo 802.15.4.
Arquitectura da aplicação do Nó Sensor (dispositivo final)
Envia o array de dados ao computador via
porta UART. O número de envios é igual ao
número de bytes constituintes do array.
Recebe uma trama-comando do computador
na porta UART e extrai os dados dessa trama.
Extrai o tipo de comando, o Node ID e se for
uma trama do tipo “SetFrequency” extrai o
divisor para implementar a frequência de
amostragem do ADC do nó sensor (a ser
explicado mais tarde).
Constrói o valor do endereço de rede do nó
sensor destino e o divisor. Compacta os dados
num array para enviar a trama-comando ao nó
sensor.
Retorna o Node ID de um determinado
endereço de rede de um nó sensor registado.
Retorna a posição do array de registo dos nós
sensores na qual está registado determinado
nó sensor.
Retorna o endereço de rede de um
determinado Node ID de um nó sensor. Se o
nó sensor não estiver registado retorna
“NOT_FOUND”.
Envia a trama de comandos ao nó sensor
correspondente.
Tal como o coordenador, o dispositivo final também implementa no seu firmware um
sistema operativo em tempo real em que surgem tarefas, eventos e mensagens, mas acrescenta
um novo elemento, os timers (Figura 38). Um timer pode tal como um evento, activar uma
determinada tarefa, bastando para isso ser configurado no RTOS do sistema operativo da Jennic.

Figura 38: Arquitectura da aplicação do Dispositivo Final.
56
Desenvolvimento
Neste dispositivo a mensagem “APP_msgZPSEvent” que activa a tarefa
“APP_taskSensorNode” tem exactamente a mesma função que no dispositivo coordenador, ou
seja transmitir eventos relacionados com a gestão da rede. Esta tarefa pode ser activada pelo
timer “APP_tmrRestart” quando o dispositivo final inicia a procura de rede e não a encontra.
Nesse caso então este timer reinicia a procura de rede passados 20 segundos após o início da
procura.
A tarefa “APP_taskSensorNode” inicia também o timer “APP_tmrAmostragem”, que por
sua vez activa a tarefa “APP_taskAmostragem”. Esta procede a uma conversão A/D, sendo
então a frequência de amostragem do nó sensor determinada pela cadência de activação de
“APP_taskAmostragem” por parte do timer “APP_tmrAmostragem”. O timer é configurado para
a frequência desejada pelo utilizador da aplicação gráfica no computador para fazer a aquisição
de amostras do sensor.
A tarefa “APP_taskSampleSensors” é activada pela “APP_taskSensorNode” quando o
dispositivo entra em modo “E_MONITOR_SENSORS” ou seja quando se inicia o processo de
aquisição de sinal do sensor. A mensagem “APP_msgComandEvent” activa a tarefa
“APP_taskFreqAmostControl” quando o nó sensor recebe uma trama de comandos do nó
controlador.
Na Figura 39 encontra-se a configuração feita no JenOS Configuration Editor do sistema
operativo JenOS do dispositivo final. Nesta imagem pode-se visualizar as quatro tarefas (azul)
descritas no parágrafo anterior e as respectivas mensagens (verde) que as activam. Tem
também os timers que podem activar as tarefas “APP_taskSensorNode” e
“APP_taskAmostragem”. Tal como no coordenador, os restantes blocos da área cinzenta

Capítulo - 3
denominada de ZBPro e as callbacks têm funções de gestão da rede e estão já estão
previamente implementadas.
57

Figura 39: Configuração pormenorizada do RTOS do sistema operativo JenOS do dispositivo final.
58

Capítulo - 3
Algoritmo
Quando o se inicia o RTOS, este activa a tarefa “APP_taskSensorNode” que inicia a
procura de rede, configura o ADC para a aquisição de amostras dos sensores e inicia o timer
“App_tmrAmostragem” para iniciar a aquisição. Neste momento o dispositivo encontra-se no
modo “E_MONITOR_SENSORS”. Neste modo é activada a tarefa “APP_taskSampleSensors”
sempre que se iniciar a construção de uma trama de amostras para enviar ao nó controlador.
Figura 40: Fluxograma do programa principal do firmware do dispositivo final (procura de rede Zigbee).
Depois de activada a tarefa “APP_taskSampleSensors” esta executa o algoritmo do
fluxograma A da Figura 41, onde se verifica se o array que contém as amostras adquiridas pelo
ADC contém 52 amostras. Se ainda não tiver as 52 amostras continua a aquisição, se já tiver
inicia a construção da trama e envia ao nó controlador.
Aquando do inicio do modo de monitorização de sensores é activado o timer que controla a
amostragem. O “App_tmrAmostragem” activa a tarefa “App_taskAmostragem”, que faz a
aquisição da amostra, guarda no array mencionado acima e incrementa a variável de controlo de
posição no array (Figura 41-B). Esta tarefa é repetida sempre que o timer expira, pois tem
prioridade sobre qualquer uma das outras tarefas, para se garantir a frequência de amostragem
desejada. A qualquer momento deste processo todo, a tarefa “APP_taskFreqAmostControl” pode
ser activada automaticamente, bastando para isso o nó sensor receber uma trama de comando
do nó controlador. Neste caso o dispositivo extrai os dados da trama de comandos, calcula o
59

60
Desenvolvimento
novo valor da frequência de amostragem pedida e actualiza o timer para esse valor (Figura 41-
C).
Figura 41: Fluxogramas do programa principal do firmware do dispositivo final (Aquisição e envio de dados).
Algumas das funções que constituem este sistema da aplicação do nó sensor pertencem
a tarefas, outras são independentes e são executadas por si só. Na Tabela 10 está feita uma
descrição geral de cada função, podendo ficar-se com uma melhor noção do como foram
organizadas todas as funcionalidades pretendidas para este sistema.
Tabela 10: Descrição das funções do firmware do Nó Sensor no protocolo Zigbee.
Tipo de função Funções
Configuração e
iniciação
Processamento
de tramas
Sincronização
adc_config
vSendSensorData
stop
Descrição
Configura o ADC para o ADC1 em modo
de amostragem contínua e com uma
tensão de referência interna.
(2xVRef = 2.2v)
Envia a trama de dados ao Nó
Controlador.
Implementa o comando “Stop” no Nó
Sensor. Pára o ADC e envia uma trama de
controlo de 4 em 4s para poder
posteriormente ser ligado pelo comando
“Start”.

Capítulo - 3
3.3.3 Aquisição de sinal e preparação para a transmissão
Para fazer a aquisição de amostras, o timer é configurado inicialmente no RTOS do
JenOS. O valor estipulado para o timer para o início da aquisição é de 20 ms que corresponde a
uma frequência de amostragem de 50 Hz. O ADC é também configurado, e pode operar em
diferentes modos.
Modo single shot: De cada vez que é pedida uma amostra é iniciado o ADC, este faz
uma só conversão e pára.
Modo contínuo: Quando é activado o ADC, este faz conversões sucessivas à frequência
configurada na função “adc_config”, quando o timer que controla a frequência à qual se
lêem as amostras, expira é recolhida e guardada a amostra do ADC. Note-se que existe a
frequência de conversão configurada directamente no ADC, e a frequência de
amostragem desejada pelo utilizador, e que é controlado pelo timer. Neste modo o ADC
está a sobreamostrar e a deitar fora as amostras que não são recolhidas. Desta forma a
frequência de conversão do ADC terá que ser sempre superior à frequência de
amostragem desejada pelo utilizador, caso contrário haverá repetição de amostras.
O firmware permite estes dois modos de operação do ADC. O modo utilizado foi o modo
contínuo porque foi o que apresentou melhor desempenho nos testes efectuados à velocidade de
aquisição de amostras.
Depois do array de amostras estar totalmente preenchido (52 amostras de 12 bits), é
tempo de construir a trama a enviar ao nó controlador. O software Zigbee PRO da Jennic
permitem enviar um array de cada vez, mas este deverá ter 16 bits em cada posição e no
máximo 41 posições, ou seja 82 bytes. Como a resolução do ADC são 12 bits, optou-se por fazer
algum processamento para “aproveitar” toda a trama. Este processamento consiste em colocar
amostras de 12 bits num array com 16 bits em cada posição. Como se pode ver na Figura 42,
existe o array onde são guardadas as amostras adquiridas pelo ADC e o array Payload que é
enviado ao nó controlador. Cada 4 amostras de 12 bits são colocadas em 3 posições do array
Payload da forma que se pode ver na figura. Assim um total de 52 amostras cabe em 39
posições do array Payload (função 1).
61

Figura 42: Construção das tramas no Nó sensor (protocolo Zigbee).
62
Desenvolvimento
Depois deste processamento, à trama a enviar são acrescentados mais 2 dados de 16
bits cada que completam a trama de 41 posições correspondendo a 82 bytes. Os dados são o
Node ID e o número de trama (Figura 43). O Node ID é um valor de 0 a 255 previamente
registado e associado ao tipo de sensor e tipo de sinal. Neste caso, ao Node ID de valor 1 está
associado o sensor de temperatura timpânica, e esta correspondência é conhecida por todos os
elementos que compõem o sistema (nó sensor, nó controlador e aplicação gráfica). O número de
trama é um valor também entre 0 e 255.
Figura 43: Trama de dados completa (Zigbee).
Para além das tramas de dados existem também as tramas de comando que, tal como
explicado anteriormente, servem para se enviar comandos entre o nó controlador e os nós
sensores (Figura 44). Estas tramas são compostas por 6 bytes, onde 1 byte contém o código de
comando, outro byte contém o Node ID e 4 bytes são reservados para o divisor para mudar a
Frequência de amostragem do ADC.

Capítulo - 3
Figura 44: Trama de comandos completa (Zigbee).
O divisor é calculado na aplicação gráfica, segundo a função 2, sabendo o valor da
frequência do clock do timer (32 kHz) utilizado para controlar a frequência de amostragem.
Os comandos implementados actualmente estão representados na Tabela 11, onde se
pode verificar as suas funcionalidades, tipo e código de comando. De destacar que futuramente
mais comandos podem ser implementados, bastando para isso seguir a mesma estrutura que
os anteriores.
Código de
comando
1
2
3
Tabela 11: Comandos e suas funções.
Tipo de comando Função
Start Inicia o nó sensor para fazer aquisição e envio de dados
Stop Pára o nó sensor.
Set_Freq Envia o divisor para mudar a frequência de amostragem do ADC.
(determinação dos divisores explicada no próximo capítulo)
3.3.4 Processamento no Coordenador e envio para a UART
O coordenador recebe as tramas no formato da trama de dados da Figura 43 e
processa-as para depois implementar a técnica de sincronização de dados Bit stuffing. Este
processamento é necessário porque a aplicação gráfica foi inicialmente implementada para a
63

64
Desenvolvimento
aplicação com o protocolo 802.15.4 e posteriormente o firmware do coordenador da aplicação
com o protocolo Zigbee foi alterado para ser compatível com a mesma aplicação. Esta alteração
consiste em dispor as amostras na trama da forma como a aplicação gráfica está implementada
para as receber, e será descrita no próximo parágrafo.
A extracção dos dados da trama recebida no coordenador, é feita exactamente no
processo inverso ao descrito anteriormente e representado na Figura 42 (função Desm4_3).
Depois deste processo é necessário fazer um processo de disposição de amostras no array em
tudo semelhante ao da secção anterior, mas neste caso tem-se que colocar as amostras de 12
bits num array de 8 bits cada posição (função Enc2_3). Cada 2 amostras de 12 bits são
colocadas em 3 posições do array de dados da forma que se pode verificar na Figura 45. Assim
um total de 52 amostras mais 2 bytes de overhead cabem em 80 posições do array de dados
(função 2).
Figura 45: Encaixe do array de amostras de 12 bits num array de 8 bits.
A técnica Bit stuffing é necessária para haver sincronização de dados entre o
coordenador e a aplicação gráfica, pois quando o coordenador envia as tramas para a porta
série do computador estas ficam guardadas numa pilha, e quando a aplicação gráfica lê os
dados tem que descriminar as tramas pelo início e fim para saber exactamente o seu tamanho.
Se durante a comunicação as tramas não forem totalmente enviadas, sem esta técnica a
aplicação nunca encontraria o início das tramas e ia processá-las de uma forma errada.
No teste da primeira versão do firmware, observou-se que havia perda de sincronização
entre a aplicação gráfica do computador e o coordenador da rede. Isto deveu-se ao facto do

Capítulo - 3
coordenador enviar dados para a porta série do computador, e este ainda não estar disponível
para receber dados. Assim que a aplicação gráfica começava a fazer a aquisição dos dados,
podia não recolher a trama completa e assim não saber qual era o início e fim da trama,
perdendo a sincronização para sempre. Para resolver este problema, foi necessário implementar
uma técnica de sincronização de dados com um caractere que identificasse o início de trama.
Este carácter, para além de ter funções de sincronização, também permite que o software da
aplicação gráfica seja construído para receber tramas de diferentes tamanhos, não necessitando
de terem um tamanho pré-definido. Assim a aplicação só necessita de identificar os inícios das
tramas, e automaticamente calcula o seu tamanho. A técnica implementada foi o Bit stuffing que
permite que as tramas contenham um número arbitrário de bits e permite o envio de tramas por
parte do coordenador, em qualquer fase da comunicação, sem que a aplicação gráfica perca
dados. Para além desta solução outras surgiram, mas que foram abandonadas por motivos de
complexidade ou de desempenho, como o flow control ou o envio de requests ao computador
para começar a comunicação.
Bit Stuffing
Na técnica de Bit stuffing cada trama inicia e termina com um padrão especial,
01111110, designado por flag byte. O receptor é assim capaz de detectar o início da trama. No
entanto, há sempre o perigo de nos dados ocorrer uma sequência de bits igual à do flag byte. É
aqui que entra a técnica de Bit stuffing. Nos dados transmitidos pelo emissor, sempre que se
detecta cinco bits consecutivos a 1, automaticamente se insere (stuffs) um bit 0, mesmo que o
bit seguinte seja um 0. Assim, apenas no início da trama é transmitido o flag byte. O receptor
reconhece assim o início da trama pelo flag byte. No processamento subsequente dos bits
recebidos, quando forem encontrados nos dados cinco bits consecutivos a 1, é retirado
(destuffs) o bit 0 que se segue.
Se os dados a transmitidas contiverem uma sequência correspondente ao flag padrão,
01111110, ela é transmitida como 011111010 mas após destuffing no receptor é guardada
correctamente como 01111110. A técnica de Bit stuffing é completamente transparente para o
nível de rede em ambos os dispositivos (coordenador e computador). Como exemplo, para enviar
a sequência 00101111111011111100000111, ela será transmitida como
0010111110110111110100000111 e recebida como 00101111111011111100000111
65

66
Desenvolvimento
(Figura 46). Com a técnica Bit stuffing, os limites entre duas tramas são conhecidos sem
ambiguidade através da flag padrão.
Figura 46: Implementação do Bit Stuffing numa sequência de bits a enviar.
Assim a trama de dados enviada ao coordenador tem um tamanho dependente do
número de sequências de 5 bits a 1, pois neste caso são acrescentados mais bits. Depois dos
dados passarem por esta técnica são enviados então ao computador pela porta UART do
dispositivo e para a porta USB do computador a um Baudrate de 115,2 kbps. Esta comunicação
entre o nó controlador e o computador é uma comunicação do tipo half-duplex, ou seja há
transferência de dados nos dois sentidos mas não em simultâneo.
Contagem de erros e qualidade do sinal
O dispositivo coordenador da rede tem ainda um mecanismo para contagem de tramas
perdidas e repetidas que pode ser activado directamente no firmware. Este sistema é bastante
útil quando é necessário fazer debug do sistema excluindo a ligação com o PC. Assim pode-se
ter uma percepção do desempenho da rede, ao longo de diferentes taxas de amostragem. O
algoritmo para este sistema encontra-se na Figura 47.

Capítulo - 3
Figura 47: Algoritmo do mecanismo de contagem de tramas perdidas e repetidas.
O firmware tem ainda a possibilidade de guardar os valores de LQI (Link Quality) de cada
trama, que são valores entre 0 e 255 e indicam a qualidade da conexão numa dada
transmissão. Estes valores podem ser analisados posteriormente, podendo tirar-se conclusões
acerca do melhor desempenho da rede.
3.4 Implementação com protocolo 802.15.4
Inicialmente os resultados do desempenho da rede implementada com o protocolo Zigbee
não foram os desejados, tendo-se então optado por implementar uma nova rede com um
protocolo de mais baixo nível, de modo a tentar aumentar as velocidades de transmissão de
dados e diminuir as perdas de tramas. Optou-se por utilizar o protocolo 802.15.4 que é a base
do Zigbee e aproveitar o facto de as tramas poderem ser maiores e da mensagem transmitida
entre os nós, terem um overhead menor.
Esta aplicação para o coordenador e dispositivo final, pelo facto de ter sido construída
depois da implementação da rede Zigbee, apresenta alguns algoritmos e funções iguais ou
semelhantes à anterior, pelo que serão explicadas apenas as diferenças entre as duas
implementações.
67

3.4.1 Arquitectura da rede de sensores sem fios
68
Desenvolvimento
Como o protocolo 802.15.4 é a base do Zigbee, a arquitectura de ambos é semelhante.
Como se pode ver na Figura 48, a camada de aplicação está ligada aos módulos da pilha do
802.15.4, aplication queue, periféricos integrados e elementos da placa de desenvolvimento
através das APIs de cada módulo.
Figura 48: Arquitectura do software 802.15.4 stack da Jennic.
Para esta aplicação, é útil destacar as interfaces MCPS e o MLME da camada MAC da
pilha protocolar 802.15.4. O MLME (MAC Layer Management Entity) é o órgão de gestão da
rede e é usado para todos os comandos da camada MAC. É responsável por tarefas como
autenticação ou associação de nós sensores. A interface MCPS (MAC Common Part Sublayer) é
responsável pelo envio e recepção de dados. Estas duas interfaces têm um papel activo no
funcionamento das aplicações do dispositivo final e coordenador. Nas secções abaixo será
mostrada a estrutura do firmware com os algoritmos e fluxogramas para estes dois dispositivos
de rede.
3.4.2 Estrutura do firmware
O firmware da aplicação com o protocolo 802.15.4 é um pouco diferente da aplicação
do Zigbee, no entanto muitas das funções anteriormente implementadas para essa aplicação
foram utilizadas com o 802.15.4, tendo-se efectuado apenas alguns ajustes. Como

Capítulo - 3
anteriormente, existem duas aplicações distintas para os dois dispositivos: coordenador e
dispositivo final, apesar de terem várias semelhanças.
Coordenador
Depois de iniciado o sistema e o nó controlador, o algoritmo executa um ciclo infinito
para processar as interrupções/eventos que possam ocorrer. Podem ocorrer três tipos de
eventos:
os eventos de rede que são tratados na interface MLME;
os eventos de transmissão de dados que são tratados no MCPS;
as interrupções dos periféricos integrados que são encaminhados para a rotina
de interrupção respectiva (Figura 49). No caso da aplicação do coordenador,
esta não tem periféricos integrados activos.
No início do sistema vão surgir eventos para criar a rede 802.15.4 e associar nós
sensores no MLME. Depois da rede criada, o nó controlador recebe as tramas de dados no
MCPS onde vai processá-las aplicando o Bit Stuffing, e envia o array final para a porta UART,
verificando então se recebeu comandos da aplicação gráfica. Se recebeu comandos então envia
uma Beacon Payload com os dados do comando recebido, ao nó sensor correspondente. A
Beacon Payload serve para o coordenador enviar comandos aos nós sensores e enviar também
outro tipo de informação que possa ser útil no futuro.
69

Figura 49: Fluxograma do programa principal do firmware do Coordenador (802.15.4).
70
Desenvolvimento
As funções utilizadas foram maioritariamente implementadas na aplicação anterior e
estão representadas na Tabela 12.
Tabela 12: Descrição das funções do firmware do Nó Controlador no protocolo 802.15.4.
Tipo de função Funções Descrição
(Vários)
Processamento de
tramas
Comandos
bittoByteArray
BytetobitArray
Bitstuffing
envia_uart
recebe_uart
uart_config
vProcessIncomingData
(Funções implementadas na aplicação Zigbee e
explicadas na Tabela 9)
Função principal da aplicação. Recebe e processa as
tramas recebidas, enviando depois para a UART e
verifica se recebeu comandos da aplicação gráfica.
vStartBeacon Configura e inicia a Beacon Payload.
vUpdateBeaconPayload
Actualiza a Beacon Payload a enviar ao respectivo nó
sensor depois de receber um comando da aplicação
gráfica.

Capítulo - 3
Dispositivo Final
O dispositivo final tem um funcionamento um pouco diferente do coordenador, pois
contém uma máquina de estados por trás que coordena toda a aplicação (Figura 50). Esta
começa no estado “E_STATE_OFF” e quando o dispositivo é iniciado vai progressivamente
transitando entre os outros estados.
Figura 50: Máquina de estados do dispositivo final.
O dispositivo inicia a procura de rede que depois de encontrada, tal como o nó
controlador, executa um ciclo infinito para processar as interrupções/eventos. Inicialmente
executa as funções de rede no MLME para estabelecer conexão com nó sensores. Para a
aquisição de dados é configurado um timer e o ADC aquando da inicialização do sistema. O
timer, tal como na aplicação Zigbee, controla a frequência de amostragem para a aquisição do
ADC. Quando expira gera uma interrupção que é imediatamente atendida e executada numa ISR
onde se faz a aquisição e armazenamento da amostra num array. Este ciclo é repetido até que o
array esteja completo, com um número de amostras estabelecido previamente, instante em que
é processado e enviado ao nó controlador (Figura 51). Neste ciclo o dispositivo transita entre os
estados “E_STATE_RUNNING”, “E_STATE_TX_DATA” e “E_STATE_READ_SENSORS” e
“E_STATE_RUNNING”.
71

Figura 51: Fluxograma do programa principal do firmware do dispositivo final (802.15.4).
72
Desenvolvimento
Quando o nó sensor recebe um comando do coordenador, processa-o de forma muito
semelhante à aplicação Zigbee. O resto das funções implementadas onde o processamento é
um pouco diferente da aplicação Zigbee está descrito na Tabela 13.

Capítulo - 3
Tabela 13: Descrição das funções do firmware do Nó sensor no protocolo 802.15.4.
Tipo de função Funções Descrição
(Vários)
Configuração
Processamento de
tramas
adc_config
stop
tmr_config
TimerAmostADC
vProcessTxBlock
Comandos vProcessRxBeacon
73
(Funções implementadas na aplicação Zigbee e
explicadas na Tabela 10).
Configura o timer para controlar a frequência de
amostragem.
Faz a aquisição de amostras do ADC e processa o
array quando este estiver completo.
Envia a trama de dados ao Nó Controlador.
Lê os dados do comando recebido e executa-o.
3.4.3 Aquisição de sinal e preparação para a transmissão
As tramas são construídas de forma muito semelhante à aplicação Zigbee. Com o
protocolo 802.15.4 o array a enviar ao coordenador tem 8 bits em cada posição, ou seja um
byte, logo é necessário colocar as amostras do ADC de 12 bits no array. Cada 2 amostras de 12
bits são colocadas em 3 posições do array Payload da forma que se pode ver na Figura 52.
Assim um total de 64 amostras cabem em 96 posições do array Payload (função 3).
Figura 52: Construção das tramas no Nó sensor (protocolo 802.15.4).

74
Desenvolvimento
Depois deste processamento, à trama a enviar são acrescentados mais 2 bytes de 8 bits
cada que completam a trama de 98 posições correspondendo a 98 bytes. Os dados são o Node
ID e o número de trama tal como na aplicação anterior (Figura 53).
Figura 53: Trama de dados completa (802.15.4).
As tramas de comando na aplicação do protocolo 802.15.4 são iguais às da aplicação
do protocolo Zigbee.
3.4.4 Processamento no Coordenador e envio para a UART
No coordenador o processamento é essencialmente o mesmo que na aplicação Zigbee,
apesar de nesta aplicação não haver tarefas e ser tudo constituído por funções. A parte que
difere um pouco é o processamento das tramas recebidas. Neste caso a trama recebida é
encaminhada imediatamente para a subrotina de Bit Stuffing. Tudo o resto, apesar de ter ligeiras
diferenças adaptadas à dinâmica da aplicação 802.15.4 é muito semelhante à aplicação
desenvolvida anteriormente.
3.5 Estrutura do software em computador
O software no computador foi desenvolvido no ambiente de desenvolvimento LabView da
National Instruments. Esta ferramenta está optimizada para aplicações de engenharia, mais
especificamente para sistemas de teste, controlo e monitorização. Através do LabView é possível
fazer-se a aquisição de sinais, análise dos dados e a comunicação ou armazenamento dos
resultados de forma rápida e simples. O LabView utiliza um ambiente gráfico de programação
por fluxo de dados, em substituição às linguagens convencionais baseadas em texto.

Capítulo - 3
Neste caso, construiu-se uma aplicação gráfica para várias funções onde se destaca a
visualização dos sinais dos sensores. O sistema de rede comunica os sinais provenientes dos
sensores que serão mostrados, a priori, em forma de gráfico, para o utilizador ter a noção, em
tempo real, dos valores que está a receber.
3.5.1 Aplicação Gráfica
O FrontEnd da aplicação gráfica, onde são representados os sinais de quatro sensores,
encontra-se representado na Figura 54. O primeiro gráfico corresponde ao sensor de
temperatura timpânica, que foi desenvolvido como exemplo para os vários sensores que
compõem o sistema, os restantes três são sinais simulados que serão substituídos por sinais
reais desses sensores.
Figura 54: Aplicação Gráfica.
Esta aplicação tem vários controlos e indicadores, ou de outra perspectiva elementos de
entrada e de saída. Os elementos indicadores são os gráficos e as caixas de fundo a cinzento, os
controladores são os botões e as caixas de fundo branco. Os gráficos estão configurados no
modo “autoscale”, logo adaptam-se ao sinal do sensor automaticamente. No eixo das abcissas
está representado o tempo, enquanto no eixo das ordenadas representa-se o valor da grandeza
física a medir, no caso da temperatura timpânica a medida é em graus celsius (ºC). Por baixo
dos gráficos, na caixa command pode-se escolher o tipo de comando (Start, Stop ou SetFreq) e
75

76
Desenvolvimento
no botão Send Command pode-se enviar o comando ao nó sensor. No caso do comando SetFreq
pode-se digitar o valor da frequência desejada e aparece a correspondente frequência real na
caixa Real Frequency. Para funções de debug, foi adicionado um indicador para cada sensor
com os valores do número de trama, o total de tramas perdidas, o total de tramas transmitidas e
o total de tramas repetidas. Para terminar a aplicação e todos os processos desta, basta
seleccionar o botão Finish Aplication.
Ao nível da programação, o algoritmo da aplicação gráfica pode ser dividido como
demonstra o diagrama de blocos da Figura 55. Existe um ciclo que é repetido sempre que se
inicia a aplicação, e um bloco isolado, o envio de comandos que só é executado quando for
activado o botão Send Command.
diagrama.
Figura 55: Diagrama de blocos da aplicação gráfica.
Nos próximos subcapítulos será abordado em particular, cada bloco representado no
3.5.2 Recepção de dados
Para aceder aos dados recebidos na porta série do computador utilizou-se uma VI pré-
definida fornecida pelo LabView. A porta série do computador contém um buffer onde ficam
guardados os dados recebidos até que a aplicação faça a leitura. Para este processo, a aplicação
utiliza a função VISA Configure Serial Port VI para escolher, configurar e inicializar a porta série.
A função VISA Set I/O Buffer Size Function define o tamanho do buffer de entrada e saída de
dados. Por último, a função VISA Read Function que lê um número específico de dados que
estão guardados no buffer da porta série (Figura 56).

Capítulo - 3
Figura 56: Recepção de dados da aplicação gráfica (Extracto do Block Diagram do Labview).
O tamanho do buffer de entrada/saída é significativamente elevado, porque quando a
aplicação está inactiva, o buffer da porta série acumula dados, e estes terão que ser lidos em
grande número por cada ciclo, de modo a que a aplicação acompanhe a taxa de transferência
de dados do coordenador da rede sem fios.
3.5.3 Extracção de tramas
Quando a aplicação lê os dados no buffer da porta série, através da função explicada
acima, esta adquire um número aleatório de dados que depende da quantidade de dados do
buffer. Logo é necessário identificar o início de cada trama para as processar. As tramas são
recebidas com a técnica Bit suffing implementada e com o processamento de encaixe de
amostras de 12 bits num array de 8 bits em cada posição, por isso é necessário fazer o destuff e
extrair as tramas dos dados recebidos em bruto. Também é necessário extrair em cada trama, o
Node ID e o número de trama para as encaminhar para o sensor correspondente. Depois disto é
necessário criar um cluster com uma correspondência entre o Node ID, número de trama e
dados dessa trama para que sejam processados posteriormente. Na Figura 57 pode-se verificar
o diagrama de blocos com a sucessão das tarefas principais da extracção de tramas.
77

Figura 57: Diagrama de blocos da subVI Extract Frames (Extracção de tramas).
78
Desenvolvimento
A separação das tramas é feita, percorrendo o array de dados adquiridos da porta série
procurando o caractere de início de trama 126 (01111110). Uma vez encontrado, é procurado o
seguinte para definir a trama e seu tamanho. Repete-se o ciclo até ao fim do array de dados.
De cada vez que é definida uma trama, esta é logo processada pelo bloco Destuff, que
faz exactamente o processo inverso do stuff implementado no dispositivo coordenador da rede
sem fios e explicado no subcapítulo anterior.
Depois do Destuff, há a extracção do node ID e número de trama, que consiste em
separar na trama de dados os dois primeiros bytes dos restantes. Os dados daqui resultantes
passam por um processo de extracção das amostras de 12 bits, visto que no coordenador da
rede, sofreram um processamento para encaixe das amostras de 12 bits no array recebido. Este
processo de extracção de amostras é exactamente o inverso do processo explicado na Figura 52.
Neste caso em cada 3 posições do array recebido, estão 2 amostras de 12 bits e é necessário
extraí-las, para guardar num array de 12 bits por posição. No fim desta extracção, é criado um
cluster com os elementos node ID, nº de trama e dados para serem processados nos blocos
seguintes. No anexo 4 pode-se ver o block diagram da sub-VI de extracção de tramas.
3.5.4 Contagem de erros
Depois de adquiridos os dados e extraídas as tramas é necessário fazer a contagem de
erros, visto que a comunicação entre os dispositivos de rede não é totalmente eficiente em
nenhum dos protocolos implementados, verificando-se em alguns casos tramas perdidas ou
repetidas. Para fazer esta contagem foi criado um cluster com 5 elementos: Node ID, nº de

Capítulo - 3
trama, total de tramas perdidas, total de tramas transmitidas e total de tramas repetidas. Este
cluster é actualizado de cada vez que o bloco contagem de erros recebe uma trama de dados e
é visualizado no painel de erros de cada sensor (Figura 58). Por cada sensor é registado o seu
Node ID, para posteriormente serem calculados os erros e guardados no cluster do sensor
correspondente. O cálculo das tramas perdidas e repetidas são feitos individualmente, ainda que
o das tramas repetidas dependa do cálculo das tramas perdidas.
Figura 58: Atribuição do cluster de erros (Node List) ao indicador.
3.5.5 Visualização de dados
Para a visualização dos dados foi feito um switch que, através da leitura do node ID de
cada cluster que recebe, encaminha os dados de cada sensor para o gráfico e painel de erros
correcto. Os dados do sensor podem ser verificados no gráfico correspondente, enquanto os
dados sobre tramas perdidas e repetidas podem ser observados no painel (Figura 59). Os
gráficos são do tipo chart, ou seja acumulam dados actuais com os dados anteriores e estão
definidos com escalas que se adaptam automaticamente ao sinal recebido.
79

Figura 59: Visualização de dados.
80
Desenvolvimento
Com este ajuste automático das escalas, os gráficos podem receber sinais de sensores
de diferentes tipos, pois são visualizados da melhor forma. Os dados são recebidos em arrays,
com um tamanho pré-definido no nó sensor remetente. Pode ainda ser consultada a frequência
real a que o sensor está a transmitir, que pode, em alguns casos, divergir um pouco da
frequência desejada.
3.5.6 Envio de comandos
Os comandos podem ser do tipo Start, Stop ou SetFreq, estando as suas funcionalidades
explicadas na Tabela 11. Para o envio de comandos para a porta série foi construído um switch
onde é seleccionado pelo botão Send Comand o case correspondente ao sensor para onde se
deseja enviar um comando. Na caixa Command pode-se escolher o tipo de comando desejado,
que selecciona um novo case dentro de um segundo switch. Depois disto é construída uma
string com o tipo de comando (A, B ou F), o node ID e o divisor da frequência de amostragem
(Figura 60). Esta string é enviada para a porta série quando o botão Send Command é activado.

Capítulo - 3
Figura 60: Envio de comandos (Extracto do Block Diagram do Labview).
Os comandos têm o tamanho de 6 bytes, e por cada caractere é enviado o seu código
ASCII ao coordenador. Depois de receber os comandos o coordenador interpreta-os e envia ao
nó sensor correspondente.
3.6 Hardware analógico
Para completar o sistema de monitorização do corpo humano e para servir como modelo,
foi construído um circuito condicionador para um sensor de temperatura timpânica. Para
implementar este circuito, foi necessário ter em conta que o valor máximo de tensão admitido
pelo ADC é de 2.4 V, então os circuitos condicionadores deverão ter o valor de Vouto de 0 a 2.4V.
3.6.1 Sensor de Temperatura Timpânica
Para a medição da temperatura timpânica, é necessário um sensor específico, visto que
o interior do ouvido é uma zona do corpo humano bastante sensível, e na prática de natação
com o sensor, pode sofrer alguma lesão. É também importante um sensor com boa precisão e
sensibilidade de dimensões reduzidas, pois não deverá incomodar a actividade e bem-estar do
utilizador. Assim sendo optou-se pelo sensor de temperatura timpânica da Smiths Medical
(Figura 61).
81

Figura 61: Sensor de temperatura timpânica.
82
Desenvolvimento
Este sensor é protegido por uma mini esponja que é inserida no ouvido, reduzindo o
risco de lesão, e uma parte exterior, também no mesmo material que faz barreira à passagem
do ar, e ajuda na inserção do sensor no ouvido. O fio condutor do sinal eléctrico fornece leituras
precisas, reduzindo a influência do ar ambiente na temperatura.
O sensor propriamente dito, é um termistor NTC (Negative Temperature Coefficient) com
precisão de 0.2 ºC, variando a sua resistência numa gama de 850Ω a 2KΩ, para uma gama de
temperaturas entre os 30 e 45 ºC (Tabela 14).
Tabela 14: Valores da resistência do sensor NTC sensível à temperatura.
3.6.2 Circuito electrónico
Temperatura (ºC) RT (Ω)
45 ºC 850Ω
43 ºC 930Ω
40 ºC 1100Ω
37 ºC 1350Ω
34 ºC 1640Ω
32 ºC 1850Ω
Antes de qualquer descrição da implementação do circuito condicionador, é importante
referir que este sensor, pela sua aplicabilidade na área da medicina e saúde, tem as suas
características reservadas aos seus fabricantes, portanto não foi tomado conhecimento do seu
datasheet, sendo a maioria das características verificadas na prática e teste efectuados ao
sensor. Por exemplo, os valores de saída do sensor de temperatura (resistência) da Tabela 14
foram obtidos experimentalmente.
Uma das condicionantes deste circuito é sem dúvida a sua fonte de alimentação. Uma
vez que o sistema tem necessidade de ser portátil, esta deverá ser feita através de pilhas
capazes de alimentar o microcontrolador dos nós da rede e simultaneamente o circuito

Capítulo - 3
implementado. Para alimentação do circuito e do microcontrolador foram utilizadas duas pilhas
de lítio do tipo AAA de 3 V cada.
Os sensores de temperatura do tipo termistor NTC têm um coeficiente de variação de
resistência com a temperatura negativo, ou seja a resistência diminui com o aumento da
temperatura, sendo esta variação não-linear. Na Figura 62 pode-se ver a curva característica
típica de um termistor NTC.
Figura 62: curva característica de um termistor NTC, adaptado de [37].
Em muitos casos os circuitos utilizados para medição deste tipo de sensores são as
pontes de Wheatstone, ideais para sensores com reduzidas variações da sua grandeza, mas
neste caso utilizou-se um circuito alternativo com base no circuito da Figura 63.
Figura 63: Amplificador inversor com sensor na malha de realimentação.
Estando o sensor inserido na malha de realimentação, pode ver-se, pela equação que
determina a tensão de saída, que a tensão na saída do sensor é dependente da resistência do
sensor, que por sua vez varia com a temperatura.
83

84
Desenvolvimento
Este circuito foi utilizado devido ao seu maior grau de exactidão comparativamente com
as pontes de Wheatstone, e por ter uma corrente pequena e constante no NTC, independente da
resistência do mesmo. Esta última característica é importante para que a situação de aumento
de temperatura, e consequentemente diminuição da resistência do termistor, não provoque um
aumento da corrente que atravessa o termistor que por sua vez produziria um maior
aquecimento e poderia influenciar os resultados. No circuito representado na Figura 63 a
corrente que passa em RS é igual à corrente que passa no termistor, e mantém-se constante
desde que não haja variação da tensão de referência.
O OpAmp escolhido foi o LM308 que tem baixa tensão de alimentação e elevada
precisão [38]. A baixa tensão de alimentação é um dos requisitos devido à fonte de alimentação
serem pilhas de 3V. Para fazer o condicionamento do sinal do termistor, implementou-se o
circuito da Figura 64, baseado no circuito anterior, acrescido de um andar amplificador e um
divisor de tensão. O primeiro andar amplificador assegura uma corrente pequena e constante no
termistor, o segundo andar serve para ajustar o ganho para obter a gama de tensões de saída
desejada e o divisor de tensão ajusta o offset para que a tensão de saída seja nula quando o
valor de temperatura é máximo.
Figura 64: Circuito condicionador para sensor de temperatura timpânica.
A gama de medição de temperatura pretendida é de 32 a 45 ºC, visto que o organismo
humano não suporta temperaturas acima de 45ºC, e que abaixo dos 32 ºC pode entrar em
hipotermia e sofrer arritmias cardíacas fatais. A primeira tarefa para implementar o circuito era
encontrar o valor da corrente no sensor que não influenciasse os resultados. Como não era
conhecido o valor da potência máxima dissipada pelo termistor, optou-se por considerar outros
termistores NTC e admitir um valor dentro dos mesmos níveis. Admitiu-se assim o valor de 0,5

Capítulo - 3
mW para a potência de dissipação máxima no termistor, calculando-se assim o valor de corrente
no termistor segundo a equação 5.
A corrente será constante e de valor 767 µA. Analisando o circuito pode-se verificar a
tensão no ponto intermediário V3 pode ser calculado segundo a função 7.
A resistência R1 (3kΩ) foi escolhida de modo a que o primeiro andar não tivesse um
ganho muito elevado, para que o ganho seja determinado praticamente só pelo segundo andar,
de modo a ser mais fácil de controlar. Assim o ganho máximo do primeiro andar para o caso da
resistência do termistor ser máxima é de 0,617.
Para se obter uma tensão de saída de 2,4v para um valor de 32 ºC correspondendo a
1850Ω, verificou-se na prática que o valor do ganho para o segundo andar deveria ser igual a 3.
Assim admitindo que R3 com um valor de 6.6 kΩ, pode ser calculada a R2 para obter-se este
ganho.
A tensão de saída (Vout) deste circuito pode ser calculada pela função 10.
85
(5)
(6)
(7)

86
Desenvolvimento
Para ajustar o offset, foi implementado um divisor de tensão, que coloca uma tensão na
entrada não inversora do OpAmp, para precisamente compensar a diferença entre as suas duas
entradas, e consequentemente colocar a saída a 0v quando a resistência do termistor for de
850Ω. Na Tabela 15 pode-se verificar a correspondência entre os valores de temperatura,
resistência do termistor, tensão intermédia V3, ganho total e saída do circuito condicionador (Vout).
Tabela 15: Valores da saída (Vout) do circuito condicionador em função da temperatura.
Temperatura (ºC) RT (Ω) V3 (mV) Vout (V)
45 ºC 850Ω 3.3mV 0V
43 ºC 930Ω -61,8mV 0,2V
40 ºC 1100Ω -191mV 0,6V
37 ºC 1350Ω -332mV 1,2V
34 ºC 1640Ω -612mV 1.8V
32 ºC 1850Ω -775mV 2.4V
Devido ao sensor de temperatura timpânica ser não linear, será necessário corrigir essa
não linearidade digitalmente no nó sensor que fizer a aquisição deste sinal. Devido ao facto da
alimentação ser feita por pilhas de 3V este circuito satura a uma tensão de 2.13V, o que é
próximo da tensão máxima de saída desejada. Por experimentação foi obtido o gráfico da Figura
1, onde pode ser observado o sinal de saída do circuito condicionador em função da
temperatura,
Figura 65: Tensão de saída (Vout) em função da temperatura.
Este circuito tem uma sensibilidade que pode ser calculada pela função:

Capítulo - 3
Com a implementação deste circuito condicionador, o sistema de monitorização de sinais
vitais do corpo humano fica completo, funcionando este sensor juntamente com o sistema de
aquisição, como modelo para os outros sensores que completam o sistema BIOSWIM.
O sistema do circuito condicionador de sensor temperatura mais o sistema de aquisição
têm a resolução de 0.00319 ºC, como pode ser confirmado na expressão 12.
A resolução do sistema de condicionamento está duas ordens de grandeza abaixo da
resolução do sensor, pelo que é suficiente.
87

4.1 Protótipos implementados
4 Resultados
Ao longo do projecto foi implementada uma rede de comunicação sem fios com o
protocolo Zigbee com a programação do nó sensor e do nó controlador, uma outra rede de
comunicação sem fios com o protocolo 802.15.4, e uma aplicação gráfica para o computador
em LabView para comunicar com ambas as redes. Foi ainda construído um circuito
condicionador para um sensor de temperatura timpânica para servir como modelo para outros
sensores do projecto Bioswim.
O circuito condicionador para o sensor de temperatura timpânica foi implementado em
breadboard (Figura 66).
Figura 66: Circuito condicionador de sensor de temperatura timpânica.
Na Figura 67 pode ver-se os protótipos de cada elemento que constitui o sistema
desenvolvido. No anexo 5 está uma imagem que apresenta o sistema protótipo desenvolvido
numa só figura.
88

Capítulo - 4
4.2 Testes
Figura 67: Protótipos implementados.
Terminado o desenvolvimento foi necessário proceder a um conjunto de testes e
medições para comprovar o funcionamento do sistema criado. Para isso foram efectuados
diversos testes, tanto para o funcionamento geral de todo o sistema, como para o desempenho
do mesmo.
Um dos aspectos interessantes a testar neste sistema é a capacidade máxima de
comunicação, ou seja até que velocidades de transmissão o sistema comunica sem falhar,
desde a aquisição do sinal do sensor até à representação do sinal na aplicação gráfica. Outro
dos aspectos curiosos e relevantes é a comunicação em ambientes adversos, por exemplo em
ambientes ruidosos ou com os módulos de comunicação separados por obstáculos à
transferência de dados.
Para visualizar os resultados dos testes do desempenho foram essencialmente utilizados o
sistema de registo das variáveis do painel de erros da aplicação gráfica. Para testes relacionados
com o funcionamento, foi usado o sistema de debug dos microcontroladores da Jennic. Todos
estes testes foram feitos e serão descritos nos subcapítulos seguintes.
4.2.1 Testes do sistema
Para testar a parte de comunicação entre os dispositivos de rede foram geradas e
enviadas tramas controladas com dados conhecidos e visualizadas pelo sistema de debug. Na
aquisição de amostras pelo ADC foi utilizada uma fonte de sinal onde primeiramente se emitia
89

90
Resultados
valores de tensão contínua, de modo a verificar as mudanças do valor digital adquirido de acordo
com a resolução do ADC. Numa segunda fase era emitida uma sinusóide pela fonte e verificada
na aplicação gráfica.
Figura 68: Teste da Aquisição e transmissão de dados.
Os testes relacionados com processamento de dados foram também efectuados pelo
sistema de debug pelo hyperterminal do Windows. Para o teste da implementação da técnica Bit
stuffing foi gerada e emitida no nó sensor uma onda triangular para enviar à aplicação no
computador, o que obrigava a que as amostras tivessem sequências de 5 bits a 1 para
obrigatoriamente serem adicionados stuffs no nó controlador.
Para testar a transmissão de dados correctos entre os dispositivos de rede e a aplicação
gráfica, foi gerada uma trama de dados igual no nó sensor e na aplicação, verificando-se a
coincidência. A trama enviada foi um “dente de serra”, de modo a que as amostras tomassem
valores, dentro da gama de valores possível, desde o menor até ao maior, testando-se assim se
os dados que chegam à aplicação gráfica são os mesmos que foram gerados no nó sensor.
Para testar as perdas e repetição de tramas de tramas, foi colocado o sistema a
funcionar por completo, desde a aquisição até à recepção de dados por parte da aplicação
gráfica. Os erros na comunicação foram visualizados no painel de erros da aplicação gráfica e
foram registados em ficheiro.
De seguida é apresentado o plano experimental para os testes efectuados ao
desempenho do sistema.

Capítulo - 4
4.3 Plano experimental
Para testar o desempenho do sistema implementado de uma forma rigorosa, foi
elaborado um plano experimental, de modo a se perceber as condições em que os testes foram
realizados (Figura 69).
Figura 69: Plano experimental para testar o protótipo implementado.
Foram feitos dois tipos de testes: um para contabilizar o número de tramas perdidas e
outro para avaliar a qualidade do sinal entre os dispositivos de rede (Etapa A).
Para o teste das tramas perdidas foram usadas as duas implementações: Zigbee e
802.15.4 (Etapa B), onde foi utilizado o modo de energia, Low Power (Etapa C). Foi ainda
testado o modo de energia High Power na aplicação com o protocolo 802.15.4, para verificar a
diferença no desempenho entre os dois modos de energia. Para estas duas implementações
91

92
Resultados
foram colocados os dispositivos em diferentes configurações (Etapa D), para se verificar se
influenciava o resultado final. As diferentes configurações estão representadas na Tabela 16.
Nome da configuração
(Diagrama)
D1-Dispositivos juntos
D2-10 metros
D3-10 metros com parede
D4-Frente e atrás do corpo
D5-Cabeça atrás e pés à
frente
Tabela 16: Posição relativa dos dispositivos.
Descrição da configuração Motivo do teste
Dispositivos juntos. Testar a comunicação nas
melhores condições.
Dispositivos separados a
uma distância 10 metros.
Dispositivos separados a
uma distância de 10 metros
separados por uma parede.
Um dispositivo à frente do
corpo e outro atrás.
Um dispositivo atrás da
cabeça e outro à frente dos
pés.
Testar a influência da distância na
comunicação.
Testar a influência de um
obstáculo como uma parede na
comunicação.
Testar a influência do corpo
humano na comunicação.
Testar a influência do corpo
humano com os dispositivos à
distância máxima no projecto
BIOSWIM.
No caso da configuração dos dispositivos juntos, foi feito o teste para 1, 2 e 3 nós
sensores na rede, enquanto para as restantes configurações apenas foi testado para um nó
sensor na rede (Etapa E). Para todas estas condições, foi contabilizado o número de tramas
perdidas em frequências de amostragem desde 10 Hz até 10 kHz.
O teste da qualidade do sinal foi feito para o protocolo 802.15.4, porque a Jennic dispôs
funções para medir o LQI (Link Quality Indicator) apenas para aplicações que usam o protocolo
802.15.4 (Etapa B). O LQI é um valor de 8 bits (0 a 255) e indica a qualidade da ligação (sinal)
entre dois dispositivos: emissor e receptor. Este teste foi feito para os dois modos de energia
High Power e Low Power (Etapa C) e também para as diferentes configurações citadas em cima
(Etapa D). Para cada uma destas configurações foi medido o LQI para um só nó sensor na rede
(Etapa E).
De destacar que os testes foram realizados com os módulos com a antena exterior
ligada ao conector SMA. Para o caso de vários dispositivos na rede, foram usados os módulos
sem conector SMA, com a antena integrada em PCB. No final foi ainda testada a comunicação
com dois nós sensores sem antena exterior, apenas com o conector SMA.

Capítulo - 4
O critério de paragem foi a estabilização da percentagem de perdas de tramas perdidas.
Verificou-se que para as frequências mais elevadas, ao fim de 10000 tramas transmitidas, a
percentagem de perdas já não sofria nenhuma alteração. Nas frequências mais baixas a
percentagem de perdas estabilizava, com um número de transmissão de tramas mais baixo (por
volta das 4000 tramas).
No caso da aplicação Zigbee, é importante destacar que esta foi construída com as
bibliotecas SDK- Libraries versão 1.1 da Jennic, visto que a nova actualização (SDK- Libraries
versão 1.2) pode obter desempenhos diferentes, mas por motivos de incompatibilidade com a
aplicação construída não foi testada.
4.4 Resultados e Análise
Na transmissão de dados, existem perdas de tramas na comunicação entre o nó
controlador e o nó sensor, em ambos os protocolos implementados, Verificou-se que para taxas
de transmissão baixas não há perdas, mas à medida que se aumenta a frequência de
amostragem, o número de tramas perdidas é também maior. Estas perdas ocorrem devido a
dois factores: o tempo de processamento das amostras para envio, que apesar de ter sido
optimizado, tem ainda uma margem para optimização, e que pode ser melhorado
minuciosamente de modo a minimizar ainda mais as perdas; a largura de banda do canal de
transmissão, que tem um limite máximo imposto pela Jennic (taxa de transmissão efectiva de
101 kbps) e pelos protocolos 802.15.4 e Zigbee (teoricamente 250 kbps), e que não depende
do desempenho das implementações dos utilizadores. Por esta razão é necessário fazer a
contagem destas perdas para perceber as variáveis que influenciam a comunicação e
desempenho do sistema. Por esta razão é necessário fazer a contagem destas perdas para
perceber as variáveis que influenciam a comunicação e desempenho do sistema.
A seguir serão mostrados e analisados os resultados obtidos, bem como a sua relação e
factores que possam influenciar positiva ou negativamente o desempenho. Por questões de
simplificação, nos próximos subcapítulos, as aplicações implementadas com os dois protocolos
de comunicação sem fios serão chamadas pelo próprio nome do protocolo implementado,
respectivamente Zigbee e 802.15.4.
93

1) Perdas de tramas (Low Power e High Power)
94
Resultados
O primeiro teste efectuado foi a contabilização de tramas perdidas e repetidas no modo
Low Power à medida que se aumenta a frequência de amostragem e consequentemente
velocidade de transmissão de dados. Foram registadas as perdas e repetição de tramas para os
dois protocolos, e no caso do 802.15.4 foi também testado nos modos Low Power e High Power.
I) Dispositivos juntos:
Figura 70: Perdas de tramas na configuração dispositivos juntos.
Em todas as configurações dos dispositivos, verifica-se uma diferença significativa entre
a aplicação implementada com o protocolo 802.15.4 e o Zigbee. O caso mais importante para
esta aplicação é a configuração dos dispositivos juntos, visto que no fato de natação os nós
sensores estarão relativamente próximos do nó controlador. Nesta configuração a percentagem
de perdas no 802.15.4 é bastante maior, ao contrário do que se esperava inicialmente. Na
aplicação Zigbee a percentagem de tramas perdidas atinge 3,68% à frequência de amostragem
de 7 kHz, enquanto na aplicação 802.15.4, a esta frequência atinge 31,2%. Na aplicação do
802.15.4 verifica-se que no modo High Power as perdas são menores que no modo Low Power,
o que é facilmente compreendido, pois a qualidade do sinal em High Power é maior e por isso
se perdem menos tramas. Pode-se concluir que o sistema, no melhor caso, com a
implementação Zigbee tem a capacidade de adquirir amostras a 7 kHz e transmitir os sinais
adquiridos a uma taxa de 84 kbps (10,5 kiloBytes por segundo), contendo no entanto uma
percentagem de perdas de tramas de aproximadamente 3,7%. No caso da implementação
802.15.4 a frequência de amostragem pode alcançar 10 kHz mas neste caso demonstra perdas
bastante significativas, atingindo os 45%.

Capítulo - 4
II) Dispositivos a distância de 10 metros
Figura 71: Perdas de tramas na configuração distância de 10 metros.
Na configuração dos dispositivos a uma distância de 10 metros, no protocolo Zigbee
verifica-se um aumento das perdas com o aumento da FA (frequência de amostragem), mas
entre os 3 kHz e 7 kHz a percentagem de perdas oscila um pouco. Neste caso, a partir de 3 kHz
a percentagem de tramas perdidas não aumenta de forma significativa, tendo mesmo diminuído
em algumas frequências superiores. De destacar que no 802.15.4, as perdas são semelhantes
nos dois modos de energia.
III) Dispositivos a distância de 10 metros separados por uma parede
Figura 72: Perdas de tramas na configuração distância de 10 metros separados por uma parede.
Nesta configuração a percentagem de perdas começa a aumentar de forma significativa
por volta dos 3 kHz. A percentagem de perdas no 802.15.4 é semelhante nos dois modos de
95

96
Resultados
energia, um aspecto curioso, visto que no modo High Power a qualidade do sinal é superior,
como poderá ser confirmado nos resultados da qualidade do sinal no subcapítulo seguinte.
IV) Frente e atrás do corpo
Figura 73: Perdas de tramas na configuração frente e atrás do corpo.
Outro dado relevante é que tanto nesta configuração de um dispositivo à frente e outro
atrás do corpo humano, como na configuração seguinte (V), a percentagem de perdas é maior
no modo High Power do que no Low Power.
V) Frente da cabeça e atrás dos pés
Figura 74: Perdas de tramas na configuração frente e atrás dos pés.
Esta configuração de um dispositivo à frente da cabeça e o outro atrás dos pés foi
testada para simular a distância máxima entre os nós na aplicação BIOSWIM, pois os módulos

Capítulo - 4
integrados no fato de natação não poderão ter distâncias superiores. Neste caso foi verificado o
dado descrito na configuração IV.
VI) Vários dispositivos na rede
Um dos testes mais importantes para o desempenho deste sistema é a comunicação
simultânea de vários nós sensores. O sistema deverá suportar vários módulos de comunicação
em simultâneo, e ter um desempenho razoável, suficiente para monitorizar os sinais dos
sensores.
Dois Nós sensores:
Figura 75: Perdas de tramas com 2 nós em comunicação.
Neste teste verificou-se a mesma linha de resultados que se tinha vindo a obter. A
aplicação 802.15.4 continua a ter perdas bastante significativas enquanto na aplicação Zigbee,
verifica-se um ligeiro aumento das perdas nos dois nós de comunicação. Verificou-se que o nó
sensor 2 tinha uma percentagem de perdas maior que o nó sensor 1 apesar de se encontrarem
os dois à mesma distância do nó controlador e estarem nas mesmas condições. No Zigbee, as
perdas atingem, a 7 kHz, uma média nos dois nós, de 6%, enquanto no 802.15.4 alcança os
30% de tramas perdidas.
97

Três Nós sensores:
Figura 76: Perdas de tramas com 3 nós em comunicação.
98
Resultados
No caso da comunicação de três nós sensores em simultâneo, a situação não difere
muito da anterior. Nas duas aplicações os nós sensores que iniciam com maior percentagem de
tramas perdidas, mantêm esse estatuto basicamente ao longo das diferentes frequências de
amostragem, sendo a diferença das perdas entre os diferentes nós pouco significativa e
constante. Neste caso pode-se concluir que o sistema é capaz de suportar três nós sensores a
comunicar simultaneamente a 3000 amostras por segundo (36 kbps), com uma percentagem
de perdas inferior a 4%.
Dois Nós sensores com conector SMA (sem antena):
Figura 77: Perdas de tramas com 2 nós em comunicação com conector SMA.
Foi ainda efectuado um teste com os módulos de comunicação com conector SMA e
sem antena. Neste caso verificou-se que a percentagem de perdas é bastante maior que nos

Capítulo - 4
módulos de comunicação com a antena integrada em PCB. No início da comunicação, a taxas
de transferência baixas, as perdas eram já elevadas (cerca de 20%), mas aumentaram a taxas
superiores, perdendo-se mesmo quase a totalidade das tramas enviadas.
2) Qualidade do sinal (LQI)
Este parâmetro foi medido para avaliar a qualidade de sinal nas diferentes configurações
dos dispositivos. Este parâmetro influencia a quantidade de erros na transmissão de dados, uma
vez que, teoricamente, quanto melhor for a qualidade de sinal, melhor é a performance da
comunicação em termos de erros de transmissão.
Figura 78: Qualidade do sinal (LQI).
No modo High Power, a qualidade é superior para todas as configurações dos
dispositivos, sendo máxima nos dispositivos juntos com antena. Neste caso refere-se a antena, à
antena conector, que tem a função de comunicação a longas distâncias.
3) Dados Gerais
Nesta secção encontram-se os resultados anteriores, ilustrados no mesmo gráfico, para
se comparar a quantidade de erros nas diferentes configurações. Pode-se também verificar a
diferença entre os modos High e Low Power.
99

Perda de tramas em Low Power
Figura 79: Perdas de tramas em todas as configurações no modo Low Power.
100
Resultados
Nos gráficos da Figura 79, podem-se comparar as perdas de tramas em todas as
configurações, para as duas aplicações.
No caso do Zigbee as configurações dos dispositivos juntos e a 10 metros obtêm
melhores desempenhos que as restantes, no entanto na aplicação 802.15.4, são as
configurações que têm maiores perdas. Este dado é interessante do ponto de vista da
comunicação com obstáculos para dois protocolos diferentes. Na aplicação 802.15.4, as
configurações dos dispositivos no corpo humano obtêm performances mais aceitáveis, apesar de
terem perdas bastantes significativas para uma comunicação fiável.
Perda de tramas em High Power
Figura 80: Perdas de tramas em todas as configurações no modo High Power.
Em High Power a configuração dos dispositivos juntos obtém o menor número de
perdas, por outro lado a configuração dos dispositivos a 10 metros tem as piores performances.

Capítulo - 4
As duas configurações com os dispositivos no corpo humano continuam a revelar resultados
bastante semelhantes.
Comparando estes resultados com os da comunicação no modo de energia Low Power,
em geral, não se verificam melhorias.
Perda de tramas numa rede com vários dispositivos
Figura 81: Perdas de tramas com vários nós sensores na rede.
A Figura 81 mostra a comparação entre os resultados do teste das perdas de tramas
para um nó sensor em comunicação, dois nós sensores a comunicar em simultâneo e por
último três nós sensores na rede. No caso em que havia mais do que um nó sensor a
comunicar, foi feita a média das perdas desses nós sensores, para se fazer a comparação. O
teste foi feito para as duas aplicações, e em ambos os casos verifica-se, obviamente que as
perdas aumentam à medida que o número de nós comunicantes na rede aumenta. No Zigbee as
perdas em cada nó duplicam quando comunicam dois nós sensores ao mesmo tempo, ou seja o
correspondente a um só nó sensor na rede perder o quádruplo das tramas. Quando se
acrescenta mais um nó sensor (três nós sensores), a percentagem de perdas em cada nó
aumenta de cinco a seis vezes o valor de um só nó sensor na rede. No 802.15.4 as perdas não
sofrem aumentos tão significativos como no Zigbee, apresentando aumentos de 1,2 e 1,5 para a
comunicação de dois e três nós sensores respectivamente. No entanto, é necessário tomar em
conta que a percentagem de perdas original é já muito superior, ou seja, mesmo com o maior
aumento de perdas, o Zigbee continua a ter menores perdas a taxas de amostragem mais
elevadas.
101

4.5 Resultados Gerais
102
Resultados
Fazendo uma análise geral dos resultados obtidos, pode-se concluir que a aplicação
desenvolvida com o protocolo Zigbee obtém melhores desempenhos que o 802.15.4. Neste
protocolo as velocidades de transmissão alcançadas são bastante interessantes para este
projecto, especialmente na implementação do protocolo Zigbee. Taxas de amostragem na ordem
dos 7 kHz com uma percentagem de perdas de 3,7%, é um bom resultado para fazer a
aquisição de sensores com necessidade de frequências de amostragem elevadas como os
sensores EMG. Este é o principal requisito deste projecto, e todo o seu desenvolvimento foi
efectuado em torno deste objectivo.
Nesta aplicação os erros na transmissão de tramas são pouco significativos, ainda que se
devam ter em conta, pois para vários sinais vitais, a perda de algumas amostras pode significar
a inviabilidade da amostragem. Este problema poderá ser solucionado futuramente, quando as
funções de ackowledgement estiverem disponíveis para a primeira versão de bibliotecas utilizada
nesta aplicação. No entanto esta solução poderá eventualmente diminuir a taxa de transmissão,
uma vez que por cada trama, ou conjunto de tramas o coordenador terá que enviar um
ackowledgement a confirmar a recepção de dados.
O facto de os dispositivos finais poderem alternar entre o modo sleep e o modo activo é
também uma mais-valia para este projecto, pois dessa forma pode-se diminuir o consumo de
energia e aumentar a autonomia da rede sem fios.
4.6 Problemas e Soluções
Ao longo do desenvolvimento deste projecto, foram vários os entraves e problemas que
surgiram, o que enriqueceu o conhecimento prático e incentivou ao desenvolvimento de novas
capacidades.
Um dos grandes problemas iniciais foi a limitada função de debug deste microcontrolador,
pois ainda não está disponível a depuração de erros por software. Para contornar este problema,
o debug foi sempre efectuado pelo hyperterminal do windows usando funções que enviam para o
computador o valor das variáveis e o estado da execução. No entanto esta solução tem um nível

Capítulo - 4
organizacional da informação muito inferior quando comparada com o debug por software.
Algumas outras funcionalidades deste microcontrolador também ainda não estão disponíveis,
como por exemplo as interrupções do ADC para esta versão do software Zigbee PRO, pois não
funcionam simultaneamente com o RTOS.
Outro problema, foi o facto do microcontrolador JN5148 não possuir um software de
desenvolvimento específico para as suas funções. Em vez disso utiliza um software (Eclipse) de
carácter geral que suporta vários níveis de programação, o que faz com que a função de
simulação por software esteja indisponível, sendo feito todos os testes online. Isto significa que
cada vez que se pretende fazer uma alteração no firmware e testá-la, o programa tem que ser
compilado e descarregado para os vários microcontroladores (dependendo do número de nós
sensores que se está a utilizar na rede) que depois terá que ser executado, visualizando-se todo
os dados de debug no computador. Este problema limita o desenvolvimento do projecto em
termos de tempo, visto que o download do firmware para a memória flash do microcontrolador
demora um tempo considerável.
As várias actualizações das bibliotecas que contêm as API’s de desenvolvimento e a
correcção de alguns erros dos fabricantes, verificados em versões anteriores, foram também um
importante entrave no desenvolvimento desta aplicação. Com a actualização, algumas das
funções implementadas anteriormente, ficaram obsoletas, o que levou a que tivessem que ser
desenvolvidas novas funções. Este microcontrolador também carece de aplications notes, visto
ser relativamente recente, o que motivou um estudo intensivo das API’s de desenvolvimento para
solucionar alguns problemas.
Um outro problema na comunicação, foi a recepção de dados por parte do controlador
quando o nó sensor ainda não estava registado. Nesta situação o controlador recebia tramas
com valores aparentemente aleatórios enquanto não se procedia ao registo e identificação do nó
sensor. Foi implementado um sistema de registo dos nós sensores que se juntam à rede, com a
memorização do seu endereço de rede e Node ID.
103

5 Conclusões
Este projecto teve como objectivo final criar um protótipo completo destinado fazer a
monitorização de sensores biométricos integrados num fato de natação.
O projecto foi iniciado com o estudo de formas de monitorizar o corpo humano em
exercício extremo no meio aquático. Terminado este estudo foi possível perceber as
necessidades do sistema a desenvolver, começando a pesquisa de módulos de comunicação
sem fios que integrassem os requisitos necessários à realização deste projecto. Uma vez
encontrados os módulos de desenvolvimento, foi realizado um estudo intensivo da pilha
protocolar Zigbee, das aplications notes, das API’s e ambiente de desenvolvimento usado pelo
microcontrolador.
Findo o processo de estudo, procedeu-se à implementação do sistema de monitorização.
Este foi o ponto de viragem no projecto, uma vez que depois de muito estudo teórico, e uma
grande variedade de testes na tentativa de funcionamento de algumas funcionalidades dos
módulos de desenvolvimento, passou-se à prática e à obtenção de resultados mais específicos.
Com o Zigbee a servir como base protocolar para a comunicação, começou-se por implementar
as funções de envio de dados entre os dispositivos, passando para as funções de aquisição de
dados, terminando com a comunicação entre o coordenador e o computador. Depois de uma
obtenção de resultados não satisfatória, foi implementada uma nova rede, desta vez com o
protocolo 802.15.4, com o objectivo de melhorar as performances da rede já implementada.
Para a visualização dos dados e controlo dos dispositivos da rede foi construída uma
aplicação gráfica no ambiente de desenvolvimento de programação gráfica LabView. Esta
aplicação permite a comunicação de quatro sensores em simultâneo, e a visualização dos sinais
correspondentes e erros associados. Os sensores podem ser controlados individualmente,
através de tramas de comandos.
Depois da implementação do software, e para completar o sistema, foi estudado e
construído o hardware para o condicionamento de sinal de um sensor de temperatura do tipo
104

Capítulo - 5
termístor NTC. Este módulo serve como modelo para outros circuitos condicionadores para
outros sensores que irão integrar o fato de natação, visto que tem os parâmetros necessários
para a interface com o dispositivo nó sensor.
Os testes efectuados ao sistema, foram feitos de forma progressiva, à medida que se
iam terminando módulos e etapas. A programação do firmware e software foi, sempre que
possível, implementado por módulos, de modo a serem vistos como uma “caixa negra” com
entradas e saídas e poderem ser utilizados noutros programas e aplicações. Uma vez
terminados os testes em termos de funcionamento, chegou o momento para testar o
desempenho do sistema de diferentes formas e com condições de funcionamento diferentes.
De entre os vários resultados obtidos, pode-se destacar a implementação com o
protocolo Zigbee que tem a capacidade de adquirir a uma frequência de 7 kAmostras/s. A essa
frequência de amostragem a taxa de transferência de dados correspondente é de 84 kbps,
obtendo-se uma percentagem de perdas de tramas abaixo dos 4%. Na comunicação com vários
dispositivos na rede a mesma implementação suporta a comunicação simultânea de pelo menos
três nós sensores, a 3000 amostras por segundo (36 kbps), com uma percentagem de perdas
inferior a 4%.
As perdas ocorrem maioritariamente em tramas individuais e casualmente em blocos de
tramas na comunicação entre o dispositivo final e o coordenador. À medida que se vai
aumentando a frequência de amostragem, a percentagem de perdas vai sendo maior até uma
frequência máxima de 10 kHz (implementação 802.15.4). Este limite deve-se ao facto de a 10
kHz, o tempo disponível entre as amostragens (0,1 ms) não ser suficiente para adquirir,
processar e enviar os dados ao coordenador.
Os resultados obtidos foram interessantes do ponto de vista da utilização deste sistema
para monitorizar vários sensores em simultâneo, e para sensores com necessidade de elevadas
taxas de amostragem.
Para a realização deste projecto foram consultados vários artigos e trabalhos
relacionados com redes corporais de sensores, e-têxteis, e redes sem fios de curto alcance, bem
como exemplos de circuitos condicionadores. Esta pesquisa revelou-se bastante importante visto
oferecer vários pontos de vista diferentes, e várias abordagens aos problemas a solucionar.
O trabalho efectuado foi realizado sensivelmente em dez meses, sendo o tempo restante
para testes e optimização. Os resultados atingiram os resultados previstos e nalguns casos
excederam algumas das expectativas criadas inicialmente.
105

5.1 Trabalho Futuro
106
Conclusões
Este projecto, apesar de importante, é apenas uma parte do projecto BIOSWIM. Para ser
utilizado neste projecto terá que ser ajustado e adaptado para outros tipos de sensores e outros
requisitos que o projecto exija. Por este motivo este projecto ainda tem alguns aspectos passíveis
de serem melhorados.
Futuramente os circuitos condicionadores terão que ser implementados em placa PCB,
de modo a terem dimensões mais reduzidas e poderem ser integrados no tecido do fato de
natação. O circuito condicionador do sensor de temperatura terá que passar por esse processo.
Deverá ser implementado um sistema de acknowledge, de modo a minimizar ou eliminar
as perdas de tramas. Deve ter-se em conta o facto de o sistema de acknowledge prejudicar a
performance da rede e colocar em risco a transmissão em tempo real, logo essa implementação
deverá ser equilibrada para se obter no final o desempenho desejado.
Poderão ser implementados outros comandos dentro da mesma estrutura que os já
existentes. Poderão ser implementados comandos para pedir amostras isoladas, por exemplo
para o sensor de temperatura, ou para enviar o valor da qualidade do sinal.
A aplicação gráfica pode tornar-se mais dinâmica com outros tipos de informação, como
a leitura da energia em cada nó sensor, a verificação do tráfego de canal e outras informações
relacionadas com os nós sensores utilizados no fato de natação.
Um aspecto interessante e de grande valor para o futuro é a interface dos sinais
biométricos com uma página Web, de modo a que o utilizador da aplicação gráfica, consiga
visualizar o exercício da pessoa monitorizada em qualquer lugar.

Bibliografia
[1] N. Zamorra, P. Marbel, and P. Khosla, "Electronic Textiles: A Platform for
Pervasive Computing," in , 2003.
[2] F. Morais, J. Lieutaud, and S. Kofuji, "e-Textiles – Uma aplicação para Redes de
Sensores Sem Fio," in .
[3] W. weber, et al., "Electronics in Textiles - The Next Stage in Man Machine
Interaction," in .
[4] B. Lee and V. Subramanian, "Organic Transistor on Fiber: A first step towards
electronic textiles," Department of Electrical Engineering and Computer Sciences,
University of California.
[5] Inovação tecnológica. [Online].
http://www.inovacaotecnologica.com.br/noticias/noticia.php?artigo=01018004122
4
[6] Mechatronic Tips. [Online].
http://www.mechatronictips.com/technology/robotics/optical-sensor-gives-robots-
human-touch/
[7] D. Tomanek. (2010) The Nanotube site. [Online].
http://www.pa.msu.edu/cmp/csc/nanotube.html
[8] A. Jain, R. Bolle, and S. Pankanti, Introduction to Biometrics . 2002.
[9] T. Reilly, B. Drust, and W. Gregson, Thermoregulation in elite athlets. 2006.
[10] M. Gleeson, "Temperature Regulation during Exercise," Int. J Sports Med, 1998.
107

[11] A. Simões and M. Martino, "Variabilidade circadiana da temperatura oral,
timpânica e axilar em adultos hospitalizados," Faculdade de ciências médicas,
Universidade Estadual de Campinas, 2005.
[12] R. Schmidt, T. Norgall, J. Morsdorf, J. Bernhard, and T. Von der Grun, Body Area
Network BAN--a key infrastructure element for patient-centered medical
applications. Schmidt R, Norgall T, Mörsdorf J, Bernhard J, von der Grün T..
[13] H. Carvalho, "Data fusion implementation in sensor networks applied to helth
monitoring," Departamento de Ciência Computação, Universidade Federal de
Minas Gerais, 2005.
[14] E. Karulf. (2008) Body Area Networks (BAN). [Online].
http://www.cse.wustl.edu/~jain/cse574-08/ftp/ban/index.html
[15] S. Rossetto, F. Costa, and V. Sacramento, "Redes de sensores sem fio: visão geral e
um exemplo de implementação," 2007.
[16] R. Ramachandran, L. Ramanna, and H. Ghasemzadeh, "Body sensor networks to
evaluate standing balance: interpreting muscular activities based on inertial
sensors," University of Texas at Dallas, 2008.
[17] T. Barbosa, "Uma arquitectura de rede de sensores do corpo humano ,"
Departamento de energia eléctrica, Universidade de Brasília, 2008.
[18] J. Sewook, "Comparisons of ZigBee Personal Area Network (PAN)
Interconnection Methods: Wireless Communication Systems," 2007.
[19] J. Lee, S. Yu, and S. Chung, "A Comparative Study of Wireless Protocols:
Bluetooth, UWB, ZigBee, and Wi-Fi," in The 33rd Annual Conference of the IEEE
Industrial Electronics Society, 2007.
[20] N. Baker, "Zigbee anr Bluetooth strengths and weaknesses for industrial
applications," IEEE Computing and Control Engineering, 2005.
108

[21] IEEE, "Wireless LAN medium access control(MAC) and physical layer(PHY)
specification," no. LAN-MAN Standards Committee of the IEEE Computer
Society, 2003.
[22] Jennic, "IEEE 802.15.4 Wireless Networks User Guide," Jennic, 2006.
[23] S. C. Ergen, "ZigBee/IEEE 802.15.4 Summary," 2004.
[24] Ondrej, Zdenek, and Petr, "Zigbee technology and device design," in IEEE
International Conference on Networking, International Conference on Systems and
International Conference on Mobile Communications and Learning Technologies,
2006.
[25] Z. Alliance, "Zigbee specification. Technical report," 2005.
[26] A. Potsch, "Zigbee Spec. and IEEE 802.15.4," Universty Linz, Austria, 2006.
[27] Bluetooth SIG. (2010) Bluetooth. [Online].
http://www.bluetooth.com/
[28] B. Miller and C. Bisdikian, "Bluetooth Revealed 1. ed.," 2001.
[29] J. Bray and C. Sturan, "Bluetooth - Connect without Cables," 2001.
[30] H. Ranki. Affix - End User Manual. [Online].
http://affix.sourceforge.net/affix-newdoc/Affix-enduser/c21.html
[31] P. Mcdermott, "Bluetooth scatternet models," 2004.
[32] (2008) Electrónica.org. [Online].
http://www2.eletronica.org/artigos/eletronica-digital/bluetooth
[33] Bluetooth SIG, "Specification of the Bluetooth System - Core v1.1," 2001.
[34] C. Pamuk, "Distributed Bluetooth Scatternet Formation Algorithm based on Device
and Link Characteristics," 2003.
[35] Wikipedia Foundation. (2010) Wikipedia. [Online].
109

http://en.wikipedia.org/wiki/Eclipse_%28software%29
[36] Jennic, "ZigBee PRO Stack User Guide," 2009.
[37] M. J. Soares. arnerobotic. [Online].
http://www.arnerobotics.com.br/eletronica/Medidas_analogicas_BS1.htm
[38] National Semiconductor. LM108/LM208/LM308 Operational Amplifiers. [Online].
http://www.national.com/opf/LM/LM308.htm
110

Figura 82: Modelo protocolar da pilha Zigbee.
1
Anexo 1

2
Anexo 2
Figura 83: Pilha de Protocolos Bluetooth e principais funções de cada camada, adaptado de [29].
A pilha de protocolos Bluetooth pode ser dividida, logicamente, em três grupos:
protocolos de transporte, protocolos middleware e grupo de aplicação.
Os Protocolos de Transporte têm como objectivo realizar a identificação entre
dispositivos Bluetooth, possibilitando a criação, configuração e gerência de conexões físicas e
lógicas. São através destas conexões que os aplicativos enviam dados, utilizando os protocolos
de transporte. Os protocolos deste grupo incluem as camadas de Radio, Baseband, Link
Manager, L2CAP e HCI (ver Figura 84 a).
Os Protocolos Middleware são compostos por protocolos de transporte adicionais
necessários para a interface de determinadas aplicações com a tecnologia Bluetooth (ver Figura
84b). Este grupo de protocolos inclui tanto protocolos padrões da indústria como protocolos

desenvolvidos pelo SIG especificamente para comunicação via Bluetooth. Os protocolos
middleware correspondem às camadas RFCOMM, SDP,
OBEX, WAP e TCS.
Figura 84: Grupos da pilha de protocolos Bluetooth. (a): Grupo de protocolos de Transporte, (b): Grupo de protocolos Middleware,
(c): Grupo de aplicação. (em negrito).
O grupo de aplicação neste contexto se refere aos softwares que residem acima da pilha
de protocolos definida pelo SIG (ver Figura 84c). Este é o caso dos softwares aplicativos que
fazem uso da tecnologia Bluetooth. Para o funcionamento adequado destes aplicativos com a
tecnologia Bluetooth, o Bluetooth SIG especificou profiles para diversas aplicações [33].
3

Figura 85: Configuração pormenorizada do ZPS (parâmetros de rede).
4
Anexo 3

Figura 86: Block Diagram da subVI Extract Frame.
5
Anexo 4

Figura 87: Protótipo implementado completo.
6
Anexo 5