dispositivo electrónico pessoal para aquisição de …ee09013/docs/dissertacao_prov...figura 34...

Faculdade de Engenharia da Universidade do Porto

Dispositivo Electrónico Pessoal para Aquisição de Dados obtidos por Sensores

António Alberto da Silva Marques

VERSÃO PROVISÓRIA

Dissertação realizada no âmbito do Mestrado Integrado em Engenharia Electrotécnica e de Computadores

Major Telecomunicações

Orientador: Prof. Dr. João Canas Ferreira Co-orientador: Prof. Dr. José Carlos Alves

Junho de 2010

Resumo

O trabalho apresentado neste documento insere-se no domínio dos sistemas de context-

aware, ambientes inteligentes (AmI) e computação ubíqua. A aquisição de informação de

contextos através de sensores e dispositivos electrónicos, que se caracterizem por ser o

menos intrusivo para o utilizador e permitam o envio da mesma para dispositivos externos

(e.g. telemóveis) poderá representar uma grande mais-valia em algumas áreas como, por

exemplo, as telecomunicações, na medida em que representa um vasto conjunto de novas

oportunidades para os operadores móveis na disponibilização de novos serviços, adaptados ao

contexto que rodeia um ou vários utilizadores. Outra área que poderá usufruir do potencial

da informação do contexto será a área da saúde, nomeadamente através da monitorização à

distância de doentes ou idosos.

Pretendeu-se com este trabalho desenvolver um dispositivo electrónico (baseado numa

placa de circuito impresso) que transmitisse, via Bluetooth, para um dispositivo móvel

(smartphone ou PDA), dados recolhidos através sensores ligados ao mesmo. O dispositivo

electrónico desenvolvido caracteriza-se por ser de baixo consumo de energia, possuir vários

canais para a aquisição de dados, obtidos através de sensores analógicos e interfaces digitais,

e a sua alimentação ser por baterias e dimensões reduzidas, tornando-o pouco intrusivo para

que possa ser colocado em qualquer tipo de ambiente (e.g. casas, hospitais, museus) ou num

artefacto utilizado por pessoas (e.g. no vestuário). O módulo de comunicação sem fios

Bluetooth integrado no sistema de aquisição de dados possui a Classe 1 da tecnologia, o que

lhe confere o maior alcance disponível. Foram utilizados sensores analógicos para obter

medidas de luminosidade, humidade e som e um sensor digital com interface SPI para medir

temperatura e aceleração.

Com a utilização de sensores ligados ao sistema de aquisição de dados, e estando o

mesmo conectado, via Bluetooth, a um computador com um software de interpretação de

dados a ser executado, é possível recolher as várias informações de medida associadas aos

contextos em análise. A informação lida pelos sensores é transmitida a um dispositivo móvel

que a utilizará para inferir o contexto em que o utilizador se encontra, como por exemplo,

identificar se esse utilizador se encontra a andar, a correr, parado ou deitado, através do

acelerómetro, se o mesmo se encontra num ambiente silencioso e escuro, através dos

sensores de som e luminosidade ou até, por exemplo, se o utilizador se encontra num

ambiente quente e húmido, através dos sensores de temperatura e humidade. A validação

dos dados recolhidos pelos sensores foi realizada através de um software de interpretação de

dados que permitiu interpretar as variações que ocorreram nos dados recolhidos dos

contextos analisados no âmbito deste projecto e analisar como os mesmos podem ser

utilizados no desenho de árvores de decisão para inferir o contexto em que um determinado

utilizador se encontra.

Palavras-chave: Context-aware, Contexto, Ambientes Inteligentes, Sensores

Abstract

The work presented in this document refers to a study in the area of systems of context-

aware, ambient intelligence (AmI) and ubiquitous computing. Context information acquired

from unobtrusive sensors and electronic devices has potential value for some areas like

telecommunications, because it uncovers a wide set of opportunities for the offer of new

services, adapted to the context that surrounds one or several users (context-aware

services). Health care can also take advantage of context information, namely for remote

monitoring of patients or elderly people.

The aim of this project was to develop an electronic device (PCB – printed circuit board)

that transmits, via Bluetooth, to a mobile device (smartphone or PDA), data collected by

sensors connected to the PCB. The electronic system developed in this work has low power

consumption, multiple channels for the acquisition of data from analog and digital sensors.

It can be powered by small batteries, making it less intrusive, so that it can be integrated in

many environments (e.g. houses, hospitals, museums) or in a wearable artefact (e.g.

clothes). The Bluetooth wireless communication module included in the data acquisition

system has Class 1, which allows it to have the largest range available.

Analog sensors are used to obtain measurements of light, humidity and sound, and a

digital sensor with SPI interface is used to measure temperature and acceleration.

The acquisition system can be connected via Bluetooth to a computer where a data

collection program stores and analyses the information about the user context.

This information can be used to infer the context in which the user is, for example, to

identify if a particular user is walking, running, standing or laying down, or if that user is

in a silent and dark environment.

The correct operation of the system was validate with help of the data collection

program, which allows the examination of the variations that occur in the data, and the

analysis of how the data can be used in the design of decision trees to infer the context of a

particular user.

Key-words: Context-aware, Context, Ambient Intelligence, Sensors

Agradecimentos

Neste espaço gostaria de agradecer às pessoas que contribuíram para a realização deste

projecto, dando o seu apoio, ideias e críticas.

Os meus sinceros agradecimentos ao Prof. João Cana Ferreira pela sua disponibilidade,

interesse demonstrado e sugestões transmitidas durante a elaboração deste projecto. A sua

excelente capacidade de orientação foi crucial nas fases mais complicadas do projecto.

Ao Prof. José Carlos Alves pela disponibilidade e interesse demonstrados, assim como

pelas sugestões dadas durante a fase do desenvolvimento do projecto.

Ao Prof. José Machado da Silva pela sua disponibilidade, apoio e partilha de

conhecimento sempre que solicitado.

Ao Prof. João Cardoso pelo interesse e disponibilidade para a partilha de ideias.

Aos técnicos do DEEC, Pedro Alvares e Rui Carvalho, o meu muito obrigado pelas rápidas

respostas, quando solicitados.

Aos meus amigos, pela compreensão e apoio que sempre me deram, o meu muito

obrigado.

Ao meu irmão e aos meus pais um agradecimento especial pelo apoio que me deram em

todos os momentos.

Um agradecimento muito especial à Cláudia, pela compreensão, carinho, apoio e

motivação incansável que me deu durante os últimos tempos. Obrigado!

Índice

Resumo ............................................................................................. 3

Abstract ............................................................................................. 5

Agradecimentos ................................................................................... 7

Índice ................................................................................................ 9

Lista de figuras ................................................................................... 11

Lista de tabelas .................................................................................. 13

Abreviaturas e Símbolos ......................................................................... 1

Capítulo 1 .......................................................................................... 1

Introdução ......................................................................................................... 1

1.1 Motivações .............................................................................................. 1

1.2 Objectivos ............................................................................................... 2

1.3 Requisitos gerais ....................................................................................... 2

1.4 Estrutura da dissertação .............................................................................. 3

Capítulo 2 .......................................................................................... 5

Enquadramento .................................................................................................. 5

2.1 A ubiquidade da computação ........................................................................ 5

2.2 Ambientes Inteligentes (Aml) ........................................................................ 6

2.3 Context-awareness .................................................................................... 7

2.4 Trabalhos relacionados ............................................................................. 11

Capítulo 3 ......................................................................................... 17

Descrição do sistema desenvolvido ......................................................................... 17

3.1 MCU PIC18F14K22 da Microchip ................................................................... 18

3.2 Módulo de comunicação Bluetooth ............................................................... 22

3.3 Interface de programação ICSP .................................................................... 25

3.4 Módulo de alimentação e alimentação externa ................................................ 25

3.5 Sensores ............................................................................................... 26

Capítulo 4 ......................................................................................... 37

Plataforma de hardware ...................................................................................... 37

4.1 Esquema eléctrico do PCB .......................................................................... 37

4.2 Layout do PCB ......................................................................................... 40

4.3 Descrição do PCB ..................................................................................... 42

4.4 Módulo Bluetooth BlueSMiRF ....................................................................... 43

4.5 Programação do MCU ................................................................................ 45

Capítulo 5 ......................................................................................... 47

Software residente ............................................................................................. 47

5.1 Algoritmo de programação do software residente ............................................. 47

5.2 Funções implementadas ............................................................................. 49

Capítulo 6 ......................................................................................... 53

Validações ....................................................................................................... 53

6.1 Software de interpretação de dados .............................................................. 54

6.2 Comunicação com o telemóvel .................................................................... 62

Capítulo 7 ......................................................................................... 63

Conclusões e perspectivas futuras .......................................................................... 63

7.1 Conclusões ............................................................................................. 63

7.2 Perspectivas futuras ................................................................................. 64

Anexo 1 ............................................................................................ 67

Anexo 2 ............................................................................................ 69

Anexo 3 ............................................................................................ 71

Anexo 4 ............................................................................................ 73

Anexo 5 ............................................................................................ 75

Anexo 6 ............................................................................................ 77

Referências ....................................................................................... 89

Lista de figuras

Figura 1 - Evolução da computação [4] ................................................................... 6

Figura 2- Ciclo de vida de um contexto [13] ............................................................. 8

Figura 3 - Dimensões de um contexto [14] [15] ......................................................... 8

Figura 4 - Atributos da informação de contexto [13] ................................................... 9

Figura 5 - Exemplo de árvore de decisão induzida [19] ............................................... 12

Figura 6 - Árvore de decisão induzida pelas leituras do cenário teste [19] ....................... 13

Figura 7 - Dispositivo de aquisição de dados BlueSentry [20] ........................................ 14

Figura 8 - Dispositivo BlueHome [21] ..................................................................... 15

Figura 9- Descrição do sistema ............................................................................ 17

Figura 10 - Ligação Simples SPI Master-Slave ........................................................... 20

Figura 11 - Ligação Master-Slave em cascata ........................................................... 21

Figura 12 - Ligação Master-Slave independente........................................................ 21

Figura 13- Pinout do módulo BlueSMiRF ................................................................. 24

Figura 14 - Divisor de tensão do sensor de luminosidade ............................................. 27

Figura 15 - Sensor de luminosidade ....................................................................... 28

Figura 16 - Características da variação da RL versus luminosidade (Lux) ......................... 28

Figura 17 - Características típicas da tensão de saída do sensor de humidade a 25º ............ 29

Figura 18 - Sensor de Humidade HU1015NA [34] ....................................................... 30

Figura 19 - Sensor de som .................................................................................. 31

Figura 20 – Sensor de temperatura e de aceleração e respectivo pinout .......................... 32

Figura 21 - Formato da frame SPI [36] ................................................................... 33

Figura 22 - Descrição do registo da aceleração [36] ................................................... 34

Figura 23 - Eixos de aceleração X, Y e Z do sensor acelerómetro .................................. 34

Figura 24 - Descrição dos bits do registo de temperatura [36] ...................................... 35

Figura 25- Esquema eléctrico do PCB .................................................................... 39

Figura 26 - Footprint do MCU ............................................................................. 41

Figura 27 - Camada BOTTOM do PCB ..................................................................... 42

Figura 28 – Esquema de localização dos interfaces conectores no PCB ............................ 42

Figura 29 - Pinout das ligações do ADC, SPI, I2C e módulo BlueSMiRF ............................. 43

Figura 30 - Protótipo desenvolvido ....................................................................... 43

Figura 31 - Parametrizações das propriedades do Hyperterminal para o BlueSMiRF ............ 45

Figura 32 - Programação do MCU ......................................................................... 46

Figura 33 - Algoritmo de programação do MCU (versão 1.0) ......................................... 48

Figura 34 – Medições de luminosidade, humidade e som do interior de uma sala de estar, com duas janelas para o exterior Contexto da medição: desligar e ligar a luz do ambiente de teste, e tom de voz alto ............................................................ 55

Figura 35 - Medições de luminosidade, humidade e som do interior de uma sala de estar, com duas janelas para o exterior Contexto da medição: fecho da janela da sala e som de passagem de veículos ....................................................................... 56

Figura 36 - Medições de luminosidade, humidade e som do interior de uma sala de estar, com duas janelas para o exterior Contexto da medição: fecho e abertura da janela da sala, e variações de frequências de uma música ............................................ 57

Figura 37 - Sensor luminosidade e som, em ambiente exterior ..................................... 57

Figura 38 - Sensor humidade, em ambiente interior de uma sala de estar e ambiente exterior ................................................................................................. 58

Figura 39 - Acelerómetro - aceleração eixo Y e X ..................................................... 59

Figura 40 - Acelerómetro - aceleração eixo Y e Z ..................................................... 59

Figura 41 - Acelerómetro - aceleração eixo X e Z ..................................................... 60

Figura 42 – Cenários de aceleração ...................................................................... 60

Figura 43 - Temperatura interior - sala de estar e frigorífico ....................................... 61

Figura 44 - Temperatura interior - sala de estar (medição por um multímetro)................. 61

Figura 45 - Informação recebida do sistema de aquisição de dados, via Bluetooth, num computador através de um emulador de terminal (Tera Term VT) .......................... 62

Figura 46 - Comunicação do sistema de aquisição de dados com o telemóvel ................... 62

Lista de tabelas

Tabela 1 - Características do dispositivo BlueSentry .................................................. 14

Tabela 2 - Características do dispositivo BlueHome ................................................... 16

Tabela 3 - Características do PIC18F14K22 .............................................................. 18

Tabela 4 - Características das classes Bluetooth ....................................................... 22

Tabela 5 - Características do módulo BlueSMiRF ....................................................... 23

Tabela 6 - Pinout do módulo BlueSMiRF ................................................................. 24

Tabela 7 - Características do sensor de luminosidade ................................................ 27

Tabela 8 - Características do sensor de humidade ..................................................... 29

Tabela 9 - Características do sensor de som ............................................................ 31

Tabela 10 - Características do sensor de temperatura e aceleração ............................... 32

Tabela 11 - Descrição do esquema eléctrico ............................................................ 38

Tabela 12 - Especificações eléctricas da SCI do MCU ................................................. 40

Tabela 13 - Características eléctricas da SCI do dispositivo RN-41 ................................. 40

Tabela 14 - Especificações de ligação ao módulo BlueSMiRF (via Bluetooth) ..................... 44

Tabela 15 - Consumo do hardware do sistema ......................................................... 53

Abreviaturas e Símbolos

ADC Analog-to-Digital Converter

AmI Ambient Intelligence

CAD Computer-Aided Design

DEEC Departamento de Engenharia Electrotécnica e de Computadores

EEPROM Electrically-Erasable Programmable Read-Only Memory

EUSART Enhanced Universal Synchronous Asynchronous Receiver Transmitter

FEUP Faculdade de Engenharia da Universidade do Porto

ICSP In-Circuit Serial Programmed

I2C Inter-Integrated Circuit

LDO Low Dropout Regulator

LDR Light Dependent Resistor

MCU MicroController Unit

PCB Printed Circuit Board

PDA Personal Digital Assistant

PLL Phase Lock Loop

SCI Serial Communications Interface

SPI Serial Peripheral Interface

SPP Serial Port Profile

SRAM Static Random Access Memory

UART Universal Asynchronous Receiver Transmitter

USART Universal Synchronous Asynchronous Receiver Transmitter

IEEE Institute of Electrical and Electronics Engineers

UPCASE User-Programmable Context-Aware Services

MOSI Mater Output Slave Input

MISO Master Input Slave Output

Capítulo 1

Introdução

Este capítulo descreve as motivações e objectivos associados ao desenvolvimento do

projecto e a descrição da estruturação do presente documento.

1.1 Motivações

"The most profound technologies are those that disappear: they weave themselves into

fabric of everyday life until are indistinguishable from it." Mark Weiser [1]

A execução deste projecto surge como uma resposta à crescente importância que as áreas

de computação ubíqua e ambientes inteligentes têm vindo a assumir.

Estamos numa era marcada pela omnipresença das comunicações e dos dispositivos

computacionais, que passam a ser parte integrante do espaço físico em que vivemos e das

mais variadas tarefas do dia-a-dia. A tendência é que essa integração aumente cada vez mais,

através do desenvolvimento de interfaces e hardwares que medem e interpretam o contexto

das pessoas (vulgarmente designado por context-aware computing).

Conforme refere Mark Weiser, o pai da computação ubíqua, as tecnologias mais profundas

e duradouras são aquelas que desaparecem, as que se dissipam nas coisas do dia-a-dia até se

tornarem indistinguíveis. Neste sentido, pretendeu-se com este projecto desenvolver um

dispositivo, que pudesse ser utilizado em casa ou como um artefacto pessoal, que se

caracterizasse por ser o menos intrusivo possível e que permitisse a recolha de informação de

contexto em que um determinado utilizador se encontra.

Introdução 2

1.2 Objectivos

Este trabalho tem como principal objectivo a concepção de um dispositivo pessoal de

aquisição de dados obtidos por sensores, de baixo consumo de energia, que possa ser

utilizado como um artefacto pessoal que comunique via Bluetooth com dispositivos externos,

como, por exemplo, o smartphone ou o PDA.

Para a execução deste trabalho, foi definido um conjunto de objectivos, que se dividiram

em 6 fases.

A primeira fase consiste no levantamento dos requisitos relacionados com o protótipo a

desenvolver, o seu estudo de viabilidade e a definição da arquitectura do sistema, baseada

nas características e compatibilidades dos componentes existentes no mercado.

A fase seguinte traduz-se na análise e estudo de dispositivos existentes no mercado com a

mesma aplicabilidade do protótipo a desenvolver.

A terceira fase corresponde ao desenvolvimento da placa de circuito impresso (PCB) do

protótipo e compreende os seguintes objectivos: a captura esquemática do protótipo, o

layout e o fabrico do PCB, a assemblagem dos componentes no PCB e os testes de fiabilidade

do hardware no protótipo.

A quarta fase consiste no desenvolvimento do software residente no micro-controlador

(MCU) para a leitura dos dados obtidos pelos sensores e o protocolo de envio da informação,

via Bluetooth, para o dispositivo externo.

Na quinta fase realizam-se os testes e as validações do protótipo em ambiente real.

Por fim, elabora-se o presente documento que pretende detalhar todas as componentes

do projecto, principais conclusões obtidas, benefícios que representa para o contexto actual

de computação ubíqua, bem como as ciências em que o mesmo se enquadra (Context-aware

e AmI).

1.3 Requisitos gerais

Desenvolvimento de um sistema de aquisição de dados, obtidos por sensores, com os

seguintes requisitos mínimos: dimensões reduzidas (que permitam a sua utilização como um

artefacto pessoal); baixo consumo de energia (aproximadamente 75 mA); módulo de

comunicação Bluetooth (classe 1); MCU para processamento e aquisição de dados obtidos

através de sensores, com oito canais ADC de 10-bit, interface de comunicação SPI e I2C, e

interface de comunicação série (SCI) UART; alimentação do sistema por baterias (máximo 4

pilhas AAA de 1,5 V); versatilidade para ligar vários tipos de sensores, analógicos ou digitais,

tais como sensores de luminosidade, humidade, som, temperatura e aceleração.

Introdução 3

1.4 Estrutura da dissertação

O primeiro capítulo descreve as motivações associadas ao desenvolvimento deste

projecto, os objectivos associados ao mesmo, os requisitos gerais e a descrição da

estruturação do documento.

No segundo capítulo, procura-se realizar a contextualização do protótipo desenvolvido na

área da computação ubíqua, context-aware services em ambientes inteligentes, evidenciando

a sua utilidade para o ser humano nos dias de hoje. É realizada uma descrição de elementos

sensoriais e de sistemas já desenvolvidos, semelhantes ao protótipo deste projecto.

O capítulo seguinte – terceiro - descreve a arquitectura do sistema desenvolvida e os

sensores que foram utilizados no projecto.

O quarto capítulo apresenta a descrição da plataforma de hardware desenvolvida, tal

como as fases de desenvolvimento (captura esquemática e layout do PCB), os procedimentos

de ligação dos sensores ao protótipo desenvolvido, programação do MCU e a configuração do

módulo de comunicação Bluetooth.

O quinto capítulo descreve o software residente desenvolvido no MCU para aquisição de

dados obtidos através dos sensores, processamento da informação e envio da mesma para o

dispositivo externo.

O sexto capítulo apresenta as validações efectuadas ao hardware do sistema desenvolvido

e dos sensores utilizados no projecto. Adicionalmente são apresentadas validações efectuadas

a contextos adquiridos pelos sensores, através de uma aplicação desenvolvida em Visual Basic

a ser executada num computador para interpretação da informação recolhida pelos sensores,

e através de uma MIDlet1 a ser executada num dispositivo móvel.

O sétimo capítulo apresenta as conclusões do trabalho realizado e perspectivas de

desenvolvimento futuras.

Em anexo apresentam-se documentos relevantes na realização do projecto.

1 Aplicação em java para dispositivos móveis, mais especificamente J2ME.

Capítulo 2

Enquadramento

Esta secção procura fazer todo o enquadramento teórico sobre a computação ubíqua, os

ambientes inteligentes e o context-awareness demonstrando a importância da associação dos

elementos sensoriais a esses conceitos e os benefícios que os mesmos trazem ao actual

quotidiano. É ainda realizada uma análise de sistemas semelhantes ao protótipo desenvolvido

no projecto.

2.1 A ubiquidade da computação

O conceito da computação ubíqua foi introduzido no inicio dos anos 90 por Weiser e é

actualmente âmbito de vários estudos. Segundo Weiser, os recursos de computação estarão

omnipresentes na vida diária e conectados com o intuito de fornecer a informação ou serviços

que os utilizadores requerem em qualquer lugar e em qualquer momento.

A adopção crescente de dispositivos de comunicação móvel, como os telemóveis e os

PDA’s, é um indicador relevante da mobilidade que caracteriza a nossa sociedade actual, e a

penetração que essa mobilidade tem na mesma, é uma evidência da mudança do paradigma

da computação [2]. Actualmente, a orientação é ir para além da computação ubíqua (i.e., a

presença útil e discreta de dispositivos de computação em todo o lado) mas também a redes

ubíquas (i.e., acesso facilitado a redes em todo o lado) e a interfaces inteligentes (i.e.,

percepção do sistema pelas pessoas como sendo inteligente, que naturalmente interagem

com o sistema que automaticamente se adapta às suas preferências) [3]. A Figura 1 ilustra a

evolução que se tem vindo a assistir no universo da computação, desde a computação

centralizada (mainframe), pessoal, portátil até à ubiquidade da computação.

Enquadramento 6

Computação centralizada

Computação pessoal

Computação portátil

Computação ubíqua/ pervasiva

Orientação para a máquina

Um computadorMuitas pessoas

Orientação para a tarefa

Um computadorUma pessoa

Orientação para o utilizador

Muitos dispositivosUma pessoa

Orientação para o utilizador

Dispositivos “invisíveis”Muitas pessoas

Avanços tecnológicos de Hardware e

Software

Crescimento da Internet

2.2 Ambientes Inteligentes (Aml)

A área de AmI evoca um futuro próximo no qual as pessoas estarão rodeadas por

dispositivos (não intrusivos), que permitirão ao ser humano interagir com determinados

ambientes físicos, de uma forma inteligível. Estes ambientes deverão estar informados

quanto às necessidades das pessoas, adaptando requisitos e prevendo comportamentos. Os

ambientes de AmI podem ser tão diversos como casas, escritórios, escolas, hospitais, centros

de controlo, transportes, etc. [5].

Como em grande parte dos domínios das tecnologias, a aplicação da engenharia nas

ciências da saúde foi profundamente afectada pelos constantes avanços nas áreas da

electrónica, micro-electrónica e informática.

Os dispositivos de apoio e controlo médico podem estar integrados com as roupas dos

doentes, recolhendo informação de sinais vitais através de sensores (pressão sanguínea,

temperatura corporal, etc.). Os pacientes poderão ser monitorizados à distância. O ambiente

em que o paciente está inserido, por exemplo, a sua casa, pode inferir os resultados dos

dados clínicos recolhidos e ainda realizar chamadas de emergência [5].

Por exemplo, uma equipa de investigadores holandeses da Philips Electronics [6] [7]

desenvolveu um sensor que, colocado na roupa interior, vai permitir prevenir e melhorar a

saúde dos doentes cardíacos. Estes sensores vão medir os sinais emitidos pelo coração e

podem ser fixados dentro de sutiãs ou calças, ligados a um pequeno módulo de aquisição de

dados que mede os sinais.

Os sinais detectados pelos sensores são enviados, via Bluetooth, para o sistema de

aquisição de dados. A informação pode ser posteriormente analisada pelos médicos. No caso

de ataque cardíaco o sistema acciona um alarme local ou remoto (e.g. através do telemóvel).

Figura 1 - Evolução da computação [4]

Enquadramento 7

2.3 Context-awareness

O contexto e o context-awareness são conceitos chave nos ambientes inteligentes. A

disponibilidade de um contexto e o uso do mesmo em aplicações interactivas oferecem novas

possibilidades de desenvolvimento de aplicações e sistemas. [8]

Dey [10] define o contexto como qualquer informação que pode ser utilizada para

caracterizar uma situação de uma determinada entidade. Uma entidade pode ser uma

pessoa, um lugar ou um objecto que seja considerado como relevante para estabelecer uma

interacção entre um utilizador e uma aplicação.

O contexto não é simplesmente o estado de um ambiente pré-definido com um conjunto

fixo de interacções de recursos. É uma parte de um processo de interacção com um ambiente

em constante mutação composto por recursos reconfiguráveis, migratórios e multi-escalas

[9].

Dey [10] define context-aware computing da seguinte forma: “Um sistema que utiliza a

informação de contexto para fornecer informação relevante e/ ou serviços ao utilizador,

onde a relevância depende das tarefas do utilizador”. O context-aware computing refere-se a

capacidade que uma aplicação móvel possui, para inferir o conhecimento sobre vários

parâmetros de contexto, como quem é o utilizador, o que é que o utilizador está a fazer e

onde está o utilizador.

Um dos desafios da computação móvel é a exploração da mudança de ambientes com

aplicações que sejam capazes de inferir o contexto nas quais elas estão a ser executadas

[11].

Os sistemas de context-aware oferecem novas oportunidades para quem desenvolve

aplicações assim como para os utilizadores finais, através da recolha de dados de contexto e

a adaptação do sistema em conformidade com os dados recolhidos. Estes mecanismos podem

representar uma valorização acrescida para os dispositivos de comunicação móveis,

aumentando bastante a sua utilidade. [12]

2.3.1 Ciclo de vida de um contexto

Podemos interpretar que um fornecedor de informação de contextos entrega essa

informação a um sistema de context-aware seguindo as fases representadas na Figura 2. Os

principais passos no ciclo de vida da informação de contexto são [13]:

• Descoberta da informação do contexto – nesta fase, o sistema de context-aware

identifica os fornecedores de informação de contexto;

• Aquisição da informação do contexto – nesta fase, o sistema de context-aware recolhe

a informação do fornecedor de informação de contexto e processa a mesma para

posterior análise.

• Inferência sobre a informação do contexto – os mecanismos de inferência conferem às

aplicações a capacidade de interpretar a informação de contexto adquirida. A

inferência pode ser realizada baseada apenas numa única informação de contexto

isolada ou num conjunto de informações de contexto.

Enquadramento 8

Descoberta da informação do contexto

Aquisição da informação do contexto

Inferência sobre a informação do contexto

Figura 2- Ciclo de vida de um contexto [13]

O processamento de informação de contextos apresenta essencialmente dois desafios

[13]:

• O primeiro está relacionado com o carácter heterogéneo da informação de contexto:

o contexto poderá chegar de diferentes fornecedores de informação de contexto e

poderá ser de diferentes tipos;

• O segundo desafio prende-se com a segurança nos sistemas de context-aware.

2.3.2 Dimensões do contexto

Segundo Pashtan [16], um contexto pode ter quatro dimensões (Figura 3), em que cada

dimensão é descrita pelos seus respectivos parâmetros de contexto:

• Contexto Estático do Utilizador e Contexto Dinâmico do Utilizador – informação

relacionada com o utilizador e com a sua caracterização. Podemos incluir nesta

dimensão, a informação biométrica, como são exemplo as impressões digitais ou a

íris.

• Contexto de rede/ sistema – a aplicação móvel tem de ter em conta a informação do

contexto relacionado com o sistema de aquisição de dados, e.g., o tipo de dispositivo

e o sistema de comunicação a ser usado.

• Contexto do ambiente – Consiste em qualquer tipo de informação relacionada com o

contexto temporal (e.g. dia e hora) e com ambiente físico em geral, nomeadamente,

a luminosidade, temperatura, condições atmosféricas, etc.

Figura 3 - Dimensões de um contexto [14] [15]

Enquadramento 9

A fase de desenho da tecnologia de inferência de contextos para as aplicações é um

processo desafiante. Os serviços de inferência de contextos devem ser capazes de

compreender vários aspectos de situações actuais ou contextos e utilizá-los para interagir

com o utilizador de uma forma inteligente, através da combinação de diferentes tecnologias

como os dispositivos sensoriais, softwares inteligentes, tecnologias wireless, etc. [14]

2.3.3 Atributos da informação de contexto

Podemos identificar três propriedades principais de atributos da informação de contexto

[13], conforme ilustra a Figura 4:

• A persistência da informação de contexto: a informação de contexto estática não

muda (ou apresenta variações muito raras) – e.g. morada e nome do utilizador, etc.

Por outro lado, as mudanças na informação de contextos dinâmicos são muito mais

frequentes – e.g. tempo, localização do utilizador, etc.

• A origem da informação de contexto: a distinção entre informação de contexto

interna e externa é importante para a avaliação de, e.g., qualidade e fiabilidade da

informação. Por exemplo, no caso de a aplicação ser executava num telemóvel, a

informação de contexto que advém do próprio telemóvel é considerada como

informação interna (pode-se assumir como mais confiável); já a informação fornecida

por um operador GSM (e.g. localização do utilizador) é considerada como informação

de contexto externa.

• A qualidade da informação de contexto: a qualidade é um atributo bastante

importante e pode ser avaliada segundo vários parâmetros, sendo que a lista

apresentada na figura abaixo não é exaustiva.

Figura 4 - Atributos da informação de contexto [13]

Enquadramento 10

2.3.4 A segurança na informação de contexto

Não constitui uma surpresa o facto de a maioria das pessoas não gostarem da ideia de

serem localizadas com precisão em qualquer momento, por qualquer pessoa e principalmente

quando os dados de localização são registados.

Neste sentido, a segurança de um sistema de context-aware torna-se um tema de

extrema relevância.

Existem três critérios essenciais em termos de segurança de sistemas [17]:

• Confidencialidade – propriedade que é violada quando a informação é divulgada a

entidades não autorizadas;

• Integridade – propriedade que é violada quando a informação é alterada de uma

forma não autorizada; e

• Disponibilidade garantia de que a informação deve estar disponível para as entidades

autorizadas.

2.3.5 Elementos sensoriais

Os sensores são os dispositivos que permitem a aquisição da informação dos contextos,

necessários para a inferência dos mesmos. Eles podem medir factores como a temperatura, a

luminosidade, o campo eléctrico, a humidade, a vibração, batimentos cardíacos, entre

muitos outros factores físicos.

Existem vários tipos de sensores que adquirem a informação e a transmitem de formas

diferentes:

• Sensores analógicos - adquirem a informação de um contexto e enviam a informação

para o sistema de aquisição de dados numa grandeza analógica, sendo a leitura

efectuada pelo sistema de aquisição de dados através de conversores analógicos

digitais (ADC). No projecto desenvolvido, foram integrados sensores de temperatura,

luminosidade e som deste tipo de tecnologia. Sensores digitais - adquirem a

informação de um contexto e enviam a informação numa grandeza digital para o

sistema de aquisição de dados, sendo a leitura efectuada pelo sistema de aquisição de

dados através de protocolos digitais, como por exemplo, SPI e I2C. No projecto

desenvolvido, foi integrado um sensor de aceleração (acelerómetro) e temperatura

com interface digital SPI.

• Sensores com tecnologia de comunicação sem fios – entre as várias tecnologias sem

fios utilizadas em sensores, podemos destacar as tecnologias Bluetooth [25] e ZigBee

[18]. Ambas as tecnologias referidas permitem a transmissão de dados em redes

pessoais sem fios, designadas também por Wireless Personal Area Network (WPAN).

• Tecnologia Zigbee – desenvolvida pela ZigBee Alliance, baseia-se na norma IEEE

802.15.4 e assume actualmente um papel relevante no desenvolvimento de

ambientes inteligentes, devido ao seu baixo custo de implementação, baixa

complexidade, baixo consumo de energia, fiabilidade e auto-suficiência. Foi

concebida para ser a tecnologia mais simples e económica das redes WPAN’s já

existentes. É direccionada para aplicações que requerem pouca largura de banda e

Enquadramento 11

baixo consumo de energia. As baterias que alimentam um dispositivo ZigBee

poderão durar meses ou até anos. Existem vários tipos de sensores com esta

tecnologia, tais como temperatura, luminosidade e humidade.

• Tecnologia Bluetooth – Neste projecto foi utilizada a tecnologia Bluetooth para a

comunicação do dispositivo de aquisição de dados com o dispositivo externo. Na

secção 3.2 Módulo de comunicação Bluetooth detalha-se esta tecnologia.

Dos diferentes tipos de sensores referidos acima, os sensores com tecnologia de

comunicação sem fios, permitem a implementação de estruturas dinâmicas e flexíveis para a

aquisição e transmissão de dados adquiridos de um determinado ambiente.

2.4 Trabalhos relacionados

Esta secção pretende apresentar dois projectos, UPCASE e BlueHome, que se baseiam em

sistemas de aquisição de dados com a mesma aplicabilidade do protótipo desenvolvido no

projecto. Ambos utilizam um MCU para a aquisição e processamento da informação obtida

através de elementos sensoriais, um módulo de comunicação sem fios Bluetooth para o

envio/ troca de informação com dispositivos externos e um baixo consumo de energia.

Nas subsecções abaixo apresenta-se uma breve descrição dos projectos acima referidos,

nomeadamente, o âmbito em que se enquadram e as características de hardware dos

sistemas de aquisição de dados utilizados,

2.4.1 Projecto UPCASE [19]

O projecto UPCASE (User-Programmable Context-Aware Services) centra-se no âmbito da

investigação e desenvolvimento de métodos de recolha e inferência de contextos, tendo por

base um conjunto de sensores (utilizáveis pelas pessoas) ligados a um sistema de aquisição de

dados que envia a informação dos contextos, via Bluetooth, para um dispositivo móvel. A

partir destes sensores, será possível realizar inferência automática de contextos relacionados

com o utilizador, de forma a possibilitar a criação de serviços conscientes do contexto.

Este projecto ambiciona o desenvolvimento de um protótipo capaz de gerar

dinamicamente informação de contexto a partir de telemóveis, de uma forma segura e

controlada pelo utilizador. Um dos principais objectivos é, portanto, o desenvolvimento de

um algoritmo robusto para determinar de forma precisa o contexto do utilizador.

A camada aplicacional foi desenvolvida utilizando o Java ME platform2, tecnologia

bastante utilizada devido à sua reconhecida compatibilidade com vários dispositivos móveis.

Num primeiro nível, os sensores recolhem os dados do ambiente e fornecem-nos na forma de

sinais analógicos para dispositivo de aquisição de dados (BlueSentry [20]), que os converte

para sinais digitais e os transmite para o dispositivo móvel, via Bluetooth. O sistema operativo

2 http:/java.sun.com/javame

Enquadramento 12

do telemóvel suporta a execução da aplicação em Java. Foi ainda desenvolvido neste

projecto uma aplicação MIDP (Mobile Information Device Profile) que adquire dados dos

sensores do BlueSentry.

Módulo de aquisição

O dispositivo móvel envia um pedido para o BlueSentry para recolher os dados dos

sensores ligados ao mesmo, em intervalos regulares. As leituras dos sensores são enviadas

para o dispositivo móvel, para posteriormente se efectuar a inferência da informação. Os

sensores podem ter diferentes taxas de aquisição no BlueSentry. A diferença na frequência de

amostragem pode levar a que a aquisição seja executada a um ritmo mais lento, ou a taxas

individuais para cada sensor. No projecto UPCASE, foi utilizada a mesma taxa de aquisição

para todos os sensores.

A inferência de contextos com árvores de decisão

As árvores de decisão são estruturas que têm o propósito da inferência de contextos e são

fáceis de construir e processar, o que as torna atractivas para implementar em dispositivos

móveis.

A árvore de decisão é inicialmente construída com base num conjunto de regras pré-

definidas de contextos (Figura 5), sendo actualizada à medida que o utilizador testa o sistema

com novos contextos.

Acelerómetro

Som

Nenhuma deslocação

Muito silêncio

Moderado

Elevado

Temperatura Temperatura

DeslocaçãoDeslocação

rápida

Correr no interior

Correr no exterior

Andar no interior

Andar no exterior

LuzLuz

Moderada Baixa Moderada Baixa

ReuniãoTrabalharTempo

DescansarDormir

Claro

Muito escuro Muito

claroMuito claro

NoiteMadrugada Tarde

Figura 5 - Exemplo de árvore de decisão induzida [19]

Contextos já conhecidos poderão ser renomeados ou apagados à medida que o sistema

fornece meios ao utilizador para gerir os contextos existentes. Isto permite que o utilizador

Enquadramento 13

possa eliminar um contexto conhecido e teste o sistema novamente, ou simplesmente apague

um contexto não utilizado.

No projecto UPCASE, foi elaborado um cenário de teste de aquisição de dados de quatro

contextos diferentes (dormir, trabalhar, realizar exercício e conduzir), através de sensores de

som, luminosidade, temperatura, aceleração e tempo. Este cenário permitiu realizar a

indução de uma árvore de decisão, apresentada na Figura 6.

Tempo

Som

Acelerómetro

Dormir Andar

Trabalhar

Conduzir

Conduzir Trabalhar

Deslocação rápida Deslocação

Nenhuma deslocação

Tarde Madrugada Manhã

Muito silêncio

Silêncio Som moderado Som

elevadoSom muito

elevado

Figura 6 - Árvore de decisão induzida pelas leituras do cenário teste [19]

Sistema de aquisição de dados – BlueSentry

O BlueSentry é o sistema de aquisição de dados utilizado pelo projecto UPCASE. O

dispositivo comunica com dispositivos externos através de comunicação sem fios Bluetooth e

permite a integração de sensores com interface analógica para a aquisição dos contextos

através dos seus 8 canais de conversão analógico-digital (ADC). O módulo Bluetooth do

sistema pertence à Classe 1 (no Capítulo 3 descrevem-se as classes de Bluetooth).

A alimentação do BlueSentry é realizada através de 4 pilhas AAA de 1,5 V encastradas e o

sistema é de baixo consumo de energia (cerca de 75 mA). A Tabela 1 apresenta as principais

características deste dispositivo e a Figura 7 apresenta fisicamente o mesmo.

Enquadramento 14

Figura 7 - Dispositivo de aquisição de dados BlueSentry [20]

Tabela 1 - Características do dispositivo BlueSentry

Dispositivo BlueSentry

Dispositivo RN-800S-AD

Dimensões 1,6” x 3,0” x 0,9” [(40,5 x 76,2 x 22,86) mm]

Canais 8 canais A/D de entrada de 16 bit com tensão de 0-5 VDC e

frequência de amostragem até 3000 Hz

Transmissão Bluetooth Classe 1 (100 m) e antena integrada

Alimentação Baixa potência, 6 a 12 VDC (75 mA) com 4 AAA

Comunicação

série Bluetooth Com suporte de SPP

Consumos Standby – 20 mA (BT off), 40 mA (BT on); ligado – 60 mA (BT

on); hibernado – 11 mA.

2.4.2 Projecto BlueHome [21]

O BlueHome é um sistema composto por um dispositivo electrónico (hardware) e um

software para dispositivos móveis (e.g. telemóvel), que pretende auxiliar pessoas idosas e

deficientes. O hardware do sistema BlueHome possui um módulo Bluetooth para a

comunicação sem fios entre o MCU e o dispositivo móvel. O software desenvolvido para o

dispositivo móvel permite o controlo de diferentes aparelhos electrónicos e a análise de

dados obtidos através de sensores ligados ao MCU.

Com este sistema, pessoas idosas e deficientes sentem-se mais autónomas dado que, sem

a ajuda de terceiros conseguem:

• Monitorizar e controlar electrodomésticos;

• Promover a própria segurança com a ajuda de sensores de movimentos (com alarmes

de voz);

• Enviar notificações em caso de emergência;

• Verificar temperaturas do interior e do exterior;

Enquadramento 15

• Ligar/desligar o ar condicionado;

• Ligar/desligar a luz do quarto; e

• Controlar janelas/portas de acesso.

O hardware do BlueHome liga directamente ao sistema que se pretende controlar. O

software que é instalado no dispositivo móvel permite ao utilizador controlar determinado

dispositivo ou obter determinada informação do sistema. As instruções de execução para o

hardware são enviadas, via Bluetooth, através das instruções seleccionadas na aplicação do

dispositivo móvel.

A aplicação comunica com os sensores que estão associados ao hardware.

A informação dos sensores é actualizada automaticamente no software do dispositivo móvel

através das informações obtidas pelo sistema. Todas as operações dos sensores são

controladas pelo MCU. Os sensores do sistema BlueHome incluem: sensor de temperatura

interior, sensor de temperatura exterior, sensor de luminosidade, sensor de movimento ou

Passive InfraRed (PIR) e sensores de portas.

Sistema de aquisição de dados - BlueHome

O dispositivo permite a aquisição de dados obtidos através de sensores e o controlo de

dispositivos electrónicos. Contém um módulo de comunicação sem fios Bluetooth para a

comunicação a comunicação com dispositivos externos.

A Tabela 2 apresenta as principais características deste dispositivo e a Figura 8 apresenta

fisicamente o mesmo.

Figura 8 - Dispositivo BlueHome [21]

Enquadramento 16

Tabela 2 - Características do dispositivo BlueHome

Dispositivo BlueHome

Dispositivo ATmega8A

Módulo Bluetooth BlueSMiRF (Bluetooth Classe 1, 100 m)

Memória Flash 8 KByte

SRAM 1 KByte

EEPROM 512 Bytes

Canais ADC 8 canais de 10 bit

Processamento de

instruções por segundo Até 16 MIPS

Consumo do MCU a 4

MHz, 3,3 V e 25 ºC 3,6 mA (Activo); 1,0 mA (standby); 0,5 uA (power-down)

Consumo do módulo

Bluetooth 25 mA (médio)

Capítulo 3

Descrição do sistema desenvolvido

O sistema é constituído pelo MCU PIC18F14K22 da Microchip [22], que funciona como

dispositivo de aquisição e processamento de sinais analógicos e digitais obtidos através de um

conjunto de sensores de luminosidade, temperatura, humidade, som e aceleração, e que

permitem a recolha e inferência dos contextos em que um determinado utilizador se

encontra. O MCU utiliza a tecnologia nanoWatt eXtreme Low Power (XLP) [23] de MCU’s de 8-

bit de alto desempenho e de baixo consumo de energia da Microchip. O sistema ainda integra

um módulo de comunicação sem fios BlueSMiRF [24] que permite a comunicação entre o MCU

e dispositivos externos (e.g. dispositivos móveis), via Bluetooth. O módulo de alimentação do

sistema permite que o mesmo seja alimentado através de baterias, viabilizando a sua

mobilidade.

A Figura 9ilustra toda a arquitectura do sistema, bem como os módulos de comunicação

sem fios Wi-Fi e ZigBee, possíveis de implementar.

Figura 9- Descrição do sistema

Descrição do Sistema 18

3.1 MCU PIC18F14K22 da Microchip

O PIC18F14K22 foi o MCU seleccionado para o desenvolvimento deste projecto. As suas

características respeitam os requisitos mínimos definidos na fase de planeamento da

concepção do projecto.

Este MCU existe em vários tipos de encapsulamento. Para este projecto foi seleccionado o

encapsulamento do tipo PDIP (Plastic Dual In-line Package), pelo facto de permitir a retirada

do MCU do PCB, para programação do mesmo através de um programador externo, e pelo

facto de proporcionar uma maior facilidade de assemblagem no PCB do protótipo, conforme

especificação inicial do projecto.

Como referido anteriormente, este MCU pertence à família de MCU’s da tecnologia

nanoWatt XLP da Microchip. Os MCU’s desta tecnologia são considerados os de menor

consumo de energia em modo sleep - cerca de 20 nA. Permite a alimentação do MCU por

baterias (conforme os requisitos técnicos definidos para este projecto) e uma maior

durabilidade da(s) bateria(s), potenciada pelo seu baixo consumo de energia. Dentro da

família de MCU da tecnologia nanoWatt XLP, o PIC18F14K22 proporciona aplicações de

elevado desempenho para MCU de 8-bit.

Tabela 3 - Características do PIC18F14K22

Dispositivo: PIC18F14K22

Memória de programa

Bytes 16 K

Instruções 8 K

Memória de dados

SRAM 512 bytes

EEPROM 256 bytes

Frequência de funcionamento 16 MHz a 64 MHz

Pinos 20

Entradas e Saídas 18

Canais A/D 10-bit 12

MSSP3 SPI e I2C

EUSART 1

Consumo

Máx.a 64 MHz e 5V 14,6 mA

Modo Sleep 34 nA

3Módulo Mater Synchronous Serial Port.


Na Tabela 3 referem-se as características mais relevantes que levaram à escolha do

PIC18F14K22. As funcionalidades de 12 canais ADC de 10-bit e as interfaces de comunicação

SPI e I2C foram muito relevantes para a escolha deste MCU, visto que possibilitam a

integração de um vasto número de sensores face aos requisitos estabelecidos para o projecto.

A compatibilidade da interface EUSART (Enhanced Universal Synchronous Asynchronous

Receiver Transmiter) com a interface UART (Universal Asynchronous Receiver Transmiter) do

módulo de comunicação BlueSMiRF, a possibilidade de armazenamento de informação na

memória de dados e as frequências de funcionamento também foram factores decisivos para

a escolha deste MCU.

A possibilidade de armazenamento de dados do MCU torna-se relevante no sentido de se

poder armazenar dados adquiridos pelos sensores e posteriormente efectuar o download dos

mesmos para uma aplicação externa ao MCU (e.g. aplicação no telemóvel).

3.1.1 Oscilador

O MCU possui um oscilador interno com frequência de funcionamento a 16 MHz, com a

possibilidade de, programando por software a Malha de Captura de Fase (PLL), atingir um

aumento da performance de funcionamento até 64 MHz (4 x PLL) e, consequentemente, a

execução de 64 milhões de instruções por segundo (MIPS). O MCU permite a utilização de

osciladores externos para funcionamento do mesmo noutras frequências.

No protótipo utilizou-se o MCU com o oscilador interno programado a 16 MHz visto ser

uma frequência que permite obter um bom desempenho para as operações que o sistema

deve desempenhar, proporcionando-se desta forma a redução do consumo de energia. O MCU

programado a 16 MHz permite a execução de 16 MIPS.

3.1.2 Conversor Analógico Digital

Os 12 canais ADC do MCU possuem uma resolução de 10-bit. Permitem a leitura de uma

grandeza analógica dentro de uma gama de 0 V a 5 V, adquirindo 1024 valores e convertendo

essa leitura numa grandeza digital (0s e 1s), para processamento da informação no MCU.

3.1.3 Interface SPI

A interface de comunicação digital SPI permite a troca/ aquisição de dados entre o MCU e

dispositivos electrónicos que possuam o mesmo interface de comunicação SPI (e.g. o sensor

de aceleração e temperatura utilizado no projecto). É um protocolo de comunicação síncrono

Master-Slave que permite um dispositivo Master iniciar a comunicação com um ou mais

dispositivos em modo Slave, para a troca/ aquisição de informação. A interface de


comunicação SPI é composta pelos seguintes quatro sinais: sinal de relógio (SCK – Serial

Clock), sinal de entrada de dados (SDI – Serial Data In, MISO – Master Input Slave Output),

sinal da saída de dados (SDO – Serial Data Out, MOSI – Master Output Slave Input) e sinal de

configuração de modo Slave (SS – Slave Select)

A comunicação SPI funciona de modo síncrono (hall duplex) e os dados são transferidos

normalmente por 8 bits, sendo que a transmissão pode ser iniciada pelo bit menos

significativo (LSb) ou mais significativo (MSb), com a possibilidade de variar conforme o

dispositivo. O dispositivo Master é o que inicia a comunicação com o dispositivo Slave,

através do controlo do pino SS (colocando o pino no estado lógico 0), e controla o sinal de

relógio para o dispositivo Slave, através do pino SCK. A troca de dados é realizada através dos

pinos SDI e SDO. Após realizadas todas as operações, o dispositivo Master finaliza a

comunicação, interrompendo o envio do sinal de relógio e desactivando o dispositivo Slave

(colocando o pino SS no estado lógico 1).

Existem várias tipologias de ligação Master-Slave do protocolo SPI. As figuras abaixo

(Figura 10, Figura 11e Figura 12) apresentam as mesmas.

A Figura 10 ilustra uma ligação simples Master-Slave entre dois dispositivos a

comunicarem por interface SPI. Neste caso só é necessário ligar os 4 sinais apresentados na

figura.

Figura 10 - Ligação Simples SPI Master-Slave

A Figura 11 ilustra uma ligação Master-Salve em cascata, nesta tipologia todos os dados

são enviados sucessivamente de dispositivo Slave em dispositivo Slave. Os dispositivos Slave

partilham o mesmo sinal de relógio (SCK) e configuração (SS).


Figura 11 - Ligação Master-Slave em cascata

A Figura 12 ilustra uma ligação Master-Salve independente. Nesta tipologia todos os

dispositivos Slaves são seleccionados de forma independente. O dispositivo Master possui um

sinal SS dedicado para cada dispositivo Slave.

Figura 12 - Ligação Master-Slave independente

No projecto utilizou-se a ligação simples Master-Slave visto ser utilizado um único

dispositivo Slave (sensor de aceleração e de temperatura), no entanto é possível alterar a

configuração para as outras tipologias referidas anteriormente.

Na secção 3.5.4 Sensor de temperatura e aceleração apresenta-se detalhadamente o

funcionamento do protocolo SPI ao nível dos sinais SS, SCK MOSI e MISO.

3.1.4 Interface EUSART

A Universal Synchronous Asynchronous Receiver Transmiter (USART), também conhecida

por interface de comunicação série (SCI), permite a comunicação do MCU com dispositivos

externos (e.g. computadores e módulos de comunicação). O PIC18F14K22 possui a interface

Enhanced Universal Synchronous Asynchronous Receiver Transmiter (EUSART), uma versão

actualizada da USART. A EUSART implementa recursos adicionais ideais para uso em sistemas

de barramento Local Interconnect Network (LIN), tais como: fornecer suporte de hardware


extra para detecção e calibração automática da taxa de transmissão de dados, de modo a que

sistemas que utilizem osciladores pouco dispendiosos (com larga tolerância de frequência)

possam ser suportados; e permitir o Wake-up na interrupção de recepção.

A SCI pode ser configurada em modo de funcionamento assíncrono e síncrono. A utilização

do modo de funcionamento assíncrono (full-duplex) é normalmente utilizada quando se

pretende comunicar, por exemplo, com um computador pessoal. O modo de funcionamento

síncrono (half-duplex) permite a comunicação com outros dispositivos, tais como ADC e

EEPROM série.

A EUSART do MCU utiliza os seguintes três sinais: Transmit Status and Control (TXSTA),

para a transmissão de dados; Receive Status and Control (RCSTA), para a recepção de dados;

e Baud Rate Control (BAUDCTL), para controlo do taxa de transmissão. A comunicação entre

o MCU e o módulo BlueSMiRF utiliza apenas os sinais TXSTA e RCSTA.

O MCU permite a configuração de várias taxas de transmissão de dados. A SCI entre

dispositivos deve utilizar a mesma taxa, de modo a garantir a compatibilidade da

comunicação entre os mesmos.

No projecto, configurou-se a taxa de transmissão de dados do MCU a 9600 bps para

comunicação com o módulo BlueSMiRF, o que significa que o período de transmissão (T) de

cada bit é de T=1/9600 = 104,17 µs.

3.2 Módulo de comunicação Bluetooth

A tecnologia Bluetooth (baseada da norma IEEE 802.15.1) [25] ermite a comunicação sem

fios entre dispositivos electrónicos, substituindo a comunicação por cabo. Existem 3 tipos de

classes Bluetooth [26] [27], baseadas nas diferentes potências máximas de transmissão e

alcances (ver Tabela 4). Para este projecto foi seleccionado o circuito integrado RN-41, de

comunicação Bluetooth, da Roving Networks [20], integrado no módulo BlueSMiRF, por possuir

a Classe 1 da tecnologia Bluetooth (requisito do projecto). Esta classe permite que o

dispositivo de aquisição de dados possa ser alcançado pelos dispositivos externos no maior

raio de alcance disponível por esta tecnologia.

Tabela 4 - Características das classes Bluetooth

Classes Potência máxima de transmissão Alcance (aproximado)

Classe 1 100 mW (20 dBm) Até 100 m

Classe 2 2.5 mW (4 dBm) Até 10 m

Classe 3 1 mW (0 dBm) Até 1 m


O RN-41 possui as características relevantes para a comunicação Bluetooth exigidas para

este projecto, tais como:

• Classe 1 da tecnologia Bluetooth;

• Baixo consumo de energia;

• SCI (via Bluetooth) entre o MCU e dispositivos externos; e

• Compatibilidade entre os sinais de transmissão e recepção da SCI (física) do RN-41 e o

MCU.

Dada a assemblagem complexa do encapsulamento do módulo RN-41, adquiriu-se o

módulo de comunicação BlueSMiRF que consiste num PCB que integra o RN-41 e disponibiliza

os sinais da SCI para ligar o mesmo ao PCB do MCU desenvolvido. Permite ainda ser

alimentado a 5 V (alimentação standarizada no PCB do projecto).

A Tabela 5 apresenta um conjunto de características detalhadas sobre o módulo

BlueSMiRF utilizado no projecto. De realçar a compatibilidade de funcionamento em outros

ambientes de radiofrequência (RF) como Wi-Fi e Zigbee, baixo consumo de energia,

comunicação encriptada e dimensões reduzidas.

Tabela 5 - Características do módulo BlueSMiRF

Dispositivo BlueSMiRF

Distância de transmissão 100 m (Classe 1 Bluetooth)

Frequência de funcionamento De 2.4 a 2.524,00 GHz

Comunicação série De 2400 a 115200 bps

Funciona em ambiente com outros sinais de RF WiFi, 802.11g e Zigbee

Comunicação Encriptada

Alimentação de funcionamento 3,3 V a 6,0 V

Temperatura de funcionamento -40 ~ +70C

Consumo médio 25 mA

Dimensões 0,15x0,6x1,9”

(3,81x15,24x48,26 mm)

Antena Integrada

A Figura 13 apresenta o pinout disponível no módulo BlueSMiRF e a Tabela 6 descreve os

sinais associados ao mesmo.


Figura 13- Pinout do módulo BlueSMiRF

Tabela 6 - Pinout do módulo BlueSMiRF

Sinais Detalhe

CTS-I

(Clear-To-Send): Controlo de fluxo de hardware (se não for utilizado liga-se a RTS-O).

VCC: 3,3 V a 6,0 V

GND: GND do circuito

TX-O: Transmissão de dados a partir do BlueSMiRF, saída série. Normalmente

liga-se ao pino RX de um micro-controlador ou UART equivalente.

RX-I: Recepção de dados para o BlueSMiRF, entrada série. Normalmente liga-

se ao pino TX de um micro-controlador ou UART equivalente.

RTS-O

(Ready-To-Send): Controlo de fluxo de hardware (se não for utilizado liga-se a CTS-I).

A SCI entre o dispositivo externo e o módulo Bluetooth é realizada através da função

Serial Port Profile (SPP) [29], da stack do Bluetooth, que emula a ligação série RS-232 por

cabo. Configurou-se a taxa de transmissão da SCI do Módulo Bluetooth para o MCU a 9600 bps

para compatibilidade da comunicação com o mesmo.

O circuito integrado RN-41 tem a possibilidade de comunicar com um MCU via interface

USB (HCI - Host Controller Interface) - esta funcionalidade não está disponível nos sinais

disponibilizados pelo pinout do PCB do BlueSMiRF. O RN-41 ligado por interface HCI com MCU

permite um débito nominal de comunicação de dados até 3,0 Mbps.

A SCI entre o BlueSMiRF e o MCU utiliza apenas os sinais TX-O e RX-I do BlueSMiRF. O sinal

TX-O do BlueSMiRF pode ser ligado directamente ao sinal RCSTA do MCU, no entanto à saída

do sinal TXSTA do MCU, teve que se efectuar um divisor de tensão para garantir que a tensão

do sinal não excedesse as especificações do RX-I do RN-41. No Capítulo 1 é descrito o divisor

de tensão efectuado, no detalhe do esquema eléctrico.


3.3 Interface de programação ICSP

No protótipo implementou-se a interface In-Circuit Serial Programming (ICSP) [30] que

permite a programação do MCU on-board. Para implementar esta interface foi necessário

disponibilizar um conector no PCB com os sinais necessários para ligar ao programador

PICkitTM 2 da Microchip [31], que comunica por interface USB para o computador.

Os sinais necessários para implementar a interface ICSP são: os pinos PDG, PGC e MCLR do

MCU, e VCC e GND do sistema.

3.4 Módulo de alimentação e alimentação externa

O módulo de alimentação interno (regulador de tensão) do sistema é constituído por um

regulador Low Dropout (LDO) que ao ser alimentado com uma tensão superior à requerida

pelo sistema, produz uma tensão de alimentação com o valor dimensionado para o sistema

funcionar.

O LDO escolhido para o projecto é o MCP1825S-5002E/AB [32] da Microchip, que permite

alimentar o sistema com 4 pilhas AAA de 1,5V à entrada do LDO e obter 5 V à saída do LDO. A

corrente máxima fornecida pelo regulador LDO é de 500 mA, que responde à exigência total

de consumo de energia requerida pelos diversos dispositivos electrónicos do sistema (cerca de

65 mA).

A especificação eléctrica da alimentação externa para o sistema funcionar é a

mencionada na seguinte especificação:

Vin4>=Vout

5(Máx) + VDropout(Max), sendo Vin inferior ou igual a 6 V e VDropout(Max)

6 igual a 210 mV a

500 mA.

A tensão de dropout do LDO escolhido para o projecto é muito baixa em comparação com

outros reguladores LDO disponíveis no mercado, pelo que permite que o diferencial da tensão

de entrada versus a tensão de saída seja muito reduzido.

O protótipo deste projecto é alimentado externamente através de 4 pilhas AAA de 1,5 V

encastradas.

4 Tensão de entrada. 5 Tensão de saída. 6 Diferencial de tensão entre a entrada e a saída para que o LDO funcione na zona linear.


3.5 Sensores

Para a aquisição de contextos de um determinado ambiente em que um utilizador se

encontra, podem ser utilizados vários tipos de sensores. Para este projecto, consideraram-se

sensores de temperatura, humidade, luminosidade, som e de aceleração, conforme as

especificações definidas.

O protótipo permite a integração de outros tipos de sensores para aquisição de outros

contextos, para além dos adquiridos pelos sensores implementados no projecto (e.g. sensores

de pressão sanguínea e/ou de batimento cardíaco).

Foram utilizados sensores analógicos, nos quais a leitura no MCU dos valores medidos

pelos mesmos é realizada através de um ADC, e sensores digitais, nos quais a leitura no MCU

dos valores medidos pelos mesmos é realizada através da interface digital SPI.

Na Bill of Materials (BOM), Anexo 2, é possível ver onde se podem adquirir os sensores

utilizados para o projecto.

De seguida descrevem-se as características que estiveram na origem da escolha dos

sensores implementados.

3.5.1 Sensor de luminosidade

O sensor de luminosidade permite medir a percentagem de luminosidade de um contexto.

Para este sensor seleccionou-se uma Light Dependent Resistor (LDR) NSL 19M51 [33] da

Silonex Inc, célula fotoeléctrica que permite fazer a leitura analógica da intensidade

luminosa através da variação da resistência da LDR. A resistência da LDR diminui com o

aumento da intensidade luminosa e aumenta com a diminuição da intensidade luminosa. A

Tabela 7 apresenta as especificações da LDR.

Para ligar a LDR ao ADC foi necessário efectuar um divisor de tensão com a LDR e uma

resistência de 3300 Ω, como apresenta a Figura 14.


Tabela 7 - Características do sensor de luminosidade

Dispositivo: NSL 19M51

Alimentação 5 V

Temperatura de funcionamento -60 a 70 ºC

Dissipação de Potência @ 25 ºC 50 mW

Corrente Máxima 500 uA

Tensão de saída 0 a 5V

RL (resistência na claridade) 20 a 100 kΩ @ 10 Lux

RL (Típico) 5 kΩ @ 100 Lux

RD (resistência no escuro) 20 MΩ

Tempo de resposta no escuro 10s após luz desligada

Figura 14 - Divisor de tensão do sensor de luminosidade

Na Figura 14 a RL é o valor da resistência da LDR que varia consoante a intensidade

luminosa que incide sobre a célula fotoeléctrica.

O valor que o canal ADC do MCU lê é a tensão que resulta do divisor de tensão, em que a

fórmula é descrita abaixo.

VADC = 3300*VCC/(RL+3300)

A resistência RL tipicamente é igual a 500/Lux kΩ. Substituindo RL = 500/Lux kΩ e VCC =

5 V, na fórmula anterior, surge a equação de medição da luminosidade (em Lux)

implementada no MCU:

f(x) = (2500/x-500)/3,3, em que x é o valor da tensão de entrada no ADC.

A Figura 15 apresenta o PCB desenvolvido para o sensor de luminosidade. O esquema

eléctrico do sensor é a apresentado na Figura 14. O PCB disponibiliza o sinal VADC que liga ao

ADC do MCU e os sinais de VCC e GND que ligam à alimentação do sistema.


Figura 15 - Sensor de luminosidade

A Figura 6 apresenta as características de medição da intensidade em Lux relativamente

à variação da resistência da LDR.

Figura 16 - Características da variação da RL versus luminosidade (Lux)

3.5.2 Sensor de humidade

O sensor de humidade permite inferir a percentagem de humidade de um contexto.

Para este sensor, seleccionou-se o HU1015NA [34] da GE Sensing & Inspection

Technologies, com as características apresentadas na Tabela 8.

A percentagem de humidade neste projecto é medida através da humidade relativa (%

RH). Este sensor disponibiliza um vasto intervalo de medição: 10 - 100 % RH.

A importância desta medição reflecte a capacidade do ar de admitir mais ou menos vapor

de água o que, em termos de comodidade ambiental, expressa a capacidade de evaporar a

transpiração, importante para regular a temperatura do corpo humano.


Tabela 8 - Características do sensor de humidade

Dispositivo: HU1015NA

Alimentação 5,0 V ± 0,2 V

Temperatura de funcionamento 0-50º C

Humidade 10 - 100 % RH

Corrente Máxima 2 mA

Tensão de saída 1 a 3 V

Precisão

25-90% RH @ 25 ºC < ±5 % RH

outros intervalos < ± 10 % RH

Tempo de resposta típico 5 min.

Para medir a percentagem de humidade deste sensor através do ADC foi implementada a

seguinte equação:

f(x) = (x-0,88)/0,02, em que x é o valor da tensão de entrada do ADC.

A Figura 17 apresenta as características de medição da percentagem de humidade

relativa (% RH) em relação à tensão de saída do sensor de humidade, com base na equação

acima apresentada.

Figura 17 - Características típicas da tensão de saída do sensor de humidade a 25º


A calibração da medição da percentagem de humidade pode ser realizada através do

ajuste da constante 0,88 da equação linear acima apresentada para outros valores.

A Figura 18 apresenta o sensor de humidade utilizado no projecto.

Figura 18 - Sensor de Humidade HU1015NA [34]

Para integrar o sensor de humidade com o sistema de aquisição de dados foi necessário

desenvolver um pequeno PCB de forma a seguir as recomendações do fabricante. No Capítulo

1 apresenta-se o PCB desenvolvido.

3.5.3 Sensor de som

O sensor de som permite medir a intensidade de ruído de um determinado contexto. Para

este projecto, seleccionou-se o sensor de som que integra circuito integrado OPA344 [35] da

Texas Instruments, que permite fazer a leitura analógica de ruídos captados pelo microfone

do sensor.

A importância desta medição reflecte na capacidade de se conseguir detectar ruídos

ambientes tais como: sons de voz, bater de portas, etc.

Para medir a detecção de ruído, utiliza-se o valor da tensão lida pelo ADC do MCU e

converte-se a mesma numa escala de 0 a 1023, que representa o nível de ruído.

A Tabela 9 apresenta as características do sensor de som.


Tabela 9 - Características do sensor de som

Dispositivo: OPA334

Alimentação 2,7 a 5,5 V

Ganho da largura de banda 0,1 Hz a 1 MHz

Ganho em decibel (dB) 0 a 120 dB

Slew Rate7 0,8 V/µs

Tensão de saída 0 a 5,0 V

A Figura 19 apresenta o sensor de som utilizado no projecto. O sensor integra o circuito

integrado OPA 334 e um microfone para a captura do ruído do ambiente. O sinal AUD liga ao

ADC do MCU e os sinais VCC e GND à alimentação do sistema.

Figura 19 - Sensor de som

No Anexo 4 apresenta-se o esquema eléctrico do sensor de som.

3.5.4 Sensor de temperatura e aceleração

O sensor de temperatura e aceleração estão integrados no mesmo dispositivo electrónico

- SCA3000-D01 [36] da VTI Technologies. A leitura dos valores obtidos pelos sensores é

realizada através da interface digital SPI com o MCU. O acelerómetro permite inferir

contextos tais como estados de movimento e posições de um determinado utilizador, bem

como a detecção de movimento e de queda livre. O sensor de temperatura permite medir a

temperatura ambiente em que se encontra um determinado utilizador.

A Tabela 10 apresenta as características do sensor.

7 Taxa de variação de um sinal de saída de um amplificador por unidade de tempo.


Tabela 10 - Características do sensor de temperatura e aceleração

Dispositivo: SCA3000-D01

Alimentação 3,35 a 10,0 V

Interface de comunicação SPI máximo 1.6 Mhz

Aceleração eixo XYZ ±2 g8

Sensibilidade 1333 valores/g

Resolução 0,75 mg / 0,04 ºC

Detecção de movimento Sim

Detecção de queda livre Sim

Temperatura - 40 a 125 ºC

Conforme referido acima, a aquisição dos dados deste sensor, é realizada através da

comunicação digital SPI. Os sinais utilizados para a comunicação entre o sensor e o MCU são:

• SS do MCU com o CSB do sensor;

• SDO do MCU com o MOSI do sensor;

• SDI do MCU com o MISO do sensor; e

• SCK do MCU com o SCK no sensor.

É necessário considerar a frequência de relógio do sinal SCK do MCU para o sensor, sendo

que o mesmo não poderá exceder os 1.6 MHz.

Este sensor permite medir a aceleração dentro de uma gama de ± 2 g e temperatura

dentro de uma gama de -40 ºC a 125 ºC. As características de detecção de movimento e de

queda livre tornam o sensor mais valioso para a aquisição de contextos.

A Figura 20 apresenta fisicamente o sensor de temperatura e aceleração e o pinout

disponível no PCB.

Figura 20 – Sensor de temperatura e de aceleração e respectivo pinout

Formato da frame SPI e procedimento de leitura de registos

A Figura 21 apresenta o formato da frame SPI quando é executada uma operação de

leitura ou escrita no sensor. Cada frame contém 16 bits:

8 É igual a 9,80665 m/s2, que é aproximadamente igual à aceleração devida à gravidade na superfície da terra


• No sinal MOSI, os primeiros 8 bits contêm a informação sobre a operação de

escrita/leitura e do endereçamento do registo acedido. Destes, os primeiros 6 bits

representam os bits do endereçamento da operação pretendida; o 7º bit é igual a 0 se

for uma operação de leitura e igual a 1 se for uma operação de escrita; e o 8º bit é

igual a 0. Os restantes 8 bits, numa operação de escrita, contêm os dados da mesma;

se for uma operação de leitura os bits são colocados a 0. Os bits do sinal MOSI são

amostrados no flanco descendente do sinal SCK.

• No sinal MISO, os primeiros 8 bits contêm a informação sobre a existência de erro na

frame e a paridade da mesma. O bit 2 (SPI_FRAME) é colocado a 1 se existiu erro na

frame, o bit 7 é sempre 1 e o bit 8 (PAR) indica a paridade (é calculada a partir dos

dados que estão a ser enviados). Os bits do sinal MISO são amostrados no flanco

ascendente do sinal SCK. Num comando de escrita, os dados são escritos no endereço

de registo no flanco descendente do sinal SS/CSB.

•

Num comando de leitura, os dados da leitura ficam no registo interno de saída (shift

register) e a partir do oitavo flanco ascendente do sinal SCK os dados são amostrados a partir

do bit mais significativo (MSB) através do sinal MISO.

Figura 21 - Formato da frame SPI [36]

Abaixo será demonstrado o exemplo da leitura dos registos dos dados da aceleração do

eixo X.

As operações de leitura da aceleração em cada eixo e da temperatura é realizada através

do envio consecutivo de dois registos - o registo mais significativo e menos significativo da

leitura pretendida (e.g. aceleração do eixo X ou valor da temperatura).

Sensor de aceleração

O sensor de aceleração permite medir a aceleração no eixo X, Y e Z. A leitura da

aceleração contém 12 bits. A Figura 22 apresenta a informação detalhada do registo da

aceleração para cada eixo, o bit s (mais significativo) representa o sinal da aceleração

(positiva ou negativa), os bits d10 a d0 representam o valor da aceleração em mg.


Para obter os bits referidos anteriormente é necessário realizar o envio de dois registos

para efectuar a leitura do valor do registo X_MSB e do registo X_LSB. A Figura 22apresenta o

procedimento para obter os dados por SPI através dos registos do sensor.

O exemplo da Figura 22 apresenta o procedimento da leitura da aceleração do eixo X. O

dispositivo Master (MCU) envia o registo X_MSB (0x05) via o sinal MISO em formato

hexadecimal ou binário. O sétimo bit é colocado a 0 para indicar que é uma operação de

leitura. No Capítulo 5 na função de leitura SPI ilustra-se o procedimento do envio do registo

de leitura. O sensor responde aos pedidos da operação através do sinal MISO. Depois de ser

transferido o registo mais significativo (X_MSB) o sinal SS/CSB é colocado a 1 e

consecutivamente a 0 para ler o registo X_LSB. O sensor envia o conteúdo do registo enviando

primeiro o bit mais significativo (MSB).

A leitura do registo da aceleração do eixo Y e eixo Z são respectivamente os seguintes

bytes: 0x07 (Y_MSB), 0x06 (Y_LSB), 0x09 (Z_MSB) e 0x08 (Z_MSB).

A Figura 23 apresenta a relação do sensor de aceleração em relação à posição X, Y e Z.

Quando o sensor está colocado com o pino 1 do circuito integrado para baixo, na vertical, o

valor da aceleração do eixo Y é de 1 g.

Sensor de temperatura

O sensor de temperatura permite medir valores entre -40 ºC e 125 ºC. A leitura da

temperatura é fornecida em 9 bits e a leitura no sensor é obtida através do byte mais

significativo (TEMP_MSB) e do byte menos significativo (TEMP_LSB) do registo de

temperatura. Os dados são recebidos pelo MCU sem sinal.

O valor da temperatura é obtido através da seguinte equação:

f(x) = 23 + 0,56*(x-256), em que x é igual o valor decimal de uma variável inteira com os

bits do registo de temperatura t8 a t0 referidos na Figura 24.

Figura 23 - Eixos de aceleração X, Y e Z do sensor acelerómetro

Figura 22 - Descrição do registo da aceleração [36]


A Figura 24 apresenta os bits utilizados para a leitura da temperatura. Os bits B7 a B6 do

registo TEMP_MSB e os bits B4 a B0 do registo TEMP_LSB não são utilizados para a leitura da

temperatura, apenas não utilizados os bit B5 a B6 do registo mais significativo TEMP_MSB e os

bits B7 a B6 do registo menos significativo TEMP_LSB dos registos da medição da temperatura.

A temperatura é igual a 23 ºC quando o registo de temperatura é igual a 256 valores

(equivale ao bit t8 = 1 e os restantes bits a 0, ver Figura 24).

Os comandos para leitura dos registos TEMP_MSB e TEMP_LSB são, respectivamente, 0x13

e 0x12.

Em [35] poderá ser consultada mais informação sobre o sensor de aceleração e

temperatura, tais como: comandos para ler o registo de status do sensor, registo de

configuração do sensor; informação sobre o overflow dos dados; funcionalidade do modo de

detecção de movimento e de queda livre; e procedimento de reset do sensor.

Figura 24 - Descrição dos bits do registo de temperatura [36]

Capítulo 4

Plataforma de hardware

Este capítulo apresenta o fluxo de desenvolvimento da plataforma de hardware, bem

como a descrição do funcionamento, configuração e programação do hardware do sistema.

O fluxo de desenvolvimento da plataforma de hardware consistiu em 4 grandes fases:

captura esquemática, layout, fabrico e montagem dos componentes.

Na fase da captura esquemática desenvolveu-se o esquema eléctrico do sistema, definiu-

se o footprint9 de cada componente e gerou-se a netlist10 utilizada na fase de layout do PCB.

O layout do PCB consistiu no placement11 dos componentes e routing do PCB.

Estando a fase do routing concluída gerou-se os ficheiros Gerber para o processo de

fabrico do PCB.

Na fase final do desenvolvimento da plataforma de hardware montaram-se os

componentes no PCB.

O software de desenho utilizado foi a ferramenta do Capture CIS para a fase da captura

esquemática e o Layout Plus para a fase de layout, ambos da Cadence Orcad [37].

4.1 Esquema eléctrico do PCB

O esquema eléctrico do PCB foi desenvolvido após a análise e definição da arquitectura

do sistema a implementar e dos dispositivos electrónicos associados à mesma. Enquadra-se na

fase da captura esquemática do desenvolvimento de um PCB, como referido anteriormente.

O esquema eléctrico apresentado na Figura 25 representa, de uma forma virtual, os

componentes utilizados no PCB e as suas ligações.

9 Termo técnico utilizado para a dimensão física do componente no PCB.

10 Ficheiro que contém as ligações e componentes do esquema eléctrico que é usado pela ferramenta de layout.

11 Disposição física dos componentes no PCB.

Protótipo do Hardware 38

Descrevem-se de seguida alguns aspectos importantes do esquema eléctrico desenvolvido:

• O símbolo U1 refere-se ao MCU utilizado no PCB, é possível ver o seu pinout e as

ligações efectuadas para outros componentes e interfaces disponíveis no PCB.

• O símbolo U2 refere-se ao regulador LDO definido para o sistema. Os condensadores

C1 e C2 são os condensadores de desacoplamento para o LDO. Para os condensadores

foram utilizados valores recomendados na datasheet do fabricante.

• A malha de reset do MCU é constituída pelo comutador SW1, pelas resistências R1 e

R2, e pelo condensador C3.

• A resistência R5 e o diodo emissor de luz (LED) D1 permitem indicar que o sistema

está a funcionar quando alimentado nas condições mencionadas na secção 3.4 Módulo

de alimentação e alimentação externa.

• As resistências R3 e R4 constituem um divisor de tensão que tem a função de tornar

compatíveis os sinais da SCI entre o MCU e o módulo BlueSMiRF. Posteriormente serão

detalhados o divisor de tensão e as especificações eléctricas dos sinais.

• Os conectores (J1 a J14) para a ligação dos sensores, alimentação externa,

programação do MCU e o botão para o reset do sistema são detalhados na Tabela 11.

Tabela 11 - Descrição do esquema eléctrico

Jumper / Comutador Descrição

J1 Alimentação externa para o sistema

J2 Jumper para ligar e desligar o sistema

J3 I/O Digital (RA5)

J4,J5,J6,J7,J8,J9,J10,J11 ADC do MCU:

AN0,AN1,AN2,AN3,AN4,AN5,AN6,AN7

J12 ADC do MCU: AN8,AN9,AN10

Ou Interface digital SPI/ I2C

J13 Interface ICSP

J14 Interface SCI para o módulo BlueSMiRF

SW1 Comutador para Reset do MCU

A alimentação externa das 4 pilhas AAA é conectada ao sistema através do J1. A

alimentação externa só é fornecida para o LDO se o J2 estiver fechado.

O J3 é o porto RA5 do MCU, que permite operar como porto de entrada ou saída digital.

Os canais ADC’s do MCU estão disponíveis através do J4 até ao J12. O J12 tem a

particularidade de disponibilizar os canais 8, 9 e 10 do ADC ou o interface digital SPI/ I2C do

MCU.

A programação do MCU é efectuada através do interface ICSP (J13).

O reset do MCU é realizado através do comutador SW1.


Figura 25- Esquema eléctrico do PCB


A integração do BlueSMiRF com o MCU é realizada através do J14. O divisor de tensão

realizado entre o sinal de saída TX do MCU e o sinal RX do BlueSMiRF serve para garantir a

compatibilidade entre a SCI dos dois dispositivos. O divisor de tensão implementado teve

como referência as especificações eléctricas da Tabela 12 e Tabela 13.

Tabela 12 - Especificações eléctricas da SCI do MCU

4,5 V <= VDD <= 5, 5 V Min. Tip. Max. Un.

Input logic level LOW (Vil) - - 0,8 V

Input logic level HIGH (Vih) 2 - - V

Output logic level LOW (Vol)

Iol= 8mA; Vdd = 5V - - Vss+0,6 V

Output logic level HIGH (Voh)

Ioh = 3,5 mA; Vdd = 5V VDD-0,7 - - V

iL I/O ports

Vss <= Vpin <= Vdd - +-5 +-100 nA

Tabela 13 - Características eléctricas da SCI do dispositivo RN-41

2,7 V <= VDD <= 3, 0 V Min. Typ. Max. Unit

Input logic level LOW (Vil) -0,4 - 0,8 V

Input logic level HIGH (Vih) 0,7VDD - VDD+0,4 V

Output logic level LOW (Vol) - - 0,2 V

Output logic level HIGH (Voh) VDD-0,2 - - V

All I/Os (excep reset) default

to weak pull down 0,2 1 5 uA

4.2 Layout do PCB

A fase de layout do PCB surge após a fase da captura esquemática concluída, conforme

referido anteriormente.

Foi nesta fase que se desenharam os footprints dos componentes utilizados no PCB.

Procedeu-se ainda à inserção na ferramenta de layout da netlist gerada pela ferramenta da

captura esquemática, para que se pudesse dar inicio à fase de placement e routing dos

componentes.


Na fase de colocação dos componentes no PCB (placement) teve-se como objectivo a

optimização da disposição no PCB de todos os componentes utilizados, para que fosse possível

desenhar um PCB com a menor dimensão possível e desenvolver o routing em uma só

camada.

No placement do PCB colocaram-se todos os componentes discretos na camada de topo do

PCB (TOP) e os componentes Surface Mout Device (SMD) na camada de fundo do PCB

(BOTTOM). A Figura 28 ilustra o placement dos componentes discretos do PCB.

Como exemplo ilustrativo de um footprint, apresenta-se na Figura 26 o footprint do MCU.

O footprint é desenhado com as informações das dimensões físicas do componente e do

pinout fornecidas na datasheet do fabricante do dispositivo electrónico. Na fase de desenho

do footprint é necessário ter em consideração o tipo de encapsulamento que o componente

possui. Se o componente possui encapsulamento SMD, não é necessário definir a padstack12

para as várias camadas do PCB uma vez que um componente SMD só é colocado na camada

TOP ou BOTTOM. No caso de um componente discreto, como por exemplo o MCU utilizado no

projecto, é necessário definir outras camadas da padstack, como por exemplo a camada Drill

(camada que define a furação do pino).

Estando a fase de placement concluída, e antes de se passar para a fase de routing,

definiram-se as dimensões de largura dos sinais (15 Mils13) e os espaçamentos mínimos entre

sinais e pinos (10 Mils). Estas configurações são baseadas nas especificações para o processo

de fabrico.

O routing do PCB foi efectuado na camada de BOTTOM, onde estão os componentes SMD

do PCB (e.g. resistências e condensadores). Estando o routing de todos os sinais finalizado,

criou-se o plano de massa que permite a absorção dos ruídos no PCB. O plano de massa

consistiu em ligar todos os pinos GND (ligados à massa do sistema) ao plano de massa.

Concluiu-se a fase de layout com a geração dos ficheiros para o processo de fabrico. O

formato do ficheiro utilizado foi o Extended Gerber14.

A Figura 27 ilustra a camada BOTTOM do PCB. As dimensões do PCB desenvolvido são

64,01 x 60,7 (mm).

12 Termo técnico utilizado para a representação física dos pinos de um componente.

13 1 Mils equivale a 0.0254 mm.

14 Formato de ficheiro para o processo de fabrico do PCB, compatível com a maioria dos fabricantes de PCB.

Figura 26 - Footprint do MCU


4.3 Descrição do PCB

Esta secção descreve as especificações da ligação dos sensores ao PCB, a alimentação do

mesmo e o botão de reset do MCU. Adicionalmente detalha-se o pinout para a ligação do

módulo BlueSMiRF e a programação do MCU.

A Figura 28 apresenta a localização dos interfaces e conectores no PCB descritos na

secção 4.1 Esquema eléctrico do PCB.

Para ligar um sensor analógico ao PCB é necessário ter em consideração o pinout do

conector associado ao canal ADC pretendido. O pino no conector que indica o canal ADC do

Figura 27 - Camada BOTTOM do PCB

Figura 28 – Esquema de localização dos interfaces conectores no PCB


MCU é o pino com formato quadrado (ANX), sendo o pino do meio o sinal de alimentação

(VCC) e o GND o sinal da massa (ver Figura 29).

A Figura 29 apresenta a descrição do conector onde disponibiliza os canais 8, 9 e 10 do

ADC do MCU e os sinais para o interface digital SP/ I2C. O pino SS equivale ao canal 8 do ADC,

o pino SDO equivale ao canal 9 do ADC e o pino SCK equivale ao canal 10 do ADC.

O conector para ligar o módulo BlueSMiRF é apresentado também na Figura 29.

A Figura 30 apresenta o protótipo desenvolvido, sendo possível visualizar a localização do

módulo de comunicação Bluetooth BlueSMiRF no canto superior direito, o interface de

programação do MCU no canto inferior esquerdo e os conectores descritos acima.

4.4 Módulo Bluetooth BlueSMiRF

Nesta secção são apresentadas as especificações para a conectividade ao módulo

Bluetooth do sistema, assim como os procedimentos da consola de configuração do módulo

BlueSMiRF.

O módulo de comunicação BlueSMiRF possui as especificações apresentadas na Tabela 14.

Figura 29 - Pinout das ligações do ADC, SPI, I2C e módulo BlueSMiRF

Figura 30 - Protótipo desenvolvido


Tabela 14 - Especificações de ligação ao módulo BlueSMiRF (via Bluetooth)

Dispositivo: BlueSMiRF

Nome FireFly-171D

Código Pin 1234

Endereço MAC 00:06:66:03:17:1D

Modo de funcionamento Slave

Porta de comunicação COM9 (SPP)

Detecção de movimento Sim

Detecção de queda livre Sim

Temperatura - 40 a 125 ºC

4.4.1 Configuração do Módulo BlueSMiRF

O BlueSMiRF permite que se aceda à consola de configuração do mesmo para alterações

de parametrizações, tais como: taxas de transmissão da SCI, nome do dispositivo, etc. Para

aceder ao modo de configuração, é necessário que a conectividade ao BlueSMiRF ocorra nos

primeiros 60 s após à ligação do dispositivo à alimentação. Existem duas formas de aceder ao

modo de configuração do BlueSMiRF:

1) Via Bluetooth, através do emparelhamento do BlueSMiRF com o PC e utilizando-se a

ligação Bluetooth como sendo uma porta série COM9 (SPP); e

2) Via cabo, através da ligação do dispositivo directamente a um computador, e com um

circuito conversor RS-232 para TTL.

Para se aceder à consola de configuração do módulo BlueSMiRF é emulador de terminal

(e.g. aplicação teraterm ou Hyper Terminal do Windows) e a configuração do mesmo é

através de comandos AT.

O módulo Bluetooth no projecto está configurado com uma taxa de transmissão de 9600

bps.

Quando se liga a alimentação do sistema, o módulo BlueSMiRF faz piscar um LED

vermelho. Após a conectividade com sucesso do computador ao BlueSMiRF, o LED vermelho

desliga-se e fica um LED verde acesso.

A configuração do Hyperterminal do Windows é realizada através da criação de uma

ligação com a porta COM, especificada na Tabela 14, e as definições da ligação com as

seguintes parametrizações: 8 bit de dados, sem paridade, 1 bit de paragem e sem controlo de

fluxo.

Nas propriedades de ligação do terminal é necessário efectuar ainda as parametrizações

apresentadas na Figura 31.


Estando a ligação do emulador de terminal configurada, é necessário digitar os caracteres

$$$ e o módulo BlueSMiRF responde com a string CMD. O BlueSMiRF fica com estado do LED

verde fixo e do LED vermelho a piscar. Enviando o comando h, o módulo BlueSMiRF responde

enviando a informação dos comandos de configurações.

Em [28] é possível obter informações adicionais sobre os comandos AT de configuração do

módulo BlueSMiRF.

4.5 Programação do MCU

A programação do MCU é realizada através do software de desenvolvimento e

programação MPLAB IDE descrito no Capítulo 5. Deverá o sistema estar desligado da

alimentação e o PICkitTM 2 ligado ao interface ICSP, acima referido, e a uma porta USB do

computador, como apresentado na Figura 32.

Estando o procedimento de programação físico concluído, os procedimentos de

programação no software de desenvolvimento e programação MPALB IDE são os seguintes:

• Menu Programmer + opção do PICKit 2;

• Menu Project + opção Build all;

• Menu Programmer + opção Program.

Com o processo de programação da fase do software concluída, desliga-se o programador

PICkitTM 2 do PCB, liga-se o mesmo a alimentação e o novo firmware colocado no MCU será

executado.

Figura 31 - Parametrizações das propriedades do Hyperterminal para o BlueSMiRF


Figura 32 - Programação do MCU

Capítulo 5

Software residente

O desenvolvimento do software residente foi realizada recorrendo ao software gratuito

MPLAB IDE versão 8.36 da Microchip. É uma ferramenta de ambiente de desenvolvimento de

realização de projectos, compilação, simulação, debug e gravação do código para o MCU.

Adicionalmente foi utilizado o compilador MPLAB C18 para a programação em linguagem C

do MCU. O compilador MPLAB C18 é gratuito e integra-se facilmente com o MPLAB IDE. O

download das ferramentas referidas anteriormente pode ser realizado no site da Microchip.

5.1 Algoritmo de programação do software residente

A Figura 33 apresenta o algoritmo de programação implementado na versão 1.0 do

software residente do MCU.

Quando se liga o protótipo à alimentação externa, o MCU começa por inicializar os seus

registos. Seguidamente o firmware inicializa os canais, onde estão ligados os sensores para

leitura de contextos, e inicializa as configurações da comunicação SCI para o módulo

BlueSMiRF.

Após as inicializações referidas anteriormente, o MCU fica a aguardar que lhe sejam

enviadas instruções pela SCI através do módulo BlueSMiRF.

Se o MCU recebe o carácter ‘l’, a seguir executa a função de leitura do canal ADC

associado ao sensor de luminosidade e converte o valor em uma unidade luminosa em Lux,

baseada na fórmula referida na secção 3.5.2 Sensor de luminosidade.

Se o MCU recebe o carácter ‘h’, a seguir executa a função de leitura do canal ADC

associado ao sensor de humidade e converte o valor numa unidade em percentagem de

humidade relativa, baseada na fórmula referida na secção 3.5.2 Sensor de humidade.

Se o MCU recebe o carácter ‘s’, a seguir executa a função de leitura do canal ADC

associado ao sensor de som e converte o valor lido pelo canal num valor inteiro.

Software residente 48

Se o MCU recebe o carácter ‘x’, a seguir executa a função de leitura do registo da

aceleração no eixo X associado ao acelerómetro e converte o valor em aceleração g.

Se o MCU recebe o carácter ‘y’, a seguir executa a função de leitura do registo da

aceleração no eixo Y associado ao acelerómetro e converte o valor em aceleração g.

Se o MCU recebe o carácter ‘z’, a seguir executa a função de leitura do registo da

aceleração no eixo Z associado ao acelerómetro e converte o valor em aceleração g.

Se o MCU recebe o carácter ‘t’, a seguir executa a função de leitura do registo da

temperatura associado ao sensor de temperatura e converte em graus celsius.

Quando é finalizada a leitura e processado o valor lido por cada sensor, é executada a

função enviarUSART que envia o valor para a USART.

A versão seguinte do software residente desenvolvida (versão 2.0) estará optimizada para

o telemóvel, permitido que o telemóvel solicite o valor lido pelos sensores e efectue a

inferência dos mesmos. Serão implementados comandos que programem o modo de leitura

em varrimento e contínuo dos sensores. O protocolo de comunicação utilizado para

comunicação do MCU com o dispositivo móvel utilizará uma trama de comunicação com 4

bytes hexadecimais. A trama é inicializada com o carácter hexadecimal 0x02 (star of text) da

table ASCII, que indica o início da transmissão de dois bytes referentes ao valor lido do ADC.

A trama é finalizada com o envio do carácter hexadecimal 0x1F (unit separator) da tabela

ASCII, que indica o fim da trama.

Figura 33 - Algoritmo de programação do MCU (versão 1.0)

Software Residente 49

5.2 Funções implementadas

Esta secção pretende apresentar as funções implementadas no software residente (versão

1.0).

5.1.1 Função de leitura da luminosidade

A função float valorLUMINOSIDADE(), apresentada abaixo, executa a leitura do canal ADC

associado ao sensor, converte essa leitura num valor de luminosidade em Lux e retorna esse

valor. O valor retornado por esta função pode variar teoricamente entre 0 e 500000.

float valorLUMINOSIDADE()

int valor;

float voltagem;

float luminosidade;

SetChanADC( ADC_CH3 );

Delay1KTCYx(5);

// Gera um atraso de 5000*4/16M = 1,25 ms <=>1k*5*Tcy, Tcy = 4/Fosc

ConvertADC();

while( BusyADC() );

valor = ReadADC();

voltagem = ( ( ((float)valor)/1023 ) * 5 );

luminosidade = ( (2500/voltagem)-500)/( 3.3) ;

return luminosidade;

5.1.2 Função de leitura da humidade

A função float valorHUMIDADE(), apresentada abaixo, executa a leitura do canal ADC

associado ao sensor, converte essa leitura num valor de percentagem relativa e retorna esse

valor. O valor retornado por esta função pode variar entre 10 e 100.

float valorHUMIDADE()

int valor;

float voltagem;

float humidade;


Delay1KTCYx(5);


ConvertADC();

Software residente 50

while( BusyADC() );

valor = ReadADC();


humidade = ( (voltagem-0.88)/0.02 );

return humidade;

5.1.3 Função de leitura do som

A função float valorSOM(), apresentada abaixo, executa a leitura do canal ADC associado

ao sensor e retorna esse valor. O valor retornado por esta função pode variar entre 0 e 1023.

float valorSOM()

int valor;

float voltagem;

float som;


Delay1KTCYx(5);


ConvertADC();

while( BusyADC() );

valor = ReadADC();

return valor;

5.1.4 Função de envio da informação para a USART

A função seguinte converte o valor float passado para a mesma numa string que é enviada

para a USART.

void enviarUSART(float valor)

char vstr[20];

itoa( (int)valor, vstr );

putsUSART( vstr );

Software Residente 51

5.1.5 Função de leitura SPI

A função de leitura SPI, apresentada abaixo, consiste na leitura do registo mais

significativo (regMSB) e menos significativo (regLSB) da medida (e.g. aceleração eixo X ou

temperatura) pretendida do sensor de aceleração e temperatura. As leituras dos registos

referidos anteriormente são efectuadas consecutivamente: coloca-se o pino SS a nível lógico

0, envia-se o registo mais significativo para sensor (regMSB), lê-se o resultado para a variável

ucMSB (valor enviado pelo sensor) e coloca-se o pino SS a nível lógico 1; volta-se a executar

os passos referidos anteriormente, para a leitura o registo menos significativo (regLSB) e lê-se

o resultado para a variável ucLSB.

SS=0;

WriteSPI(regMSB<<2);

while (!DataRdySPI());

ucMSB = ReadSPI();

SS=1;

SS=0;

WriteSPI(regLSB<<2);


ucLSB = ReadSPI();

SS=1;

Estando a fase de leitura dos registos concluída, processa-se ao tratamento da informação

conforme especificado na datasheet do sensor [36].

Abaixo ilustra-se o exemplo do tratamento dos dados da aceleração. As variáveis v1, v2 e

v3 são variáveis auxiliares utilizadas para obter a medida da aceleração (Acc).

v1 = ucLSB>>3 & 0x1F;

v2 = ucMSB;

v3=v2;

v3=v3<<5;

v3=v2|v1;

Acc = (float)v3;

Por fim processa-se ao envio da informação para a USART.

Capítulo 6

Validações

Esta secção apresenta as validações efectuadas ao hardware do sistema do projecto.

A Tabela 15 demonstra as medições de consumos dos dispositivos de hardware utilizados

no projecto. As medições do consumo do MCU referem-se a condições de funcionamento de

funcionamento a 16 MHz. O módulo BlueSMiRF em modo Idle apresenta um consumo de 8 mA

e, quando ligado, apresenta um consumo de 30 mA. O módulo BlueSMiRF, nas condições em

que está a enviar e a receber dados, via Bluetooth, apresenta consumos dentro da gama de

30 mA a 50 mA. Os sensores consomem pouca energia, excepto o sensor de humidade, que

apresenta o maior consumo de energia dos sensores utilizados no sistema - cerca de 1,90 mA.

Os valores medidos permitem validar as especificações de consumo de energia referidas

pelos fabricantes dos dispositivos electrónicos, sendo que se encontram abaixo dos consumos

definidos como referência

Tabela 15 - Consumo do hardware do sistema

Dispositivo Consumo

MCU 1,04 mA

BlueSMiRF

Estado Idle 8 mA

Estado Ligado 30 mA a 50 mA

Sensor Luminosidade 46 µA

Sensor Humidade 1,90 mA

Sensor de Som 680 µA

Sensor De aceleração e

Temperatura 920 µA

Validações 54

A tecnologia nanoWatt do MCU foi validada através de um PCB desenvolvido no projecto,

que integra um regulador de tensão step-up. O regulador de tensão step-up permite que o

mesmo seja alimentado de uma até três pilhas AAA de 1,5 V encastradas e obter à saída do

step-up 5 V. Alimentando o PCB, referido anteriormente, com uma pilha AAA de 1,5 V e

colocando o MCU a processar instruções, validou-se que a tecnologia nanoWatt permite que o

MCU seja alimentado com uma pilha AAA de 1,5 V, conforme refere o fabricante. Este

regulador de tensão não foi utilizado no protótipo final desenvolvido devido ao facto de não

fornecer a corrente necessária para o sistema funcionar com todos os dispositivos ligados, nas

condições em que o step-up é alimentado com três pilhas AAA de 1,5 V.

O sensor de humidade foi validado em ambiente interno e externo. Verificou-se a

variação da percentagem de humidade relativa na passagem do sensor do ambiente interno

para o ambiente externo.

O sensor de luminosidade foi validado através de tabelas de luminosidade com a medida

lux. Verificou-se o aumento da intensidade da luminosidade quando o sensor passou de um

ambiente interno para um ambiente externo com maior luminosidade (período do dia). As

variações da intensidade luminosa do desligar e ligar da luz do ambiente de uma sala também

foram medidas.

O sensor de som foi validado em ambiente interno e externo. Validou-se que o sensor

detecta as variações de ruído no ambiente, tais como passagem de veículos, música e tons de

voz mais elevados.

O acelerómetro foi validado com a rotação do sensor no eixo X, Y e Z e confirmando os

valores com os referidos pelos fabricante do dispositivo

O sensor de temperatura foi validado com a medição da temperatura de um ambiente de

uma sala de estar e da temperatura interna de um frigorífico. Os valores foram validados com

um multímetro que mede temperaturas.

A comunicação do telemóvel com o sistema de aquisição de dados foi validada com uma

MIDlet a ser executada no telemóvel e o com a execução do envio de informação do sistema

de aquisição de dados para o mesmo.

As próximas secções apresentam resultados visuais das validações que foram efectuadas

aos sensores de luminosidade, humidade, som, aceleração e temperatura apurados através da

aplicação desenvolvida em linguagem de programação Visual Basic e a comunicação do

sistema de aquisição de dados com o telemóvel.

6.1 Software de interpretação de dados

Foi desenvolvida uma aplicação em Visual Basic para efectuar a leitura dos valores

adquiridos pelos sensores.

As secções seguintes apresentam validações efectuadas aos sensores de luminosidade,

som, humidade, aceleração e temperatura. Colocando os mesmos em diferentes condições

ambientais.

Validações 55

6.1.1 Validações do sensor som luminosidade e humidade

As figuras seguintes apresentam várias validações que foram efectuadas aos sensores

ligados ao sistema de aquisição de dados, em diferentes condições ambientais.

O primeiro gráfico representa as variações de intensidade de som, em que a unidade de

medida é o valor lido no ADC que varia entre 0 e 1023, que equivalem ao valor lido pelo ADC

de 0 a 5 V.

O segundo gráfico representa as variações da intensidade luminosa, em que unidade de

medida é o Lux. O valor pode variar teoricamente entre 0 e 500000.

O terceiro gráfico representa as variações da humidade relativa de um ambiente, em que

a unidade de medida é a percentagem de humidade relativa. O valor pode variar entre 10 e

100 % RH.

A Figura 34 apresenta a informação dos contextos de luminosidade, humidade e som. O

teste foi realizado num ambiente interior (sala de estar). O valor de pico do sensor de som

(aproximadamente 1000), aos 1,40 s, indica um tom de voz mais elevado perto do sensor. O

flanco descendente do sensor de luminosidade, entre os 2,20 s e os 3,40 s, indica o desligar

da luz do ambiente de teste. A intensidade luminosa média da sala manteve-se cerca dos 67

lux. O gráfico da intensidade da humidade manteve-se estável no ambiente de teste, 59 %

RH. O gráfico apresenta os 20 últimos valores lidos no sistema de aquisição de dados por

sensor a uma frequência de amostragem de 10 Hz.

Figura 34 – Medições de luminosidade, humidade e som do interior de uma sala de estar, com duas janelas para o exterior

Contexto da medição: desligar e ligar a luz do ambiente de teste, e tom de voz alto Medições adquiridas a uma frequência de 10 Hz durante 2 s por sensor

Validações 56

A Figura 35 apresenta a informação dos contextos de luminosidade, humidade e som. O

teste foi realizado num ambiente em que os sensores estavam perto da janela de uma sala de

estar. O gráfico apresenta os últimos 100 valores lido por cada sensor a uma frequência de

amostragem de 5 Hz. O sensor de som manteve-se com uma média constante de 520

(equivale ao valor lido pelo ADC de 2,54 V), sendo que as pequenas variações apresentadas

pelo mesmo representam a passagem de veículos na rua. O sensor de luminosidade

apresenta, com a janela aberta, um valor cerca dos 700 lux, sendo que o decréscimo da

intensidade luminosa do gráfico, representa o fechar da janela da sala – o valor lido da

intensidade luminosa interior passou para os 9 lux. A humidade apresenta um aumento nos

últimos valores lidos que se deve ao facto de o sensor de humidade ter um tempo de resposta

de cerca de 5 minutos após se ligar o sistema, sendo que os valores lidos foram após o

sistema ter sido inicializado.

Na Figura 36 poder-se-á verificar a estabilização do sensor de humidade.

Figura 35 - Medições de luminosidade, humidade e som do interior de uma sala de estar, com duas janelas para o exterior

Contexto da medição: fecho da janela da sala e som de passagem de veículos Medições adquiridas a uma frequência de 5 Hz durante 20 s por sensor

A Figura 36 apresenta a informação dos contextos de luminosidade, humidade e som num

ambiente em que os sensores estavam numa sala de estar. Os gráficos apresentam os últimos

100 valores lidos por cada sensor a uma frequência de amostragem de 200 ms. O sensor de

som caracteriza as variações de frequências captadas através de uma música que estava a

tocar no ambiente de teste. A média dos 55 lux do sensor representa a luminosidade da sala

com as janela da sala entreabertas, sendo que o decréscimo da intensidade luminosa

representa o fechar das janelas da sala e o aumento da intensidade luminosa representa o

Validações 57

abrir das janelas da sala. Conforme referido na descrição do gráfico anterior, o sensor de

humidade estabilizou nos 58 % RH, quando o sistema se encontrava no ambiente interno e

ligado após os 5 minutos de estabilidade do sensor.

Figura 36 - Medições de luminosidade, humidade e som do interior de uma sala de estar, com duas janelas para o exterior

Contexto da medição: fecho e abertura da janela da sala, e variações de frequências de uma música

Medições adquiridas a uma frequência de 5 Hz durante 20 s por sensor

A Figura 37 apresenta um cenário em que se colocou o sensor de som e luminosidade num

ambiente exterior. Valida-se o aumento da luminosidade quando o sensor passa de uma

sombra ao cenário em que se encontra exposto ao sol. As variações do sensor de som,

representam o vento que se fazia sentir durante a validação.

Figura 37 - Sensor luminosidade e som, em ambiente exterior Medições adquiridas a uma frequência de 5 Hz durante 20 s por sensor

Validações 58

A Figura 38 apresenta a humidade interior de uma sala de estar (60 %RH) e no exterior da

janela da sala de estar (88%). O aumento da percentagem da humidade relativa que se

verifica no gráfico consiste na adaptação do sensor à humidade do ambiente. O eixo vertical

apresenta a medição da temperatura em percentagem relativa (RH), o eixo horizontal

representa o espaçamento temporal entre cada medição (cada medição foi obtida com uma

frequência de amostragem de 1 Hz).

Figura 38 - Sensor humidade, em ambiente interior de uma sala de estar e ambiente exterior Medições adquiridas a uma frequência de 1 Hz durante 100 s por sensor

6.1.2 Validações do sensor de aceleração

As figuras seguintes apresentam várias validações que foram efectuadas ao sensor de

aceleração ligado ao sistema de aquisição de dados, em diferentes posições relativamente ao

eixo X, Y e Z.

O eixo vertical nos gráficos representa o valor lido de cada eixo do acelerómetro. Os

gráficos apresentam os últimos 100 valores lidos por cada eixo e a uma frequência de

amostragem de 200 ms.

O gráfico de cima apresenta a aceleração no eixo X, o gráfico do meio apresenta a

aceleração o eixo Y e o gráfico de baixo apresenta a aceleração no eixo Z.

Para obter o valor da aceleração na unidade da aceleração g é necessário dividir o valor

apresentado no gráfico por 1333.

A Figura 39 apresenta as aceleração quando o acelerómetro varia no eixo X e Y e

mantém-se estável no eixo do Z. A última posição detalhada na figura representa o

acelerómetro pousado numa mesa.

Validações 59

Figura 39 - Acelerómetro - aceleração eixo Y e X

Medições adquiridas a uma frequência de 5 Hz durante 20 s por eixo de aceleração

A Figura 40 apresenta as aceleração quando o acelerómetro varia no eixo Y e Z e

mantém-se estável no eixo do X. A última posição detalhada na figura representa o


Figura 40 - Acelerómetro - aceleração eixo Y e Z


Validações 60

A Figura 41 apresenta as aceleração quando o acelerómetro varia no eixo X e Z e

mantém-se estável no eixo do Y. A última posição detalhada na figura representa o


Figura 41 - Acelerómetro - aceleração eixo X e Z


A Figura 42 apresenta a aceleração no eixo X, Y e Z num cenário de teste em que uma

pessoa se encontrada em passo de caminhada, passando a passo de rápido (corrida), voltando

a um passo de caminhada. No fim da caminhada verifica-se a paragem do indivíduo assumindo

por fim uma posição de repouso na horizontal para cima.

Figura 42 – Cenários de aceleração


6.1.3 Validações do sensor temperatura

A Figura 43 apresenta a temperatura interior de uma sala de estar. Seguidamente o

sensor de temperatura foi deslocado para outra divisão (a cozinha), sendo colocado no

interior de um frigorífico. Pode-se verificar no gráfico o comportamento da adaptação da

temperatura do exterior para o interior do frigorífico e, posteriormente, a retirada do sensor

para o exterior do frigorífico. O eixo vertical apresenta a medição da temperatura em graus

célsius (ºC), o eixo horizontal representa o espaçamento temporal entre cada medição (cada

medição foi obtida com uma frequência de amostragem de 1 s). A validação da temperatura

da sala de estar encontra-se apresentada na Figura 44, através da medição da temperatura

recorrendo a um multímetro que efectua medições de temperatura.

Figura 43 - Temperatura interior - sala de estar e frigorífico Medições adquiridas a uma frequência de1 Hz durante 100 s

.

Figura 44 - Temperatura interior - sala de estar (medição por um multímetro)

Validações 62

6.2 Comunicação com o telemóvel

A validação da comunicação do sistema de aquisição de dados com o telemóvel foi

validada através do envio de 2 caracteres (OK) para o mesmo. No telemóvel encontrava-se a

ser executada uma MIDlet, fornecida pelo Prof. João Cardoso da FEUP, que recebe dois

caracteres enviados pelo sistema de aquisição de dados (na secção 5.1 Algoritmo de

programação do software residente apresenta-se o protocolo estabelecido para a

comunicação entre os dois dispositivos). O sistema de aquisição de dados encontrava-se a

enviar consecutivamente os dois caracteres referidos acima.

A Figura 45 apresenta a recepção dos dois caracteres, via Bluetooth, pelo Tera Term VT

(emulador de terminal), em execução num computador.

A Figura 46 apresenta a recepção dos dois caracteres, via Bluetooth, pelo telemóvel.

Verifica-se também a conectividade com sucesso do telemóvel ao sistema de aquisição de

dados. A informação apresentada “Connecting to sensing board: FireFly-171D setup finished!”

traduz-se na conectividade com sucesso, do telemóvel ao dispositivo Bluetooth do sistema de

aquisição de dados (FireFly-171D, ver Tabela 14). O telemóvel recebe os dois caracteres em

dois bytes hexadecimais. O valor decimal apresentado 20299 representa em hexadecimal

0x4F4B. Recorrendo a tabela de ASCII verifica-se que o primeiro byte hexadecimal 0x4F

representa o carácter O e o segundo byte hexadecimal 0x4B representa o carácter K.

Figura 45 - Informação recebida do sistema de aquisição de dados, via Bluetooth, num

computador através de um emulador de terminal (Tera Term VT)

Figura 46 - Comunicação do sistema de aquisição de dados com o telemóvel

Capítulo 7

Conclusões e perspectivas futuras

Este capítulo apresentada as conclusões do trabalho e perspectivas futuras de

desenvolvimento.

7.1 Conclusões

No desenvolvimento de um projecto de hardware para o tipo de aplicações referidas

neste documento, é necessário ter em consideração todas as fases de análise, execução e

validação percorridas ao longo deste documento.

A fase de estudo das áreas em que o projecto se enquadra, permite-nos perceber a

importâncias das mesmas para a sociedade actual e futura.

O estudo de mercado sobre soluções equivalentes ao hardware a desenvolver, permitiu

sustentar as mais-valias que o mesmo poderá representar para o processo de investigação.

O estudo das compatibilidades de hardware entre os diferentes dispositivos electrónicos a

utilizar no produto a desenvolver, é uma análise bastante relevante para garantir que o

produto, após fabrico e montagem dos componentes, irá funcionar com garantias.

O protótipo desenvolvido responde às especificações definidas para o projecto. O mesmo

possui um baixo consumo de energia em relação aos produtos que foram analisados no

mercado, um maior número de canais ADC e a disponibilização de interface digital SPI e I2C, o

que permite uma maior integração de sensores para inferência de uma variedade maior de

sensores.

O protótipo desenvolvido permitiu a aquisição do know-how para o desenvolvimento de

um produto final com menores dimensões, uma vez que o MCU utilizado disponibiliza outros

tipos de encapsulamento de menores dimensões (e.g. encapsulamento SSOP, SOIC e QFN),

assim como para o desenvolvimento de produtos personalizados, i.e., produtos de pequenas

dimensões que já integrem sensores no próprio dispositivo de aquisição de dados.

Conclusões e perspectivas futuras 64

A possibilidade da programação do MCU on-board é interessante na medida em que

permite o desenvolvimento de um produto que possibilita a actualização do firmware

(software residente) para novas funcionalidade.

O software de interpretação de dados desenvolvido, permitiu efectuar a validação dos

dados de contextos obtidos através dos sensores analógicos e do sensor com interface digital

SPI. A validação dos dados recolhidos pelos sensores foi realizada através de um software de

interpretação de dados que permitiu interpretar as variações que ocorreram nos dados

recolhidos dos contextos analisados no âmbito deste projecto e analisar como os mesmos

podem ser utilizados no desenho de árvores de decisão para inferir o contexto em que um

determinado utilizador se encontra.

O sistema de aquisição de dados é compatível com dispositivos móveis, conforme

pretendido com o desenvolvimento do projecto, o que torna o protótipo bastante adaptado à

realidade de context-aware computing services.

O desenvolvimento deste tipo de produtos torna-se cada vez mais importante numa

realidade em que caminhamos para a ubiquidade da computação, ambientes inteligentes e

interpretações de contextos que permitam melhorar o dia-a-dia das pessoas.

Durante a execução do projecto foram analisados vários MCUs e módulos de comunicação

sem fios. Foi estudado o MCU PIC18K14K50, que pertence à família do MCU utilizado neste

projecto e que apresenta características muito semelhantes. A principal diferença face ao

implementado (PIC18K14K22) relaciona-se com a possibilidade de comunicação com outros

dispositivos electrónicos através da interface de comunicação USB (HCI), o que possibilita o

desenvolvimento de um dispositivo de aquisição de dados utilizando o módulo de

comunicação ZigBee xBee (que comunicava com o MCU através do interface USART) e o

módulo de comunicação Bluetooth RN-41 (que comunica com o MCU através da interface USB

(HCI)). É, portanto, um produto com uma variedade de aplicações, tais como integração de

sensores analógicos, digitais SPI/I2C e comunicação sem fios para dispositivos externos (e.g.

telemóvel e sensores) através das tecnologias ZigBee e Bluetooth.

Das três tecnologias de comunicação sem fios estudas, o ZigBee distingue-se pelo seu

baixo consumo de energia. A tecnologia Bluetooth apresenta vantagens na integração com os

dispositivos móveis e a tecnologia Wi-Fi na integração do sistema de aquisição de dados em

ambientes Wi-Fi e com dispositivos móveis, sendo que esta possui um maior consumo de

energia em relação às outras tecnologias.

Pessoas deficientes podem tornar-se mais autónomas com dispositivos deste tipo,

conforme referido no projecto BlueHome, na medida em que não só permitem a análise de

contexto do utilizador como também o controlo de dispositivos electrónicos.

7.2 Perspectivas futuras

O objectivo de desenvolvimento de um produto dimensões reduzidas poderá ainda ser

optimizado, na medida em que existe a possibilidade de desenvolver um produto com o

módulo Bluetooth RN-41 e o MCU, utilizando tecnologia SMD.

O desenvolvimento de uma nova versão de software residente no MCU com

funcionalidades adicionais, tais como: leituras por varrimento ou contínuo dos sensores.

Conclusões e perspectivas futuras 65

Adicionalmente, a integração de um módulo de comunicação sem fios Wi-Fi no sistema

potencia a aplicabilidade do dispositivo de aquisição de dados em ambientes que Wi-Fi e

também com telemóveis que usem a mesma tecnologia. A integração deste módulo poderá

ser efectuada recorrendo ao circuito integrado RN-134 [28] da Roving Networks, que

disponibiliza interface de comunicação série (UART) para ligar ao MCU escolhido no projecto.

Por fim, a integração de um módulo de comunicação sem fios Zigbee num produto final

apresenta-se como uma potencial mais-valia do produto, dado que existem sensores com

interface de comunicação sem fios Zigbee [38] (e.g. sensores de temperatura, luminosidade e

humidade da Digi International [38]. A integração deste módulo poderá ser efectuada através

do módulo de comunicação ZigBee xBee da Digi International que disponibiliza interface de

comunicação série que poderá ser ligada ao interface de SCI do MCU utilizado. A utilização de

sensores com tecnologia de comunicação sem fios torna-se actualmente bastante relevante

para o desenvolvimento de aplicações em ambientes inteligentes.

Anexo 1

O Anexo 1 apresenta a Bill of Materials do PCB do Dispositivo Electrónico Pessoal para

Aquisição de Dados obtidos por Sensores. Consiste nos componentes associados ao esquema

eléctrico desenvolvido, footprint, part number do fornecedor e valores de cada componente.

Circuitos Integrados

Item Footprint Quantidades Referência Part Manufacturer (Part No. Name)

1 DIP.100/20/W.300/L.975 1 U1 PIC18F14K22 Micropchip (PIC18F14K22-I/P)

2 TO220AB 1 U2 MCP1825S Micropchip ( MCP1825S-5002E/AB)

Resistências

3 SM/R_1206 2 R1,R3 10 kΩ ---

4 SM/R_1206 2 R2, R5 1 kΩ ---

5 SM/R_1206 1 R4 20 KΩ ---

Condensadores

6 SM/R_1206 1 C1 4,7 µF ---

7 SM/R_1206 1 C2 10 µF ---

8 SM/R_1206 1 C3 1 ---

Diodos

9 JUMPER100 1 D1 --- ---

Resistências

10 JUMPER100 2 J1, J2 --- ---

11 POLCON.100/VH/TM1SQS/W.300/3 9 J3,J4,J5,J6,J7,J8,J9,J10,J11 --- ---

12 POLCON.100/VH/TM1SQS/W.300/6 3 J12,J13,J14 --- ---

13 PUSHBOT 1 SW1 --- ---


Revision 1.1

Bill Of Materials PCB

Anexo 2

O Anexo 2 apresenta a Bill of Materials dos sensores, módulo Bluetooth e programador

programado PICkit 2. Consiste em Indicar o part number do fabricante dos componentes e

onde foram adquiridos os mesmos.

Item Part Number Quantidades Manufacturer (Part No. Name) Distributor (ID Product)

1 Módulo Microfone 1 Texas Instruments Loja Luso Robótica

2 NSL 19M51 1 --- Farnell

3 1226686 1 GE SENSING / THERMOMETRICS (HU1015NA) Farnell

4 SCA3000 1 VTI Technologies (SCA3000) inMotion

5 BlueSMiRF Gold 1 SparkFun Electronics (BlueSMiRF Gold) Loja Luso Robótica

6 DV164120 1 Microchip (DV164120 - PICkit 2 Starter Kit ) Farnell (9847162)


Revision 1.1

Bill Of Materials Sensores, Módulo Bluetooth e programador PICkit 2

Anexo 3

O Anexo 3 apresenta o esquema eléctrico do módulo BlueSMiRF utilizado no projecto. O

esquema eléctrico apresenta a integração do circuito integrado RN-41 com o regulador de

tensão que permite a alimentação do mesmo a 5V e os sinais disponibilizados para a

comunicação série.

Anexo 4

O Anexo 4 apresenta o esquema eléctrico do PCB do sensor de som. O esquema eléctrico

apresenta a integração do circuito integrado do sensor de som OPA344 da Texas instrumentos

com o microfone para a captura de ruído e o sinais disponíveis pelo sensor.

Anexo 5

O Anexo 5 apresenta o esquema eléctrico do PCB do sensor acelerómetro e temperatura.

O esquema eléctrico apresenta a integração do circuito integrado SCA-3000-D01 com o

regulador de tensão que permite alimentar o sensor dentro de uma gama de 3,35 V a 10 V e

fornecer os 3,3 V para o funcionamento do sensor, com também os sinais disponíveis para

ligação ao MCU.

Anexo 6

O Anexo 6 apresenta a verão 1.0 do software residente desenvolvido para o MCU. O

software desenvolvido permite a visualização dos contextos adquiridos pelos sensores através

de um emulador de terminal, com a descrição da unidade de medida do valor lido pelos

sensores.

//*******************************************************************

// Firmware V. 1.0

//*******************************************************************

#pragma config FOSC = IRC, PLLEN = OFF, PCLKEN = ON, FCMEN = OFF, IESO = OFF

#pragma config PWRTEN = OFF, BOREN = OFF, BORV = 30

#pragma config WDTEN = OFF, WDTPS = 32768

#pragma config MCLRE = ON, HFOFST = OFF

#pragma config STVREN = ON, BBSIZ = ON, LVP = OFF, XINST = OFF

#pragma config CP0 = OFF, CP1 = OFF

#pragma config CPB = OFF, CPD = OFF

#pragma config WRT0 = OFF, WRT1 = OFF

#pragma config WRTB = OFF, WRTC = OFF, WRTD = OFF

#pragma config EBTR0 = OFF, EBTR1 = OFF

#pragma config EBTRB = OFF

#include <p18f14k22.h>

#include <stdlib.h>

#include <stdio.h>

#include <usart.h>

#include <adc.h>

#include <delays.h>

#include <string.h>

#include <spi.h>

#define SS PORTCbits.RC6 // Define outro nome para a estrutura

void InicializaUSART() // Função de inicialização da USART

ANSELHbits.ANS11 = 0; // Configura porto digital RB5/AN11 para uso RX da USART

//Open USART com BaudRate 9600 bps em High Speed

OpenUSART(USART_TX_INT_OFF &

USART_RX_INT_OFF &

USART_ASYNCH_MODE &

USART_EIGHT_BIT &

USART_CONT_RX &

USART_BRGH_HIGH &

USART_ADDEN_OFF,

25); // 16M / (64*9600) - 1

BAUDCONbits.BRG16=1;

void InitializaSPI() // Função de inicialização da interface SPI

TRISCbits.TRISC6 = 0; //SS como saída

TRISBbits.TRISB6 = 0; //SCK

TRISBbits.TRISB4 = 1; //SDI

TRISCbits.TRISC7 = 0; //SD0

TRISAbits.TRISA4 = 1; //SD0 #define ADC_REF_VDD_VDD_X 0b11110011 // ADC

voltage source VREF+ = AVDD

ANSELHbits.ANS10 = 0; // Configura porto digital RB4/AN10 para uso SDI da interface

SPI

OpenSPI (SPI_FOSC_16,MODE_00,SMPMID); //inicializa SPI

SS =1; // desactiva Slave

Delay1KTCYx(5);

// Função de inicialização do canal ADC para o sensor de luminosidade

void InicializaADCLuminosidade()

#define ADC_REF_VDD_VDD_X 0b11110011 // ADC voltage source VREF+ = AVDD

OpenADC(ADC_FOSC_RC & ADC_RIGHT_JUST & ADC_12_TAD,

ADC_CH3 & ADC_INT_OFF,

ADC_REF_VDD_VDD_X & ADC_REF_VDD_VSS,

0b00001000);

Delay1KTCYx(5); // Gera um atraso de 5000*4/16M = 1,25 ms <=>1k*5*Tcy, Tcy =

4/Fosc

// Função de inicialização do canal ADC para o sensor de humidade

void InicializaADCHumidade()





0b00001000);


4/Fosc

// Função de inicialização do canal ADC para o sensor de som

void InicializaADCSom()





0b00001000);


4/Fosc

// Função de leitura Luminosidade

float valorLUMINOSIDADE()

int valor;

float voltagem;

float luminosidade;



4/Fosc

ConvertADC();

while( BusyADC() );

valor = ReadADC();


luminosidade = ( (2500/voltagem)-500)/( 3.3) ;

return luminosidade;

// Função de leitura humidade

float valorHUMIDADE()

int valor;

float voltagem;

float humidade;


Delay1KTCYx(5);


ConvertADC();

while( BusyADC() );

valor = ReadADC();


humidade = ( (voltagem-0.88)/0.02 );

return humidade;

// Função de leitura som

float valorSOM()

int valor;

float voltagem;

float som;


Delay1KTCYx(5);


ConvertADC();

while( BusyADC() );

valor = ReadADC();

return valor;

void enviarUSART(float valor)

char vstr[20];

itoa( (int)valor, vstr );

putsUSART( vstr );

void main (void)

float humidade, luminosidade,som,Ax,Ay,Az,temp,stemp,ry;

int tdec,ri,rj,cont;

char c,ucMSB, ucLSB,t1,t2;

char buf[20];

InicializaADCLuminosidade();

InicializaADCHumidade();

InicializaADCHumidade();

InitializaSPI();

InicializaUSART();

putrsUSART ("\r\nProjecto MIEEC\r\n");

putrsUSART ("Escolha uma das seguintes opcoes:\r\n");

putrsUSART ("\nDigitar o caracter 'l' para obter a intensidade luminosa\r\n");

putrsUSART ("\nDigitar o caracter 'h' para obter a percentagem de humidade\r\n");

putrsUSART ("\nDigitar o caracter 's' para obter a intensidade do som\r\n");

putrsUSART ("\nDigitar o caracter 'x' para obter a aceleracao no exio X\r\n");

putrsUSART ("\nDigitar o caracter 'y' para obter a aceleracao no exio Y\r\n");

putrsUSART ("\nDigitar o caracter 'z' para obter a aceleracao no exio Z\r\n");

putrsUSART ("\nDigitar o caracter 't' para obter a temperatura\r\n");

while (BusyUSART()); // espera até a transmissão ficar completa

for (;;)

if (DataRdyUSART()) // verifica o buffer de leitura da USART

c = getcUSART(); // lê a USART para a variável c

switch(c)

case 'l':

luminosidade = valorLUMINOSIDADE();

putrsUSART( "Luminosidade: ");

while(BusyUSART());

enviarUSART( luminosidade );

while(BusyUSART());

putrsUSART( " Lux\r\n" );

break;

case 'h':

humidade = valorHUMIDADE();

putrsUSART( "Humidade: ");

while(BusyUSART());

enviarUSART( humidade);

while(BusyUSART());

putrsUSART( " % RH\r\n" );

break;

case 's':

som = valorSOM();

putrsUSART( "Som: ");

while(BusyUSART());

enviarUSART( som);

while(BusyUSART());

putrsUSART( " \r\n" );

break;

case 'x':

SS=0;

WriteSPI(0x05<<2);


ucMSB = ReadSPI();

SS=1;

SS=0;

WriteSPI(0x04<<2);


ucLSB = ReadSPI();

SS=1;

Delay10KTCYx(4);

t1 = ucLSB>>3 & 0x1F;

t2 = ucMSB;

tdec=t2;

tdec=tdec<<5;

tdec=tdec|t1;

Ax = (float)tdec;

Delay1KTCYx(5);

putrsUSART( "Aceleracao eixo Y : ");

while(BusyUSART());

enviarUSART( Ax);

while(BusyUSART());

putrsUSART( " g/1333\r\n" );

ucMSB=0; ucLSB=0;t1=0;t2=0;

tdec=0;Ax=0;

break;

case 'y':

SS=0;

WriteSPI(0x07<<2);


ucMSB = ReadSPI();

SS=1;

SS=0;

WriteSPI(0x06<<2);


ucLSB = ReadSPI();

SS=1;

Delay10KTCYx(4);

t1 = ucLSB>>3 & 0x1F;

t2 = ucMSB;

tdec=t2;

tdec=tdec<<5;

tdec=tdec|t1;

Ay = (float)tdec;

Delay1KTCYx(5);

putrsUSART( "Aceleracao eixo Y : ");

while(BusyUSART());

enviarUSART( Ay);

while(BusyUSART());



tdec=0;Ay=0;

break;

case 'z':

SS=0;

WriteSPI(0x09<<2);


ucMSB = ReadSPI();

SS=1;

SS=0;

WriteSPI(0x08<<2);


ucLSB = ReadSPI();

SS=1;

Delay10KTCYx(4);

t1 = ucLSB>>3 & 0x1F;

t2 = ucMSB;

tdec=t2;

tdec=tdec<<5;

tdec=tdec|t1;

Az = (float)tdec;

Delay1KTCYx(5);

putrsUSART( "Aceleracao eixo Z : ");

while(BusyUSART());

enviarUSART( Az);

while(BusyUSART());



tdec=0;Az=0;

break;

case 't':

SS=0;

WriteSPI(0x13<<2);


ucMSB = ReadSPI();

SS=1;

SS=0;

WriteSPI(0x12<<2);


ucLSB = ReadSPI();

SS=1;

Delay10KTCYx(4);

t1 = ucLSB>>5;

t2 = ucMSB&0x3F;

tdec=t2;

tdec=tdec<<3;

tdec=tdec|t1;

temp = 23+0.56*((float)tdec-256);

ri = (int)temp;

ry = temp -ri;

if (temp >= 0.0)

rj = (int) (ry*100.0+0.5);

else

rj = -((int) (ry*100.0-0.5));

sprintf(buf, "%d.%02d", ri, rj);

putrsUSART( "Temperatura : ");

while(BusyUSART());

putsUSART(buf);

while(BusyUSART());

putrsUSART( " graus celsius\r\n" );


tdec=0;temp=0;stemp=0;

break;

while (BusyUSART()); // espera até a transmissão ficar completa

Delay1KTCYx(5);


while (DataRdyUSART()) // limpa o buffer de recepção

getcUSART();

Referências

[1] M. Weiser, “The Computer for the 21st Century”, Scientific American, Vol. 265, N.º 3, 1991

[2] L. Barkhuus, “Ubiquitous Computing: Transparency in Context-Aware Mobile Computing”, Doctoral Consortium position paper UbiComp 2002

[3] Arts, E. et al. Ambient Intelligent. Invisible Future: The Seamless Integration of Technology into Everyday Life”. McGraw Hill Professional

[4] Computação ubíqua, http://www.slideshare.net/wpjr2/computao-ubqua, consultado em Junho, 2010

[5] C. Ramos, J. C. Augusto, D. Shapiro, “Ambient Intelligence”, IEEE Intelligent Systems, 2008

[6] A. Astaras, A. Kokonozi, E. Michail, D. Filos, I. Chouvarda, O. Grossenbacher, J.-M. Koller, R. Leopoldo, J.-A. Porchet, M. Correvon, J. Luprano, A. Sipilä, N. Maglaveras, “Pre-clinical physiological data acquisition and testing of the IMAGE sensing device for exercise

guidance and real-time monitoring of cardiovascular disease patients”, XII Mediterranean Conference on Medical and Biological Engineering and Computing, 2010

[7] Projecto My Heart, Site Oficial, http://www.hitech-projects.com/euprojects/myheart/, Consultado em Junho 2010

[8] A. Schmidt, “Interactive Context-Aware Systems Interacting with Ambient Intelligence”, 2005

[9] J. Coutaz, J. L. Crowley, S. Dobson, D. Garlan, “Context is Key”, Communications of the ACM, vol.48, nº.3, pp. 49-53, 2005

[10] A. K. Dey, “Understanding and Using Context”, Personal and Ubiquitous Computing Journal, 5, pp. 4-7, 2001

[11] B. N. Schilit, N. Adams, R. Want, “Context-Aware Computing Applications”, Proceedings of the Workshop on Mobile Computing Systems and Applications, 1994.

[12] M. Baldauf, “A survey on context-aware systems”, Int. J. Ad Hoc and Ubiquitous Computing, Vol. 2, N.º 4, 2007

[13] K. Wrona e L. Gomez, “Context-aware security and secure context-awareness in ubiquitous computing environment”, XXI Autumn Meeting of Polish Information Processing Society Conference Proceedings, pp.255-265, 2005

Referências

[14] B. Omar, T. Ballal, “Intelligent Wireless Web Services: Context-Aware Computing in

Construction-Logistics Supply Chain”, Journal of Information Technology in Construction, Vol. 14, 2009

[15] G. Chen and D. Kotz , “A Survey of Context-Aware Mobile Computing Research”, Dartmouth Computer Science Technical Report TR2000-381, 2000

[16] A. Pashtan, “Mobile Web Services”, Cambridge University Press., 2005

[17] C. P. Pfleeger, “Security in Computing”, Prentice-Hall, Inc., 1997.

[18] ZigBee Alliance, Site oficial. Disponível em http://www.zigbee.org/, consultado em Junho 2010

[19] A. C. Santos, L. Tarrataca, J. M. P. Cardoso, D. R. Ferreira, P. C. Diniz, P. Chainho, “Context Inference for Mobile Applications in the UPCASE Project”, Proceedings of the Second International Conference on Mobile Wireless Middleware (Mobilware 2009), LNICST, vol.7, pp. 352-365, Springer, 2009

[20] Roving Networks, BlueSentry. Disponível em http://www.rovingnetworks.com/bluesentry.php, visitado em Junho 2010

[21] BlueHome, http://www.bluehome.info/, consultado em Junho,2010

[22] Microchip, MCU PIC18F14K22 - Datasheet, http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en538160 consultado em Junho, 2010

[23] Microchip, Tecnologia nanoWat XLP, http://www.microchip.com/XLP consultado em Junho, 2010

[24] Sparkfun eletronics, BlueSMiRF http://www.sparkfun.com/commerce/product_info.php?products_id=582 consultado em Junho, 2010

[25] Bluetooth.com, Site oficial. Disponível em www.bluetooth.com, consultado em Junho, 2010

[26] Bluetooh.com, Características de transmissão. Disponível em http://www.bluetooth.com/English/Technology/Works/Pages/Architecture__Radio.aspx, consultado em Junho, 2010

[27] Bluetooh.com, Alcances disponíveis. Disponível em http://www.bluetooth.com/English/Technology/Pages/Basics.aspx, consultado em Junho, 2010

[28] Roving Networks, Dispositivo RN-41. Disponível em http://www.rovingnetworks.com/rn-41.php, consultado em Junho, 2010

[29] Bluetooh.com, Funcionalidade SPP. Disponível em http://www.bluetooth.com/English/Technology/Works/Pages/SPP.aspx, consultado em Junho, 2010

[30] Microchip, Interface ICSP –Datasheet, Maio 2003 - http://ww1.microchip.com/downloads/en/devicedoc/30277d.pdf, consultado em Junho, 2010

[31] Microchip, PICkitTM 2 , http://ww1.microchip.com/downloads/en/DeviceDoc/PICkit2%20Overview.pdf consultado em Junho, 2010

[32] Microchip, LDO Regulator MCP1825S, Datasheet,

Referências

http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en531456 consultado em Junho, 2010

[33] Silonex INC, LDR NSL-19M51 – Datasheet 102082 REV 3, http://silonex.com/datasheets/specs/images/pdf/102082.pdf, consultado em Junho, 2010

[34] GE Sensing & Inspection Technologies, Sensor de humidade HU1015NA – Datasheet D-HU10-1

[35] Texas Instruments, Sensor de som OPA344, Agosto 2008, http://focus.ti.com/lit/ds/symlink/opa344.pdf, consultado em Junho, 2010

[36] VTI Technologies, Sensor de aceleração e temperatura, SCA300-D01 – Datasheet Nr. 8255700B.01, http://www.vti.fi/en/support/obsolete_products/sca3000_series/, consultado em Junho, 2010

[37] Cadence OrCAD Solutions, http://www.cadence.com/, consultado em Junho, 2010

[38] Digi International, http://www.digi.com/, consultado em Junho, 2010

dispositivo electrónico pessoal para aquisição de …ee09013/docs/dissertacao_prov...figura 34...

Documents