Você está na página 1de 93

Douglas Rocha Ferraz

Sistema aberto de aquisição de dados meteorológicos


para caracterização de recursos eólicos

Campinas
2014

i
ii
Universidade Estadual de Campinas
Faculdade de Engenharia Elétrica e de Computação

Douglas Rocha Ferraz

Sistema aberto de aquisição de dados meteorológicos para caracterização de


recursos eólicos

Dissertação de Mestrado apresentada à Faculdade


de Engenharia Elétrica e de Computação como
parte dos requisitos exigidos para a obtenção do
tı́tulo de Mestre em Engenharia Elétrica. Área de
concentração: Automação.

Orientador: Prof. Dr. Yaro Burian Jr.

Este exemplar corresponde à versão final


da tese defendida pelo aluno, e orientada
pelo Prof. Dr. Yaro Burian Jr.

Campinas
2014

iii
v
vi
Resumo

O sistema construı́do nesta tese estima a geração elétrica em determinado local


passı́vel de instalação de uma usina de geração eólica. Sua arquitetura utiliza um
processador que recebe dados de uma estação meteorológica de baixo custo e as
envia para um servidor na nuvem. Este servidor analisa os dados e as projeções de
geração eólica podem ser estimadas em tempo real.

Palavras-chave: geração eólica, sistemas embarcados, telemetria

vii
viii
Abstract

The following thesis describes the construction and implementation of an open-source


wind resource assessment system. The architecture uses an embedded processor that
fetches environmental data from a low-cost weather station, and sends it to a cloud
server where analyses such as projections of energy generation potential can be
made in real time. The authors believe such a system can facilitate the inexpensive
assessment of wind resources, especially in developing and transition economies, and
thereby contribute to the development of renewable energy systems.

Key-words: wind energy generation, embedded systems, telemetry

ix
x
Conteúdo

1 Introdução e Problemática 1
1.1 Consumo energético sob perspectiva histórica 1
1.2 A equação de impacto humano 6
1.3 Matriz Energética Global 9
1.4 Energia Elétrica no Brasil e no Mundo 11
1.5 Incentivos ao consumo de combustíveis fósseis 12

2 Energia Eólica 14
2.1 Histórico 14
2.2 Energia Eólica no Brasil e no Mundo 15
2.3 Inserção deste projeto de mestrado 16
2.4 Características do Recurso Eólico 16
2.5 Potencial de Recurso Eólico 17
2.6 Turbulência 19
2.7 Fluxo laminar e sua variação com a altitude 19
2.8 Estimativas de recurso eólico 21
2.9 Dados para análise de recursos eólicos 23

3 Sistema de aquisição de dados 26


3.1 Arquitetura 26
3.2 Hub 27
3.3 Aspectos gerais de Firmware 30
3.4 Interface de Memória SD 31
3.5 Interface USB 33
3.6 Estação meteorológica WH-1080 52
3.7 Interface Ethernet e TCP/IP 60
3.8 Banco de dados e servidor 60

xi
3.9 Interface com usuário 63
3.10 Montagem 63

4 Testes e Validação 67

5 Conclusão 73

xii
Aos que viverão de nosso legado.

xiii
xiv
Agradecimentos

Agradeço,
ao Senhor, doador da vida, origem e fim de toda arte, filosofia e ciência.
à minha esposa Cláudia, meus pais Dina e Paulo e meu irmão Denis pelo seu suporte e incentivo
ao prosseguimento deste trabalho.
ao prof. Yaro Burian Jr. pelos diversos anos de prestigiosa orientação e paciência.
aos professores: Ana Cristina Lyra, César José Pagan, Romis Attux e Fabiano Fruett, pelo
apoio na qualificação deste trabalho e nos valorosos cursos oferecidos.
ao prof. José Teixeira Filho e ao sr. Sérgio Lopes, ambos da FEAGRI, sempre prestativos e
fundamentais para a instalação fı́sica deste trabalho em campo.
aos membros da banca examinadora pelos comentários e contribuições que ajudaram a melhorar
a qualidade e o texto deste trabalho.
ao prof. Charles Elworthy da Universidade de Oxford e Universidade de Szczecin pelas valorosas
discussões e oportunidade de dar prosseguimento aos trabalhos da fundação Bhuu.
aos colegas de trabalho Leonardo Tamura, Daniel Berners, Décio Rocha, Alex Massadi e Con-
rado Almeida pela incentivo e flexibilidade dadas para a realização desta empreitada.
à FEEC/UNICAMP, pela estrutura e oportunidade de realizar um trabalho independente.
ao CEPAGRI pelos dados de sua estação meteorológica.
à CAPES/MCT pelo portal de periódicos eletrônicos, que permite o acesso rápido e eficiente ao
conhecimento cientı́fico.

xv
xvi
A luz solar é uma forma de energia, vento e as cor-
rentes marı́timas manifestações desta energia. Fa-
zemos uso delas? Ah, não! Nós queimamos flores-
tas e carvão, como inquilinos queimando a porta de
nossas casas para nos aquecer. Nós vivemos como
colonos selvagens e não como se esses recursos nos
pertencessem.

Thomas Edison, 1916

Parece para mim que à medida que nossa ciência


fica mais especializada, cada um de nós se inclina a
dar mais ênfase em nossa especialidade, em nossa
própria disciplina. Isso cria grandes dificuldades
quando tentamos transmitir uma visão global do
impacto da ciência e da tecnologia, (...) precisamos
encorajar uma certa atitude entre nossos jovens ci-
entistas: enquanto alguns deles ficam em sua es-
pecialidade e disciplina, outros devem trabalhar de
forma integrada através de diversas disciplinas.

Jeffrey D. Sachs

xvii
xviii
Capı́tulo 1
Introdução e Problemática

1.1 Consumo energético sob perspectiva histórica


Utilizamos os recursos que no alvorecer de nossa civilização nos pareceram infindáveis. Du-
rante milhares de anos a humanidade viveu o conceito das terras e mares inexplorados, e o
infinito e o imperscrutável permeou de maneira indistinta os céus, a terra e os mares desconhe-
cidos no imaginário coletivo do homem.
Podemos vasculhar nossa pré-história em busca dos primeiros indı́cios de alterações geográfi-
cas e ambientais em nosso planeta e encontraremos há mais de 10 mil anos o homem pré-histórico
transformando através do fogo diversas florestas com o intuito de criar pradarias mais favorá-
veis para a caça [2]. Entretanto foi a agricultura a principal revolução humana pois permitiu
que o homem obtivesse energia de maneira mais eficiente: através de suas plantações e seus
animais domesticados. Desde então o consumo energético evoluiu lentamente, inexoravelmente
ligado às revoluções das matrizes tecnológicas até que, a partir da revolução industrial, teve seu
crescimento extremamente acentuado. A Tabela 1.1 presente no trabalho Alternative Energy
Resources de Paul Kruger [4] mostra estimativas da população planetária e seu consumo per
capita de energia. Nela vemos esse crescimento vertiginoso do consumo energético per capita
(da ordem de 105 ), que multiplicados pela população terrestre em seus respectivos perı́odos nos
fornece uma diferença de impacto energético agregado da ordem de 5 · 106 desde o alvorecer das
primeiras civilizações.
Somos cerca de 7 bilhões de pessoas [11] compartilhando o mesmo macro-habitat. Desde os
primeiros indı́cios de desequilı́brios ambientais graves causados pela atividade humana como a
extinção dos tigres dente-de-sabre e mamutes na América do Norte e a aparente auto-extinção
dos habitantes da pequena Ilha de Páscoa, sabemos que há limites às nossas atividades econô-
micas e necessidades energéticas.
Apesar de termos conhecimento destes casos históricos isolados, hoje vivenciamos um mo-
mento de inflexão em nossa história no qual estes limites são de diversas maneiras pressionados.
O resultado das nossas escolhas hoje, mais que em qualquer outro momento da existência de
nossa espécie, será fundamental para o bem-estar dos que colherão o legado deixado por nossa
sociedade de consumo.
Da energia necessária à mobilidade urbana à energia requerida por quilograma de alumı́nio a

1


Quadro 1.1: Crescimento do consumo de energia humano desde a pré-história. Adaptado de [4],
p. 5
Perı́odo População Cresc. Mé- Consumo Cresc. Mé-
(Bilhões) dio (%/a) diário per dio (%/a)
capita
(kWh/dia)
300.000 a.C. 2,9
100.000 a.C. 5,0 < 0,001
5.000 a.C. c. 0,1 9,4 < 0,001
0 0,3 0,04
1850 a.D. 1,3 0,08 12 0,004
1980 a.D. 4,4 0,94 51 1,1
2000 a.D. 5,0 1,6 230 7,5

ser usado em bens perecı́veis, nos cercamos de conforto baseado extensivamente em quantidades
abundantes e sempre crescentes de energia. De fato entidades como o IEA (International Energy
Agency) foram criadas à luz da manutenção da segurança energética como pilar fundamental
do capitalismo moderno num contexto de crise energética do final dos anos 1970.
Além desta volatilidade do preço do barril de petróleo após 1979, das décadas de 1950 a
1980 o contexto da guerra fria e a perspectiva de uma eventual guerra nuclear aterrorizaram o
imaginário público – certamente de maneira midiática e exagerada, mas não sem fundamento.
Contudo, as gerações do século XX e XXI lidarão com uma ameaça aparentemente muito mais
simples que esta, mas infinitamente mais complexa politicamente: nossa matriz energética é a
causa direta do atual e futuro aquecimento das temperaturas médias da superfı́cie terrestre. Este
fato singular tem inúmeras implicações e retroalimentações ainda não perfeitamente modeladas
como mudanças de correntes marı́timas, padrões migratórios, adaptação de culturas de plantio,
elevação dos nı́veis marı́tmos, desequilı́brios ecológicos, migrações humanas em massa e possı́veis
desabastecimentos de diversas commodities.
De fato vivemos em um momento de definição único. Temos um desafio duplo de segurança
energética e alterações climáticas globais que se não tratado de maneira apropriada, pode levar a
uma grande e duradoura instabilidade global nas décadas seguintes do século XXI, especialmente
após o marco de 2050.
Historicamente é inocência acreditar que vivemos em tempos livres de turbulências e conflitos
de todas as naturezas, afinal os interesses estratégicos das nações, muitas vezes conflitantes,
continuam os mesmos, e também são os mesmos os seus meios de alcançá-los. Ainda que estes
sejam alterados pela tecnologia, e que passemos por um movimento aglutinador ao redor de
grandes blocos como o NAFTA, a UE, Mercosul e a APEC, forças econômicas, culturais e
bélicas continuarão a moldar nossa estrutura polı́tica global de maneira não muito distinta da
época de Alexandre, Ciro, Cæsar ou Nabucodonosor.
Se na era clássica assegurar commodities alimentares era fundamental para as grandes civili-
zações, hoje isso não deixou de sê-lo, mas diversos outros interesses nacionais foram agregados.
Dentre eles, a segurança energética se destaca por sua intrı́nseca volatilidade e recente inser-
ção na pauta de prioridade dos lı́deres globais, principalmente a partir de 1979. Não somente a
Capı́tulo 1. Introdução e Problemática 3

manutenção do estilo de vida civil ocidental, mas o próprio conceito de guerra seria hoje inimagi-
nável sem grandes quantidades de energia.1 Somada a ela, o aquecimento global em decorrência
da emissão de Gases de Efeito Estufa (GEE) agravou a problemática energética por introduzir
condições de contorno que se não observadas, poderão gerar consequências catastróficas para o
planeta.
Alguns dados e gráficos usados nesta introdução são extrapolações das tendências atuais
muitos anos à frente. Obviamente a história mostra que movimentos sociais são dinâmicos e
dificilmente poderı́amos supor a composição energética e populacional de hoje cinqüenta anos
atrás. Apesar disso, como diz o relatório das Nações Unidas sobre Populações Mundiais [3],
ver tais gráficos é como tirar conclusões após 5 minutos de um jogo de basquete ou futebol: o
resultado não está certo, mas podemos ver os erros e acertos do time, e o que devemos fazer
para que ele vença. Procurar contribuir, mesmo que de maneira muito pequena, para o legado
futuro da relação do homem com a energia é o objetivo deste trabalho.
Houve diversas e subseqüentes tentativas endereçar o problema sistemicamente, dentre as
quais podemos citar a ECO92 no Rio de Janeiro e as conferências de Kyoto e de Kopenhagen. O
mais recente acordo, firmado em Kopenhagen, assumiu um objetivo de estabilizar a concentração
de CO2 atmosférico a um máximo de 450 ppm, o que representa cerca de 2 C de aquecimento
global médio em relação aos nı́veis pré-industriais ([1], p. 45). Entretanto não foi criado um
mecanismo supra-nacional que garanta o cumprimento destes compromissos, sendo estes somente
garantias voluntárias fracas dos paı́ses signatários dos acordos. Ainda mais alarmante é o fato
de que ainda que cumpridos, os compromissos individuais dos paı́ses signatários em Kopenhagen
quando somados não atingem este objetivo de 450 ppm.
A Figura 1.1 mostra a composição atual de geração de energia por fonte energética e as pro-
jeções do International Energy Association (IEA) para 2020 e 2035 no cenário que se contempla
a introdução novas polı́ticas energéticas moderadas, chamado de Cenário de Novas Polı́ticas
(NPS ou New Policy Scenario). O IEA além deste cenário adota dois outros: o de polı́cias atu-
ais inalteradas (Current Policies Scenario ou CPS) e o cenário com maiores alterações polı́ticas,
caso todos os estados nacionais se comprometessem a manter o limite de 450 ppm CO2 -eq, o
(Cenário 450 ou 450S).
É cada vez mais patente a impossibilidade de cumprirmos esta meta de 2 C de aquecimento
global em relação aos nı́veis pré-industriais ao final deste século sem modificarmos o nosso
paradigma atual de consumo energético baseado em combustı́veis fósseis e ineficiência de seu
consumo. Lembremos que o limite de 2 C é aceito como o gatilho para o inı́cio alterações globais
mais profundas como alterações de regimes de chuvas, correntes marı́timas, padrões de plantio,
polarização dos extremos de secas e inundações, redução da segurança hı́drica, aumento do nı́vel
dos mares e grandes deslocamentos humanos a partir de grandes regiões costeiras alagáveis.
Para atingir deste objetivo de 450 ppm, terı́amos que assumir medidas mais restritivas a
partir de 2020 ([1], p. 45), especialmente nas economias emergentes, uma vez que os dados
preliminares de 2009 sugeriram que neste ano a China ultrapassou os EUA como o maior usuário

1
Um dos grandes fatores que levaram à derrota do eixo foi seu estrangulamento energético. Embora os
alemães tivessem tecnologia de transformar carvão mineral em óleo combustı́vel através do dispendioso processo
de Fischer–Tropsch, isso não foi o suficiente para suprir as suas necessidades energéticas da máquina de guerra.


já sobre-explorados midiaticamente. Nem por isso eles são irrelevantes ou irreais. É lamentável
que apesar de toda exploração midiática e mercadológica, o processo de mudança de polı́ticas
energéticas seja tão vagaroso. A euforia brasileira do pré-sal nos mostra essa falta de com-
promisso com uma polı́tica energética consistente com nossos padrões históricos marcados por
produção hidroelétrica e busca por alternativas renováveis como o etanol e o biodiesel.

1.2 A equação de impacto humano


O economista Jeffrey Sachs em seu livro Common Wealth [2] comenta sobre o impacto
humano no planeta postulando a seguinte equação com três fatores:

1. População P – Para dado grupo de controle, o número de indivı́duos que habita nesta
região

2. Nı́vel de renda e consumo A – Média da renda e decorrente consumo deste grupo

3. Impacto ambiental da produção e descarte T – Quantidade de impacto ambiental gerado


por unidade de unidade monetária decorrente da tecnologia utilizada

Esses três elementos contribuem de forma multiplicativa (I = P ×A×T ), formando a fórmula


conhecida como I-PAT. Há muitos impactos I relacionados à produção energética nos moldes
atuais, como a poluição do ar de grandes cidades por particulado sólido de carvão mineral e
petróleo, CO e NOx e O3 e contaminação de mananciais ou expansão da fronteira agrı́cola para
plantações de matéria produtora de biocombustı́veis. Entretanto, o problema que se crê que seja
o mais impactante e de efeito global seja a emissão de gases de efeito estufa, particularmente
CO2 .

1.2.1 População – P
Se a população em nações com maior renda tende a se estabilizar nas próximas décadas –
incluso no Brasil – o mesmo não é verdadeiro das nações mais pobres, especialmente na África.
Com uma população global estimada de cerca de 8,9 Bilhões de pessoas em 2050, a maior
concentração terrestre será na África e Ásia dadas as altas taxas de crescimento populacional
daquele continente e a atual população deste, que já soma mais de 3 bilhões de pessoas.
Historicamente as curvas populacionais tendem a seguir 4 fases distintas na curva de desen-
volvimento econômico e social, como podem ser vistas na Figura 1.5:

1. Quando a nação ainda é pobre, ela possui alta taxa de natalidade e alta taxa de mor-
talidade, gerando um crescimento vegetativo pequeno. A lógica por trás da alta taxa de
natalidade está intimamente relacionada à garantia do casal de seu sustento na velhice,
mesmo que muitos filhos venham a falecer. No campo, a prole numerosa também sem-
pre foi vista como positiva pela contribuição dos filhos trabalho agrı́cola e baixo custo de
criação. Este é o estágio de algumas partes mais pobres da África hoje.
Capı́tulo 1. Introdução e Problemática 13

reconhecendo os desafios que se apresentam às populações afligidas pela escassez energética,
comprometemo-nos a:
- Racionalizar e eliminar gradualmente, no médio prazo, os subsı́dios ineficientes aos com-
bustı́veis fósseis que promovem o consumo com desperdı́cio.
(...)
31. Aumentar a oferta de energia limpa e renovável, melhorar a eficiência energética e
promover a conservação de energia constituem medidas cruciais para proteger o meio ambiente,
fomentar o crescimento sustentável e enfrentar a ameaça representada pela mudança do clima. A
rápida adoção de tecnologias energéticas limpas e renováveis e de medidas de eficiência energética
diversifica nossas fontes de energia e fortalece nossa segurança energética. Comprometemo-nos
a:
- Estimular investimentos em energia limpa e renovável e em eficiência energética, bem como
fornecer apoio técnico e financeiro a projetos dessa natureza nos paı́ses em desenvolvimento.
- Adotar providências para facilitar a difusão ou transferência de tecnologias de energia
limpa,incluindo a condução conjunta de pesquisas e o desenvolvimento de capacidades. A redu-
ção ou eliminação de barreiras ao comércio e os investimentos nessa área vêm sendo discutidos
e devem ser buscados voluntariamente nos foros apropriados.
32. Como lı́deres das maiores economias do mundo, estamos trabalhando em favor de uma
recuperação econômica duradoura, sustentável e verde. Sublinhamos nossa determinação reno-
vada de enfrentar a perigosa ameaça da mudança do clima.
Capı́tulo 2
Energia Eólica

2.1 Histórico
A energia eólica é aproveitada pelo homem há milênios na navegação. O primeiros registros
históricos de moinhos de vento datam de aproximadamente 900 A.D. pelos Persas[7]. Na Europa
seu uso data da idade média, mas a após o inı́cio da revolução industrial sua importância relativa
foi diminuı́da pois sua energia não é facilmente transportada e despachada como a dupla carvão-
vapor.
Até o advento da revolução industrial houve uma evolução nas técnicas de construção de
moinhos, culminando nos tı́picos modelos “smock mill”, nos quais somente a parte superior era
rotatória.
O inglês John Smeaton fez grandes contribuições ao estudo cientı́fico do aproveitamento
eólico, e estruturou as três propriedades fı́sicas fundamentais da energia eólica – na verdade
derivada da mecânica de fluidos:

• Idealmente a velocidade das pontas das pás é proporcional à velocidade do vento

• O torque máximo é proporcional ao quadrado da velocidade do vento

• A potência máxima é proporcional ao cubo da velocidade do vento

Embora bombas de água e geradores eólicos fossem utilizados em fazendas norte-americanas


no começo do século XX, foi somente nos anos 1980 que a energia eólica voltou a receber atenção,
possivelmente em decorrência da preocupação com a segurança energética decorrente das crises
de petróleo da década de 1970.
Durante o começo da década de 1980 houve diversos parques eólicos instalados na Califórnia
devido a uma série de benefı́cios governamentais. Essa foi uma experiência traumatizante para
a indústria pois além das máquinas ainda não serem robustas, após a retirada dos benefı́cios
pelo governo Reagan a maior parte dos fabricantes norte-americanos da época foi à falência.
Após esse episódio a Europa se firmou durante muitos anos como o centro de desenvolvimento
e produção eólicas, especialmente a Dinamarca, Alemanha e Espanha. Já mais recentemente,
desde o inı́cio dos anos 2000 se vê a ascensão dos fabricantes chineses como grandes competidores
mundiais.

1


2.2 Energia eólica no Brasil e no Mundo


Embora a utilização de fontes de energia renováveis se tornará mais competitiva, o estı́mulo
governamental será fundamental para expandir a sua contribuição na matriz energética mundial.
Em 2009 esse valor foi de cerca de USD$57 Bilhões. No NPS esse valor crescerá para USD$
205 Bilhões em dólares atuais, ou 0,17% do PIB global em 2035. A maior parte deste estı́mulo,
cerca de 63%, será direcionado à eletricidade com geração renovável. com isso se espera que
o preço do MWh se reduza de cerca de USD$55 para USD$23 com o aumento da produção e
aprendizagem tecnológia[14].
Muitos avanços serão também necessários na integração destas novas fontes energéticas ao
grid elétrico, pois a variabilidade inerente da energia eólica e fotovoltaica deverá ser estatisti-
camente compensada por outras regiões e por outras fontes energéticas com curvas de resposta
melhor controladas, como a energia hidráulica e termoelétricas a gás natural[14].
Um dos quadros mais comuns em todo texto sobre energia eólica é a Figura 2.1, que mostra
o crescimento em tamanho e potência das turbinas eólicas. Embora obviamente haja muitas
vantagens da utilização de grandes turbinas – melhor custo benefı́cio do gerador, qualidade
dos ventos em maior altitude, aproveitamento da área do parque – deve-se considerar que a
instalação das turbinas é um fator determinante em seu custo de capital, e a infraestrutura para
transporte de peças: portos, rodovias, locação de gruas pode não acomodar as torres ou pás das
maiores turbinas.

Figura 2.1: Tamanho de turbinas e seus anos de lançamento[6]. O diâmetro do rotor varia de
15m em 1981 a 90m em 2002

O potencial eólico bruto mundial é da ordem de 500.000 TWh/ano, cerca de 30 vezes o


Capı́tulo 2. Energia Eólica 

consumo atual de energia elétrica mundial. No Brasil, o potencial se encontra principalmente


na zona litorânea do NE e em algumas regiões do interior no Sul e no Sudeste. Os dados do
Atlas do Potencial Eólico Brasileiro[8] apontam para um potencial de 143.000 MW, sendo que
7.694 MW já foram autorizados (2010). Atualmente as usinas em operação têm capacidade para
gerar 26,8 MW (2010). O estado do Ceará corresponde a 65% desta capacidade[15].
Um dos fatos interessantes do desenvolvimento da energia eólica no Brasil é a atuação do
produtor independente de energia, dada a flexibilidade brasileira do mercado livre de energia,
especialmente energia renovável.

2.3 Inserção deste projeto de mestrado


O projeto desenvolvido procura endereçar a necessidade de levantamentos de potenciais eó-
licos preliminares de locais que possam sustentar parques eólicos através do registro de dados
históricos em estações meteorológicas de baixo custo (< 100 USD). A estação meteorológica
utilizada foi a WH-1080 da Fine Offset Electronics, mas outros fornecedores poderiam ser agre-
gados ao sistema sem grande dificuldade, oferecendo opções de melhor qualidade ou menor
preço. Ela foi escolhida pois um projeto que visa utilizá-la como plataforma de aquisição de
dados ambientais (Bhuu Project), coordenado pelo colega Dr. Charles Elworthy (Univ. Ox-
ford), se prontificou a enviar três unidades para o Brasil para serem utilizadas neste projeto de
mestrado. Uma delas foi utilizada para desenvolvimento e outra está instalada junto à estações
da Embrapa e do Cepagri na Unicamp.
Embora existam sistemas comerciais para esse fim, especialmente os produtos da Vaisala[16],
diversos agentes podem se interessar nessa tecnologia, desde o eventual proprietário privado ou
público de terreno que deseje avaliar seu potencial eólico a empresas que prestem estes serviços
comercialmente. Os capı́tulos seguintes descrevem tecnicamente o sistema desenvolvido e o
analisam à luz dos dados coletados por outras estações adjacentes para referência.

2.4 Caracterı́sticas do Recurso Eólico


Os ventos são causados por diferenças na maneira como a terra é aquecida pela radiação
solar. Em seu modelo mais simples, próximo ao equador temos zonas com fluxos verticais
ascendentes que geram zonas de baixa pressão. Isso faz com que massas de ar densas dos pólos
se desloquem para estas regiões. Somado a este fenômeno, devemos levar em consideração que
embora a velocidade angular de rotação da terra seja obviamente igual em todas as latitudes,
próximo ao equador temos uma velocidade superficial de cerca de 600 Km/h, enquanto que
nos pólos ela é zero. Diversos outros fatores contribuem para um modelo bastante complexo e
geralmente computado somente numericamente: fricção com superfı́cie, inércia de massas de ar,
diferenças de permeabilidade da atmosfera à luz (nuvens, poeira), quantidade de vapor d’água
no ar, albedo, evapotranspiração da camada de vegetação e espelhos d’água.
Também caracterizamos movimentos atmosféricos e climáticos em diversas escalas de tempo-
espaço. Por exemplo, embora ambos sejam “vento”, o estudo de rajadas e mudanças de padrões
eólicos devido a fenômenos como o El Ninõ seguem metodologias completamente distintas para


P̄ 1
= ρŪ 3 Ke (2.7)
A 2
no qual P̄ é a média anual de velocidade eólica e Ke é o fator de padrão energético, dado
por
N
1 X 3
Ke = Ui (2.8)
N Ū 3 i=1
no qual Ui são médias horárias e N é o número de horas consideradas, tipicamente 8760
(número de horas em um ano). Valores consideráveis para instalações eólicas são de P̄ /A ≥
400W/m2 .

2.6 Turbulência
As turbulência são causadas por perturbações no perfil de fluxo laminar e consequentes
redemoinhos ou eddies que têm diferentes tamanhos e convertem a energia cinética em energia
térmica.
Os impactos da turbulência na aferição do fluxo laminar podem ser vistos como uma função
de densidade de probabilidade sobre a velocidade média Ui com uma intensidade de turbulência
T I (Turbulence Intensity), medida tipicamente em um intervalo de dez minutos, de acordo com
q P NS
1 2
σu NS 1 i=1 (ui − U )
TI = = (2.9)
U U
sendo N o número de medições ui de velocidade de vento; medições realizadas ao menos a
1Hz. Como nossa estação meteorológica utilizada não fornece dados a essa velocidade, a medição
de turbulência não é possı́vel, e pode somente ser inferida imprecisamente através da velocidade
máxima de rajadas, que é um dos parâmetros informados pela WH-1080.
Além do parâmetro geral de intensidade de turbulência T I, a turbulência também pode ser
expressa como uma função densidade probabilidade normal (ou Gaussiana), que fazendo uso do
desvio padrão σu é

(u − U )2

1
p(u) = √ exp − (2.10)
σu 2π 2σu 2
Também há interessantes análises da turbulência como superposições de senóides de diferen-
tes frequências e análise de autocorrelação, mas elas fogem do escopo deste trabalho.

2.7 Fluxo laminar e sua variação com a altitude


A variação da velocidade média do vento Ui de acordo com a elevação z é importante
tanto para a correção dos dados de anemômetros a diferentes alturas, como para o desenho
de máquinas, turbinas e pás. Afinal, a varredura de áreas A que apresentam um gradiente dU
dz
influencia na distribuição de carga de toda a mecânica.
Capı́tulo 2. Energia Eólica 

Existem duas maneiras principais de se estimar o perfil eólico para altitudes superiores às
medidas por anemômetro: a lei de log e a lei de potências.

2.7.1 Lei de log


A lei de log se baseia na equação de momento, que perto da superfı́cie terrestre é

∂p ∂
= τxz (2.11)
∂x ∂z
sendo que τxz é a tensão de cisalhamento entre planos xy.
Como a pressão perto da superfı́cie não depende de z, integrando a equação obtém-se

∂p
τxz = τ0 + z (2.12)
∂x
Como o gradiente de pressão no eixo x é pequeno perto da superfı́cie, também podemos
descartar o segundo termo à direita.
Ora, de acordo com a teoria de mistura de comprimentos de Prandtl, a tensão de cisalha-
mento também pode ser dada por
✓ ◆
2 ∂U
τxz = ρl (2.13)
∂z
Uma vez combinando as duas últimas equações temos

1 U⇤
r
∂U τ0
= = (2.14)
∂z l ρ l
onde U ⇤ é a fricção à velocidade.
Se a superfı́cie não é rugosa, pode-se assumir que l = kz, com k = 0, 4 (constante de von
Karman), e assim a equação anterior pode ser integrada de z0 a z, na qual z0 é o comprimento
da rugosidade da superfı́cie, perfazendo
✓ ◆
U⇤ z
U (z) = ln (2.15)
k z0
que é conhecida como o perfil logarı́tmico eólico.
A integração é feita a partir de z0 e não zero pois as superfı́cies sempre apresentam rugosi-
dades, mostradas na Tabela 2.1
A última equação pode ser escrita como

k
ln(z) = U (z) + ln(z0 ) (2.16)
U⇤
a partir da qual com dados experimentais se pode determinar os parâmetros U ⇤ e z0 . Essa
lei é tipicamente utilizada para determinar as relações entre U a diferentes alturas
⇣ ⌘
z
U (z) ln z0
fc = = ⇣ ⌘ (2.17)
U (zr ) ln zr
z0


Quadro 2.1: Valores de rugosidade de terreno[7]


Descrição de terreno z0 (mm)
Gelo ou barro muito liso 0,01
Mar aberto e calmo 0,20
Mar agitado 0,50
Neve 3,00
Grama 8,00
Pasto alto 10,00
Pousio 30,00
Cultivo 50,00
Algumas árvores 100,00
Muitas árvores, cercas e alguns prédios 250,00
Floresta 500,00
Subúrbios 1500,00
Centros de cidades com prédios altos 3000,00

A equação 2.17 foi utilizada em nossos cálculos para, a partir de medições a 5m de altura,
comprimento médio de rugosidade z0 de 0,1m (árvores esparsas) e altura de hub de 100m
obter fc = 1.7658 (fator de correção de velocidade de vento para a atual instalação da estação
meteorológica).
Uma maneira melhor de se realizar a estimação do fator z0 de rugosidade seria realizar duas
medições a diferentes alturas e assim deduzir z0 a partir da curva log de perfil de velocidade.
Dado o escopo limitado deste projeto essa medição a diferentes alturas não foi realizada, mas
pode ser um dos parâmetros adicionais interessantes para futuros trabalhos.

2.7.2 Lei de potências


A lei de potências representa um modelo para perfil de U (z) que segue
✓ ◆α
U (z) z
= (2.18)
U (zr ) zr
no qual α também é um parâmetro experimental. Existem diversas maneiras de se estimar
α, mas a que creio que seja mais interessante é a proposta por Counihan[17] , que propõe um α
em função do parâmetro z0 , tal que

α = 0, 096log10 z0 + 0, 016(log10 z0 )2 + 0, 24 (2.19)


válida para 0, 001m < z0 < 10m, sendo a rugosidade z0 em metros.

2.8 Estimativas de recurso eólico


Ao estimar a geração elétrica em determinada usina, ao invés de simplesmente avaliar a
potência gerada por P = (1/2)ρAU 3 , devemos levar em consideração a curva real de geração
do gerador, que leva em consideração diversas perdas aerodinâmicas, mecânicas e elétricas,


v v ( )
u N u N
u 1 X u 1 X
σU = t 2
(Ui − Ū ) = t Ui2 − N Ū 2 (2.21)
N −1 i=1
N −1 i=1

enquanto a potência média por unidade de área é


N
P̄ 1 1 X 3
= ρ U (2.22)
A 2 N i=1 i
A potência média da máquina é
N
1 X
Pw = Pw (Ui ) (2.23)
N i=1
onde Pw (Ui ) é a potência de saı́da definida pela curva de potência de um gerador. Dessa
maneira, a energia gerada por uma máquina é
N
X
Ew = Pw (Ui )(∆t) (2.24)
i=1

que é o resultado que nos interessa calcular neste trabalho.

2.9 Dados para análise de recursos eólicos


Geralmente a análise do potencial para instalação de sı́tios de geração eólica passa por uma
fase inicial de levantamento através de atlas eólicos que são gerados por métodos numéricos e
algumas aferições pontuais. No nosso caso brasileiro, a referência principal é o Atlas do Potencial
Eólico Brasileiro[8].
Embora sejam extremamente úteis, é necessário ter sempre em conta as suas limitações dado
o escopo do trabalho: os atlas geralmente endereçam grandes áreas, e não têm informações
detalhadas sobre o posicionamento de sı́tios onde devam ser instaladas turbinas eólicas. Além
disso, muitas das informações utilizadas para sua construção são provenientes de dados aferidos
com propósitos meteorológicos e/ou de tráfego aéreo, e devem ser adaptadas para as estimativas
de geração eólica. A Figura 2.5 mostra um exemplo de mapa eólico da região nordeste gerado
por esses métodos.
A caracterização de perfis eólicos pode ter diferentes propósitos como

• Instrumentos desenhados para medição e caracterização de recursos eólicos (especı́fico para


esse uso)

• Instrumentos usado por serviços de meteorologia voltada a previsão de tempo

• Instrumentos usados por meteorologia voltada a tráfego aéreo

• Instrumentos de alta freqüência de amostragem para determinar rajadas, turbulências, e


gradientes para analisar respostas de turbinas
Capı́tulo 2. Energia Eólica 

Figura 2.5: Potencial eólico na região nordeste do Brasil de acordo com o Atlas do Potencial
Eólico Brasileiro[8]


Para cada tipo de aferição eólica o instrumental utilizado assim como as alturas das torres
meteorológicas são diferentes. Embora a estação utilizada em nosso sistema não seja ótima
para nenhum dos casos citados e seja desenhada para uso amador, seu baixo custo e fácil
disponibilidade no mercado a fazem candidata para os propósitos deste trabalho. Caso seja
necessária maior precisão das aferições (vide Tabela 3.6 para precisão dos sensores da estação
WH1080), este trabalho poderia ser estendido para outros fabricantes e modelos com diferentes
excursões de valores, exatidão e precisão.
Embora geralmente para estimar recursos eólicos os anemômetros sejam instalados de 20 a
150m de altura, no nosso caso a estação foi instalada a 5m de altura, próxima às estações da
Embrapa e do Cepagri na Unicamp.


com os servidores NTP1 .


As transmissões de dados para o servidor são sempre iniciadas pelo hub cliente, e um script
CGI2 escrito na linguagem Python é executado a cada requisição. Esses scripts são responsáveis,
entre outros aspectos, pela inserção dos dados no banco de dados, que é uma instância do
PostgreSQL3 . Estes servidores são mostrados na Figura 3.2 com o nome Capture Server.
Já o aplicativo de interface com usuário foi contruı́do sobre a arquitetura Vaadin4 . Esta
arquitetura permite que programas para a web sejam escritos em Java da mesma maneira como
seriam escritos para desktop, fazendo a comunicação entre cliente e servidor transparente para
o desenvolvedor. Na Figura 3.2 este aplicativo é mostrado no bloco Presentation Server.
Entre os dois blocos citados está o banco de dados (DB), que armazena os dados provenientes
do Capture Server e permite consultas de diferentes formatos pelo Presentation Server.
Essa arquitetura permite que tenhamos sn servidores tanto para captura como para interface
com usuário com o mesmo banco de dados. Na ocasião do banco de dados estar no seu limite
de capacidade de funcionamento e queda de performance, podemos criar bancos de dados espe-
lhados ou adotar outras medidas para melhorar sua performance, mas isso não será necessário
para o escopo inicial deste projeto.
No software de interface com usuário desenvolvido (Presentation Server ), é apresentada
uma tela com os mapas do Google Maps na qual os marcadores são as estações meteorológicas
associadas ao sistema. Quando estes marcadores são clicados, uma tela com dados em tempo
real e históricos é apresentada. O sistema pode ser acessado via o site http://www.bhuunet.
com/bhuuapp5 . A Figura 3.19 mostra uma captura de tela deste sistema.

3.2 Hub
Para o hardware do hub foi aproveitado o desenvolvimento previamente disponı́vel e parci-
almente abandonado pelo projeto Bhuu6 , mas que carecia de firmware para seu funcionamento.
Este hardware é baseado no microcontrolador PIC32 de 32 bits. Ele possui também um
controlador CAN, um controlador ETHERNET7 um conector para cartões SD que podem ser
acessados via SPI8 . No hardware também está disponı́vel um módulo Zigbee, mas ele não foi
utilizado nesta fase do desenvolvimento do protótipo. Futuramente seria interessante ativá-lo
para que sensores possam se conectar ao hub sem a necessidade de fios.
1
Network Time Protocol
2
Common Gateway Interface
3
http://www.postgresql.org
4
http://www.vaadin.com
5
À época da publicação deste trabalho a interface com o usuário (UI) apresentava lentidão devido à grande
quantidade de pontos coletados. Uma nova versão dessa interface pode ser no futuro adaptada para essa quan-
tidade de dados. Todas as análises quantitativas deste trabalho foram feitas offline, independentemente da
UI
6
O projeto Bhuu é uma iniciativa sem fins lucrativos que tem como objetivo distribuir estações meteorológicas
em diversas regiões do globo e ser uma fonte independente de informações climáticas focada na interação do
grande público com a meteorologia através de redes sociais
7
O padrão ETHERNET geralmente é utilizado em conjunto com o popular padrão de “cabeamento azul”
CAT5.
8
Serial Peripheral Interface Bus
Capı́tulo 3. Sistema de aquisição de dados 

Para o desenvolvimento de software é necessária a instalação do ambiente de desenvolvimento


do fabricante, chamado MPLAB. Há também uma versão mais moderna disponı́vel chamada
MPLABX, mas na época do desenvolvimento deste sistema (2011–2013) ele ainda era instável
e apresentava problemas em sua interface com o programador e o debugger.
Essencial para o desenvolvimento do firmware também são as bibliotecas fornecidas pelo fa-
bricante do microcontrolador que permitem a utilização de sistemas de arquivos (FAT9 , FAT32),
dispositivos externos à CPU (controlador ETHERNET), protocolos de comunicação TCP10 ,
IP11 , NTP12 e USB, dentre outras. Estes recursos foram amplamente utilizados.

3.3 Aspectos gerais de Firmware


O firmware foi construı́do como um sistema não preemptivo. A própria pilha USB fornecida
pelo fabricante não necessita de um RTOS, e isto reduz as complexidades inerentes à interrup-
ção de processos concorrentes como relações inter-processos e dispositivos compartilhados. Não
utilizar um RTOS também traz a vantagem de ter como resultado um sistema mais determi-
nı́stico. O cuidado que se deve ter ao desenvolver esse tipo de sistema deve ser que uma tarefa
nunca deve consumir a CPU por um tempo arbitrariamente longo, como esperar um input do
usuário ou do servidor. Geralmente estes problemas relacionados à espera de um agente externo
são contornados por máquinas de estado, sendo que a mais emblemática delas é a máquina de
estado da aplicação de cliente que envia os dados do hub para o servidor através do protocolo
TCP/IP.
A Figura 3.4 mostra o funcionamento deste sistema, na qual é representado um loop principal.
Neles estão inseridas:

1. as atividades da pilha USB e da Pilha TCP/IP, que são máquinas de estado que devem
ser executadas periodicamente.

2. Upload de dado instantâneo: esta rotina tenta enviar o instantâneo de todas as medições
periodicamente para o servidor. Caso ela não consiga enviar o pacote por algum problema
na conexão, ela irá guardar o dado em um arquivo local.

3. Upload de dado em arquivo: se houver um arquivo no hub e a conexão estiver ativa, esta
rotina enviará os dados deste arquivo para o servidor e em caso de sucesso da transmissão,
apagará os dados da memória.

4. Download de firmware: esta rotina faz o download de um novo firmware quando ele se
encontra disponı́vel no servidor do Bhuu. Um script deve ser atualizado no servidor para
que informe as estações de que uma nova versão de firmware está disponı́vel.
9
File Allocation Table
10
Transmission Control Protocol
11
Internet Protocol
12
Network Time Protocol


• SDO/MISO: Serial Data Out/Master Input Slave Output

• CS/SS: Chip Select/Slave Select

A comunicação é iniciada pelo circuito integrado mestre (no nosso caso o microcontrola-
dor) através da habilitação de um sinal de CS, e então é produzido um sinal de relógio em
SCLK dentro dos parâmetro aceitáveis pelos escravos (no nosso caso o cartão SD). A partir da
sequência de inicialização do cartão SD, é possı́vel haver dados trafegando em SDI e em SDO.
A transmissão se enc.a com a parada dos pulsos de CLK e suceptiva desativação do sinal de CS.
O sistema construı́do é capaz de ler cartões de memória SD (Secure Digital ). A leitura
e escrita é feita numa partição FAT32 ou FAT16 neles existente. São seis os sinais para a
comunicação entre o micro-controlador e o cartão de memória

Quadro 3.1: Sinais de comunicação do cartão de memória


Sinal SD Correspondente SPI Nome (SD)
CS SS Card Select
DI MOSI Data Input
DO MISO Data Output
SCLK SCLK Interface Clock
CD Card Detect
WP Write Protection

A transmissão de dados o corre já descrita, com o acrécimo opcional dos sinais de detecção de
cartão CD e proteção de escrita WP, que detectam a inserção do cartão e impedem a gravação.
Esses sinais adicionais não foram utilizados.

3.5 Interface USB


A interface USB (Universal Serial Bus) é consideravelmente mais complexa que os antigos
padrões RS232, RS485 ou SPI. Isso porque o USB além de sua interface fı́sica, tem uma in-
terface lógica de endereçamentos de dispositivos e reconhecimento automático (o conceito de
plug-and-play). Apesar disso, é importante entender o funcionamento deste protocolo para re-
alizar a interface com dispositivos como a estação meteorológica utilizada. Isso se dá pois na
ausência de manuais detalhados, com frequência é necessário fazer engenharia reversa a partir
das transmissões que acontecem entre o dispositivo e um PC. Esta comunicação é interceptada
por programas especı́ficos, detalhados à frente.
Esta seção do trabalho é basicamente uma parafraseamento do conteúdo da documentação
USB[18], da documentação da Classe Human Interface Device (HID)[19] e do documento USB
In a Nutshell[20]. Não serão feitas referências singulares, mas nestes três documentos pode-se
encontrar grande parte do material aqui descrito.
O protocolo USB foi concebido com a finalidade de se fazer daisy-chaining de dispositivos, ou
seja, ligar um no outro, reduzindo o número de cabos necessário. Entretanto ele é inerentemente
um protocolo com topologia de estrela e assim, os dispositivos USB são geralmente ligados a
um hub central e não dispõe de saı́das para outros dispositivos.
Capı́tulo 3. Sistema de aquisição de dados 

Quadro 3.2: Padrão de mercado para conectores e cabos USB


Pino Cor do Fio Descrição
1 Vermelho 5V
2 Branco D–
3 Verde D+
4 Preto GND

As velocidades de transmissão do protocolo USB 1.1/2.0 são dadas pela tabela 3.3 (excluindo
os novos padrões USB 3.0 de alta velocidade que fogem ao escopo deste trabalho)

Quadro 3.3: Velocidades do padrão USB


Nome Velocidade (Mb/s) Tolerância (ppm)
High Speed Data (USB 2.0) 480 500
Full Speed Data 12 2.500
Low Speed Data 1,5 15.000

O padrão de transmissão de dados é diferencial (D+ e D–) e a linha de transmissão tem


uma impedância caracterı́stica de 90Ω ± 15%. Quando um dispositivo é conectado ao host
— tipicamente um computador — o dispositivo terá em uma das linhas de dados (D+ ou D–)
um resistor pull-up de 1, 5 KΩ ligado. No caso da linha D+ possuir o resistor, este dispositivo
será enxergado como full speed, e no caso da linha D– possuir o resistor, o dispositivo será
configurado como low speed. Os dispositivos high speed se conectam como full speed e depois
negociam o aumento da taxa de transmissão.
Como muitos dispositivos são alimentados pela própria USB, eles são classificados em low
power, high power, self powered (auto-alimentados) dependendo do nı́vel de uso energético.
Inicialmente os dispositivos se conectam como low power e podem utilizar 100mA. Entretanto
se ele negociar o aumento de corrente do barramento ele pode passar a utilizar 500mA, se
tornando high power. Os dispositivos self powered também podem utilizar 100mA do barramento
USB, mas a maior parte de sua alimentação vem de uma outra fonte. Isso é útil para que
impressoras ou scanners se conectem num primeiro momento ao host sem a necessidade de
estarem fisicamente ligados à rede elétrica.

3.5.2 Package Identifiers (PID)


Toda transmissão USB é iniciada pelo host. Elas têm um Pacote de Token PID (que deter-
mina o que se segue), um Pacote de Dados Opcional (com o payload ) e um Pacote de Status.
A tabela 3.4 mostra todos os tipos de Tokens das transmissões14 .
Como mostramos de maneira resumida na Figura 3.9, os pacotes contém as seguintes partes:

• Sync: 8 bits que sincronizam o clock do receptor e do transmissor

• PID – Packet ID: identifica o tipo de pacote sendo enviado. (Os valores possı́veis são
mostrados na Tabela 3.4). Estes 4 bits são então barrados (invertido) e retransmitidos,
totalizando 8 bits.
14
note que o PID de ERRo é de fato idêntico ao PID do PREamble


Quadro 3.4: Tipos de dados Packet ID


Grupo PID Identificador de Pacote
Token 0001 OUT Token
1001 IN Token
0101 SOF Token
1101 SETUP Token
Data 0011 DATA0
1011 DATA1
0111 DATA2
1111 MDATA
Handshake 0010 ACK Handshake
1010 NAK Handshake
1110 STALL Handshake
0110 NYET Handshake
Special 1100 Preamble
1100 ERR
1000 Split
0100 Ping

• ADDR (opcional): Endereço do dispositivo, que pode ser de 1 a 127. O endereço 0 é


reservado aos dispositivos ainda não identificados que devem responder ao endereço 0

• ENDP (opcional): 4 bits de endereço de endpoint

• CRC (opcional): 5 bits de CRC para verificação de erros (16 bits em pacotes de dados)

• EOP: Fim de pacote (End of Packet): Sinalizado por um SE0 (Single Ended Zero 15 ) de 2
bits, seguidos por um estado J por 1 bit. Em low speed o estado J é um “zero” diferencial,
enquanto em high speed este estado é um “um” diferencial.
Vemos na Tabela 3.4 quatro categorias de pacotes: Token, Data, Handshake e Special. A
seguir segue a descrição dos tipos de pacotes em cada uma destas categorias:
• Pacotes de Token
IN: o host quer ler informações do dispositivo
OUT: o host quer escrever informações no dispositivo
SETUP: utilizado para controlar o inı́cio de transmissão

• Pacotes de Dados: transmitem de 0 a 1023 bytes de dados

• Pacotes de Handshake
ACK: Confirmação que o pacote foi recebido com sucesso
NAK: Informa que o dispositivo temporariamente não pode mandar nem receber
informações. Também utilizado para interromper transmissões
15
Neste estado o sinal diferencial D+ e D– tem um comportamento diferente do normal, no qual ambas as
linhas estão com o sinal em sua tensão mais baixa


ACK (dispositivo): é um handshake que determina recepção com sucesso. Caso houve
problema, o dispositivo deve ignorar

• Estágio de DADOS (opcional) consiste de uma ou mais transferências IN e OUT. O


estágio SETUP define o total de dados a serem transferidos.

IN (host): Enviado quando o host quer receber dados do dispositivo. Este pacote
é seguido pelo pacote DATAx (dispositivo) e então ACK (host), quando o dispositivo
tem dados para enviar. Caso o dispositivo tenha problemas com o CRC ou o PID não
corresponde com o PID barrado, ele responderá com o pacote STALL (dispositivo). Caso
a transmissão do IN tenha sido bem sucedida mas o dispositivo não tem dados no buffer
para serem transmitidos, ele responde com NAK (dispositivo).

OUT (host): Enviado quando o host quer enviar dados para o dispositivo. Este
pacote é seguido pelo pacote DATAx (host). Quando a transmissão do OUT foi bem
sucedida, o dispositivo responde com um ACK (dispositivo). Quando a transmissão do
OUT foi bem sucedida, mas o dispositivo deseja que o host espere um pouco para enviar
o próximo pacote, o dispositivo responde com um NACK (dispositivo) para interromper
a transmissão. No caso de um erro na transmissão o dispositivo responde com um pacote
STALL (dispositivo)

• Estágio de STATUS: muito semelhante ao estágio de dados, mas o pacote DATA enviado
é DATA0 e seu tamanho é nulo. Esta estágio é utilizado para validar a transação como
um todo.

3.5.5 Interrupt Transfer


As transferências por interrupção têm latência menor, detecção de erro e são unidirecio-
nais. Usando o conceito de inı́cio por interrupção do dispositivo, na verdade o host pergunta
periodicamente para o dispositivo se há interrupções que têm de ser tratadas. O formato de
transmissão da transferência por interrupção é o mostrado na Figura 3.12. Esse tipo de trans-
missão é tipicamente utilizado em dispositivos de entrada como mouses e teclados.
A estação meteorológica utilizada neste trabalha utiliza interrupt transfers e control transfers
para sua comunicação com o host.

3.5.6 Isochronous Transfer


As transferências isochronous têm acesso a grande largura de banda da USB, são unidire-
cionais, têm correção de erro mas não o re-envio de informações incorretas e operam somente
nos modos full speed e high speed. Essas transferências também não têm handshake e são ideais
para a transferência de streaming de áudio e vı́deo. Não entraremos em detalhes pois ela não é
foco deste trabalho.
Capı́tulo 3. Sistema de aquisição de dados 

• idVendor e idProduct são também utilizados pelo sistema operacional do host para
encontrar o driver do dispositivo

• bcdDevice tem o mesmo formato do bcdUSB e pode ser utilizado pelo desenvolvedor
para alocar a versão do dispositivo

• os três string descriptors fornecem detalhes sobre o fabricante, produto e número de


série. São opcionais e caso não sejam utilizados devem conter o ı́ndice 0

• bNumconfigurations determina o número de configurações que o dispositivo suporta na


velocidade atual

Quadro 3.5: Device Descriptors


Campo Tamanho Tipo Descrição
bLenght 1 Número Tamanho do Descriptor em Bytes (inclusos
os cabeçalhos) – 18 bytes
bDescriptorType 1 Constante Device Descriptor – 0x01
bcdUSB 2 BCD Número de especificação USB
bDeviceClass 1 Classe Class Code
Se for igual a zero, cada interface especifica
seu class code
Se for igual a 0xFF, o class code é especifi-
cado pelo fabricante
Caso contrário é um class code válido
bDeviceSubClass 1 Sub Classe Subclass Code (Dado pelo USB Org.)
bDeviceProtocol 1 Protocolo Protocol Code (Dado USB Org.)
bMaxPacketSize 1 Número Tamanho máximo de pacote para o endpoint
zero. Tamanhos válidos são 8, 16, 32 e 64
idVendor 2 ID ID do Fabriante (Dado pelo USB Org.)
idProduct 2 ID ID do Produto (Dado pelo fabricante)
bcdDevice 2 BCD Número de Device Release
iManufacturer 1 Index Index da string descritora do fabricante
iProduct 1 Index Index da string descritora do produto
iSerialNumber 1 Index Index da string descritora do número de série
bNumConfigurations 1 Inteiro Número de configurações possı́veis

3.5.9 Configuration Descriptors


Após os descritores de dispositivo, o segundo nı́vel abaixo na hierarquia de descritores são os
configuration descriptors, que definem as configurações, ou seja, modos alternativos de set-up
do dispostivivo. Eles são apresentados na Tabela 3.6.
Deles podemos citar:

• bNumInterfaces: número de interfaces presentes nesta configuração

• bConfigurationValue: identificador desta configuração especı́fica




• iConfiguration: é um index para uma string contendo informações sobre esta configu-
ração

• bmAttributes: especifica os parâmetros de potência da configuração do dispositivo

• bMaxPower: especifica a corrente máxima a ser utilizada pelo dispositivo em múltiplos


de 2mA

Quadro 3.6: Configuration Descriptors


Campo Tamanho Tipo Descrição
bLenght 1 Número Tamanho do descritor em Bytes (inclusos os
cabeçalhos) – 18 bytes
bDescriptorType 1 Constante Configuration Descriptor – 0x02
wTotalLenght 2 Número Tamanho total dos dados retornados
bNumInterfaces 1 Número Número de Interfaces
bConfigurationValue 1 Número Valor a ser usado como argumento para sele-
cionar esta configuração
iConfiguration 1 Index Index da string descrevendo esta configura-
ção
bMmAttributes 1 Bitmap D7: Bus Powered
D6: Self Powered
D5: Remote Wakeup
D4..0: Reserved (0)
bMaxPower 1 mA Consumo máximo de potência

3.5.10 Interface Descriptors


O terceiro nı́vel da hierarquia de descritores é o de interface descriptors (Veja Figura 3.10)
Eles podem, como já dito, serem diversos e estarem ativados simultaneamente. Eles são apre-
sentados na Tabela 3.7.
Deles podemos citar:

• bInterfaceNumber: Este valor deve se iniciar por zero e ser incrementado a cada nova
interface do dispositivo

• bAlternateSetting: Pode ser utilizado para especificar interfaces alternativas.

• bmAttributes: especifica os parâmetros de potência da configuração do dispositivo

• bMaxPower: especifica a corrente máxima a ser utilizada pelo dispositivo em múltiplos


de 2mA
Capı́tulo 3. Sistema de aquisição de dados 

Quadro 3.7: Descritores de Interface (Interface Descriptors)


Campo Tamanho Tipo Descrição
bLenght 1 Number Size of Descriptor in Bytes
bDescriptorType 1 Constant Interface Descriptor – 0x04
bInterfaceNumber 2 Number Number of Interface
bAlternateSetting 1 Number Value used to select alternative setting
bNumEndpoints 1 Number Number of Endpoints used for this interface
bInterfaceClass 1 Index Class Code (Assigned by USB Org)
bInterfaceSubClass 1 Bitmap Subclass Code (Assigned by USB Org)
bInterfaceProtocol 1 mA Protocol Code
iInterface 1 mA Index of String Descriptor Describing this in-
terface

3.5.11 Endpoint Descriptors


Os descritores de endpoint o nı́vel mais baixo na hierarquia de descritores USB e são usados
para configurar endpoints que não o endpoint 0, pois este é sempre um endpoint de controle.
Podemos citar dentre os campos da Tabela 3.8 os seguintes campos:

• bEndPointAddress: Identifica o endpoint que será descrito

• bmAttributes: Identifica o modo de transferência que será utilizado pelo endpoint

• wMaxPacketSize: Especifica o payload máximo deste endpoint

• bInterval: especifica a corrente máxima a ser utilizada pelo dispositivo em múltiplos de


2mA

3.5.12 String Descriptors


Os descritores de string são utilizados nas codificações dos descritores para introduzir textos
legı́veis por humanos, e são opcionais. Quando não utilizados, devem ser zero.
Eles são codificados no formato UNICODE e a primeira posição descreve a lı́ngua utilizada
em uma codificação presente na especificação USB.

3.5.13 Pacote de Setup


O default pipe (pipe padrão), no endpoint zero de cada dispositivo USB deve responder aos
pacotes de setup. Eles são utilizados para a detecção e configuração ds dispositivos.
Para que uma detecção de dispositivo seja bem sucedida, existem como condicionantes de-
terminados requisitos temporais de resposta, como:

• Todas as requisições devem ser respondidas pelo dispositivo USB em ao menos 5 segundos

• As requisições de Standard Device quando não no estágio de dados devem ser respondidas
em 50ms


Quadro 3.8: Descritores de Endpoint (Endpoint Descriptors)


Field Size Type Description
bLenght 1 Number Size of Descriptor in Bytes (7 bytes)
bDescriptorType 1 Constant Endpoint Descriptor – 0x05
bEndpointAddress 2 Endpoint Endpoint Address, Encoded as follows
0..3b: Endpoint Number
4..6b: Reserved. Set to Zero
7b: Direction (Ignored for Control End-
points)
0 = OUT Endpoint
1 = IN Endpoint
bmAttributes 1 Bitmap Bits 0..1: Transfer Type
00 = Control
01 = Isochronous
10 = Bulk
11 = Interrupt
Bits 2..7: Reserved
Bits 3..2: Synchronisation Type (Iso Mode)
00 = No Synchonisation
01 = Asynchronous
10 = Adaptive
11 = Synchronous
Bits 5..4: Usage Type (Iso Mode)
00 = Data Endpoint
01 = Feedback Endpoint
10 = Explicit Feedback Data Endpoint
11 = Reserved
wMaxPacketSize 1 Number Maximum Packet Size this endpoint is capa-
ble of sending or receiving
bInterval 1 Number Interval for polling endpoint data transfers.
Value in frame counts. Ignored for Bulk &
Control Endpoints. Iso must equal 1 and fi-
eld may range from 1 to 255 for interrupt
endpoints.

Quadro 3.9: Descritores de String Zero (String Descriptors Zero)


Field Size Type Description
bLenght 1 Number Size of Descriptor in Bytes
bDescriptorType 1 Constant String Descriptor – 0x03
wLANGID[0] 2 Number Supported Language (code 0)
wLANGID[1] 2 Number Supported Language (code 1)
wLANGID[2] 2 Number Supported Language (code 2)
Capı́tulo 3. Sistema de aquisição de dados 

Quadro 3.10: Descritores de String Subsequentes (String Descriptors)


Field Size Type Description
bLenght 1 Number Size of Descriptor in Bytes
bDescriptorType 1 Constant String Descriptor – 0x04
bString n Unicode String

• As requisições de Standard Device quando no estágio de dados devem ser respondidas em


500ms depois da requisição, sendo que:
Cada pacote de dados deve ser transmitido dentro do intervalo de até 500ms do pacote
de dados anterior (bem-sucedido)
O estágio de status deve estar finalizado dentro de 50ms da transmissão do último
pacote de dados

• O comando SetAddress deve retornar o status em até 50ms, sendo que o dispositivo tem
2ms para mudar o seu endereço atual

No pacote de setup:

• o campo bmRequestType determina a direção e tipo da requisição, assim como seu


destinatário

• o campo bRequest determina o tipo de requisição sendo feita.

Quadro 3.11: Pacote de Setup (Setup Packet)


Field Size Type Description
bmRequestType 1 Bitmap D7: Data Phase Transfer Direction
0 = Host to Device
1 = Device to Host
D6..5: Type
0 = Standard
1 = Class
2 = Vendor
3 = Reserved
D4..0: Recipient
0 = Device
1 = Interface
2 = Endpoint
3 = Other
4..31 = Reserved
bRequest 1 Value Request
wValue 2 Value Value
wIndex 2 Index or Offset Index
wLenght 2 Count Number of bytes to transfer if there is a data
phase


3.5.14 Standard Device Requests


As standard requests são comuns a todos os dispositivos USB, enquanto as class requests
são particulares para determinadas classes de dispositivos. Para esses dispositivos muitas ve-
zes não são necessários drivers especı́ficos, mas drivers genéricos de classes, como a classe de
armazenamento USB.
Também há as vendor defined requests que são codificadas usando protocolo proprietário do
fornecedor do dispositivo, que tipicamente fornece um driver customizado a ser instalado no
host.
Nas standard requests os parâmetros wValue e wIndex permitem parâmetros adicionais,
sendo que o primeiro é simplesmente um valor e o segundo é um ponteiro para um conjunto
de valores. O parâmetro wLenght determina o número de bytes a serem transferidos caso se
utilize o ponteiro wIndex.
A Tabela 3.12 mostra as standard device requests, a Tabela 3.13 mostra as standard interface
requests, e a Tabela 3.14 as standard endpoint requests.

Quadro 3.12: Requisições Padrão de Dispositivo (Standard Device Requests)


bmRequestType bRequest wValue wIndex wLenght Data
0x80 GET STATUS (0x00) Zero Zero Zero Device
Status
0x00 CLEAR FEATURE (0x01) Feature Se- Zero Zero None
lector
0x00 SET FEATURE (0x03) Device Zero Zero None
Address
0x00 SET ADDRESS (0x05) Descriptor Zero Zero None
Type &
Index
0x80 GET DESCRIPTOR (0x06) Descriptor Zero or Descriptor Descriptor
Type & Lan- Lenght
Index guage
ID
0x00 GET DESCRIPTOR (0x07) Zero Zero or Descriptor Descriptor
Lan- Lenght
guage
ID
0x80 GET CONFIGURATION (0x08) Configuration Zero Zero Configuration
Value Value
0x00 SET CONFIGURATION (0x09) Zero Zero Zero None

A requisição Get Status direcionada ao dispositivo retornará 2 bytes contendo informações


sobre remote wakeup (bit 0) e tipo de alimentação do dispositivo (bit 1). Quando o bit 1 é
ativo, o remote wakeup está habilitado. Quando o bit 0 é ativo, o dispositivo é auto-alimentado
e não depende da alimentação via barramento USB.
A requisição Clear Feature e Set Feature são utilizadas para ativar e desativar bits.
Quando direcionadas ao dispotivo, os únicos bits disponı́veis para serem alterados são o remote
Capı́tulo 3. Sistema de aquisição de dados 

wakeup e self-powered.
Como o nome sugere, a requisição Set Address determina o endereço do dispositivo USB,
sendo os endereços válidos no intervalo [1..127].
Set Descriptor e Get Descriptor são utilizados pelo host para obter o device descriptor,
junto com todos os interface descriptors e endpoint descriptors.
Get Configuration e Set Configuration lêem e ativam diferentes configurações que do
dispositivo. Quando é feita uma requisição Get Configuration para o dispositivo, a resposta
será um valor não-nulo correspondente à sua configuração atual quando alguma delas estiver
ativa. Se nenhuma configuração estiver ativa, a resposta será zero. A mesma codificação de
configurações de dispositivos é utilizada pelo comando Set Configuration que ativa uma destas
configurações.

3.5.15 Standard Interface Requests

Quadro 3.13: Requisições Padrão de Interface (Standard Interface Requests)


bmRequestType bRequest wValue wIndex wLenght Data
0x81 GET STATUS (0x00) Zero Interface Two Interface
Status
0x01 CLEAR FEATURE (0x01) Feature Se- Interface Zero None
lector
0x01 SET FEATURE (0x03) Feature Se- Interface Zero None
lector
0x80 GET INTERFACE (0x0A) Zero Interface One Alternate
Interface
0x01 SET INTERFACE (0x11) Alternative Interface Zero None
Setting

3.5.16 Standard Endpoints Requests

Quadro 3.14: Standard Endpoints Requests


bmRequestType bRequest wValue wIndex wLenght Data
0x82 GET STATUS (0x00) Zero Endpoint Two Endpoint
Status
0x02 CLEAR FEATURE (0x01) Feature Se- Endpoint Zero None
lector
0x02 SET FEATURE (0x03) Feature Se- Endpoint Zero None
lector
0x82 SYNCH FRAME (0x12) Zero Endpoint Two Frame
Number

Nas Standard Endpoints Requests o campo wIndex é utilizado para definir o endereço do
endpoint que é parte do processo de comunicação (bits [0..3]) e também a direção da comunicação
(bit 7).
Capı́tulo 3. Sistema de aquisição de dados 

Figura 3.15: Estrutura dos Report Descriptors HID

O class code de bInterfaceClass é 3 para todos os dispositivos da classe HID. Como há muitos
tipos de dispositivos distintos com diferentes usos, o comitê de especificação decidiu não criar
uma subclasse para cada dispositivo, mas um mecanismo chamado de Report Descriptor, no
qual ao fazer sua enumeração, o dispositivo descreve quais os seus inputs e outputs para o host.
As únicas excessões são alguns teclados e mouses que têm subclasses separadas para utilização
durante os processos de boot, que historicamente têm mais limitação do tamanho do código.
O membro bInterfaceProtocol do Interface Descriptor HID só faz sentido se o bInterface-
SubClass especificar um dispositivo de boot, com o valor 1 para teclados e 0 para mouses. Caso
contrário, seu valor é 0.
Quadro 3.15: Subclasses do HID
Código Subclasse
0x00 Sem subclasse
0x01 Dispositivos de boot
0x02–0xFF Reservados

Quando o HID realiza a enumeração, um dos processos mais importantes é o envio destes
report descriptors. Ao contrário dos outros descritores, ele não é simplesmente uma tabela, mas
ele de fato descreve os campos que são enviados no HID, permitindo que o sistema operacional
do host possa interpretar os comandos mesmo sem ter um driver que tenha sido escrito especi-
ficamente para este dispositivo (veja Figura 3.15). Por exemplo um teclado que tenha também
a função de touchpad ou botões multimı́dia pode ter em seu report descriptor estas funções
adicionais especificadas.


A seguir um exemplo com comentários do report descriptor de um mouse. Cada um dos


textos entre vı́rgulas (geralmente uma linha da tabela) é um item.

Código Descrição
Usage Page (Generic Desk- Esta linha descreve que este dis-
top), positivo é relevante para o desk-
top. Ou seja, esta é uma descri-
ção genérica do dispositivo
Usage (Mouse), Esta linha nos diz que este dispo-
sitivo é um mouse
Collection (Application), Aqui se inicia a descrição de da-
dos que podem ser utilizados por
uma aplicação
Usage (Pointer), Esta aplicação pode utilizar estes
dados para contolar um ponteiro
na tela
Collection (Physical), Aqui se inicia a descrição de um
dado especı́fico. Neste caso, o bo-
tão esquerdo do mouse e a posição
relativa nos eixos X e Y
Report ID (0A), Faz as alterações em um Report
especı́fico, neste caso o 0x0A
Usage (X), Usage (Y), Diz ao host que os dados seguin-
tes estão se referindo respectiva-
mente ao eixo X e Y
Logical Minimum (-127), O mı́nimo lógico destes dados é
-127
Logical Maximum (127), O máximo lógico destes dados é
127
Report Size (8), São dados com 8 bits
Report Count (2), São dois dados
Input (Data, Variable, Input pois é uma entrada para
Relative), o host, Variable pois ela varia
no tempo e Relative pois os da-
dos são relativos a algum eixo, no
caso, os dados anteriores de posi-
ção
Logical Minimum (0), O mı́nimo lógico destes dados a
serem descritos é 0
Logical Maximum (1), O máximo lógico destes dados a
serem descritos é 1 (ou seja, são
binários)
Report Count (3), São três dados
Report Size (1), De um bit
Usage Page (Button Page), O host deve interpretá-los como
botões
Capı́tulo 3. Sistema de aquisição de dados 

Usage Minimum (1), O “botão mı́nimo é o número 1”


Usage Maximum (3), E o “botão máximo é o número 3”
– sendo portanto 3 botões
Input (Data, Variable, Input pois é uma entrada para o
Absolute), host, Variable pois ela varia no
tempo e Absolute pois os dados
não dependem de outros valores
como valores passados
Report Size (5), Adiciona um Report de 5 bits
Input (Constant), Adiciona esse report como uma
constante, para completar o byte
de bitmap dos botões
End Collection, Finaliza a Physical Collection
End Collection Finaliza a Application Collection

O dispositivo HID deve ter os pipes endpoint 0 e o Interrupt In definidos para suas comuni-
cações, enquanto o Interrupt Out é opcional.

3.5.19 USB Host


O USB Host é tipicamente o computador no qual é conectado um dispositivo. Entretanto,
excepcionalmente também é possı́vel que sistemas embarcados sejam hosts. Isso permite que a
estes dispositivos sejam conectadas câmeras fotográficas, armazenamento, e etc.
Em nosso caso, o hub atua como um host, pois a estação meteorológica é o seu dispositivo.
Logo, ele deve suportar os diversos report descriptors que mencionamos. Para o aumento da
produtividade do desenvolvedor, diversos fabricantes de microcontroladores e processadores já
fornecem a pilha USB tanto de dispositivo como de host. Este é o nosso caso.

3.6 Estação meteorológica WH-1080


A estação meteorológica WH-1080 é produzida pelo fabricantes chinês Fine Offset Electro-
nics16 , embora elas sejam revendidas sob a marca de diversos revendedores. Embora não sejam
os instrumentos mais apropriados para a avaliação de potencial eólico, seu baixo custo as torna
muito interessantes. Uma de suas desvantagens é a imprecisão relativamente alta, casos reporta-
dos de dados errados (algum bug?) e sua taxa de atualização lenta, com perı́odo de 48s. Isso as
torna inapropriadas para a medição de turbulência, embora a medida de velocidade de rajadas
(gust) possa ser um parâmetro pelo qual podemos inferı́-la.
A Tabela 3.6 nos mostra suas especificações técnicas conhecidas. Embora o autor tenha
contactado o fabricante diversas vezes, não obteve resposta sobre a acurácia, precisão, drift,
snr, range dinâmico e taxa de amostragem dos parâmetros.
16
Site: http://www.foshk.com/Weather_Professional/WS1080.htm


Quadro 3.17: Especificações técnicas da estação meteorológica WH-1080


Parâmetro Valor
Distância de transmissão de dados 100m
Excursão de temperatura -40 C – 65 C
Resolução de temperatura 0,1 C
Excursão de humidade relativa 10% – 99%
Volume de chuvas 0 – 9999mm
Resolução de chuvas 0,3mm (se volume < 1000mm)
1mm (se volume > 1000mm)
Velocidade de vento 0 – 160km/h
Intervalo de medição do 48s
sensor de temperatura, humidade e pressão
Excursão barométrica 435mmHg – 810mmHg
Resolução barométrica 0,25mmHg

As Figuras 3.16 e 3.17, assim como a Tabela 3.19 mostram as saı́das do programa USBLy-
17
ser , que é utilizado para fazer a interceptação de dados transmitidos pelas portas USB assim
como a análise de protocolo. Com o software fornecido junto com a estação instalado em um
PC, o USBLyser foi usado para interceptar essa comunicação, gerar relatórios e assim realizar
a engenharia reversa da comunicação USB com a estação.
Neles podemos ver na Figura 3.16a o device descriptor da estação meteorológica, e na Figura
3.16b o configuration descriptor e o interface descriptor. A Figura 3.17a nos mostra o report
descriptor HID que descreve os dados a serem enviados pela estação meteorológica, enquanto a
Figura 3.17b mostra os dados enviados pelo host à estação. Estes dados são usados pelo report
seguinte, mostrado na Figura 3.17c, que comanda a estação a usar o report da Figura 3.17b
como entrada para as saı́das que são finalmente enviadas em três relatórios de 8 bits semelhantes
à Figura 3.17d. Nestas saı́das estão finalmente os dados que estamos interessados: temperatura,
direção de vento, intensidade de vento e etc. Este processo também pode ser visto de maneira
sequencial na Tabela 3.19.
Com base nestas informações e também em código já existente, foi construı́do/adaptado um
driver USB que simula um host e permite que estas informações meteorológicas sejam capturadas
pelo hub.
Foi encontrado um documento na internet chamado “WH1080 EEPROM data definition”
(sem referência a autor), que traz alguma documentação a respeito da descrição do mapa de
memória da estação, mas o autor deste trabalho considera a documentação bastante incompleta.
Deste documento, sabemos que do endereço 0x0000 a 0x0100, há variáveis de configuração, assim
como dados históricos de mı́nimos e máximos da estação. A partir do endereço 0x0100 até o
endereço 0x1FFFF, temos dados em um buffer FIFO18 que armazena blocos de 16 bytes de
dados históricos das medições, sendo que os únicos dados de interesse para nós são os mais
recentes, justamente se iniciando na posição 0x0100. A descrição dos dados nos blocos está
17
Site: http://www.usblyzer.com/
18
First-in, first-out
Capı́tulo 3. Sistema de aquisição de dados 

apresentada na Tabela 3.18.




Quadro 3.18: Definição dos dados de interesse da estação meteorológica


Intervalo
Item Bytes Unidade Formato dados Mı́n. Máx. Comentários
Intervalo de amos- 1 Byte minuto HEX 1 240 Intervalo de amostragem
tragem
Humidade relativa 1 Byte 1% HEX 1 99 Um byte
interna
LSB
Temperatura interna 2 Bytes 0.1 ? HEX -400 60 MSB
Humidade relativa 1 Byte 1% HEX 1 99 Um byte
externa
LSB
Temperatura externa 2 Bytes 0.1 ? HEX -400 600 MSB
LSB
ABS P 2 Bytes 0.1 Hpa HEX 920 1080
MSB
Média vel. vento 1 Byte 0.1 m/s HEX 0 500 LSB
Máximo vel. vento 1 Byte 0.1 m/s HEX 0 500 LSB
Vel. vento – High 1 Byte HEX 0 1 MSB
Nibble
Direção vento 1 Byte N/A HEX 0 15 Um byte – 0x80 para dire-
ção de vento inválida, 0 para
N, 1 para NNE, 2 para NEE,
3 para E, 4 para EES, etc
LSB
Pluviosidade total 2 Bytes Hz HEX 0 65535 MSB
bit0
bit1
bit2
bit3
bit4
Status 1 Byte bit5
Flag de da- bit6=1:não foram recebidos
dos válidos dados de sensor
Flag de bit7=1:aconteceu overflow
overflow do contador de nı́vel pluvi-
de pluvio- ométrico
sidade
Capı́tulo 3. Sistema de aquisição de dados
Quadro 3.19: Sequência temporal de enumeração e transferência de dados da estação me-
teorológica WH-1080

Seq Time Duration Request Request Details Raw Data I/O Status Comentários

Inı́cio do processo de enumeração

7 21:37:28.779 Get Descriptor from Device Dvc in


0010-0007 21:37:28.782 2.804 ms Control Transfer Get Descriptor (Dvc) 12 01 10 01 00 00 00 08... in Success Figura 3.16a – descritor do dispositivo
11 21:37:28.782 Get Descriptor from Device Cfg ind:0 in
0014-0011 21:37:28.784 1.954 ms Control Transfer Get Descriptor (Cfg ind:0) 09 02 22 00 01 01 00 80... in Success Figura 3.16b – descritor da primeira configu-
ração
15 21:37:28.784 Get Descriptor from Device Cfg ind:0 in
0018-0015 21:37:28.788 4.499 ms Control Transfer Get Descriptor (Cfg ind:0) 09 02 22 00 01 01 00 80... in Success Figura 3.16b – descritor da primeira configu-
ração com o descritor da interface HID
23 21:37:28.789 Class Interface Set Idle out
0026-0023 21:37:28.790 819 us Control Transfer Set Idle out Success Manda o dispositivo ficar em idle
27 21:37:28.790 Get Descriptor from Interface Report in
0030-0027 21:37:28.796 6.053 ms Control Transfer Get Descriptor (Report) 06 A0 FF 09 01 A1 01 09... in Success Figura 3.17a – report descriptor da interface
HID
67 21:37:28.830 Bulk or Interrupt Transfer 8 bytes buffer in
69 21:37:28.831 Bulk or Interrupt Transfer 8 bytes buffer in

A partir desta linha temos blocos iguais, varrendo incrementalmente 0x0020 bytes da memória da estação meteorológica a cada bloco – memória 0x0000 a 0x001F

130 21:37:30.380 Class Interface Set Report (Output len:8) A1 00 00 20 A1 00 00 20 out Dados são enviados para o endpoint 1 – co-
mando para a leitura dos 32 bytes iniciando
no endereço 0x0000 – (Figura 3.17c)
0133-0130 21:37:30.381 1.124 ms Control Transfer Set Report (Output len:8) out Success Comando é enviado para que os dados sejam
lidos do endpoint 1 e sejam processados (Fi-
gura 3.17b)
0135-0067 21:37:30.400 1.569731 s Bulk or Interrupt Transfer Input Report len:8 55 AA FF FF FF FF FF FF in Success Dados são lidos do dispositivo (Figura 3.17d)
136 21:37:30.400 Bulk or Interrupt Transfer 8 bytes buffer in
0139-0069 21:37:30.408 1.577645 s Bulk or Interrupt Transfer Input Report len:8 FF FF FF FF FF FF FF FF in Success Dados são lidos do dispositivo (Figura 3.17d)
140 21:37:30.408 Bulk or Interrupt Transfer 8 bytes buffer in
0143-0136 21:37:30.416 15.919 ms Bulk or Interrupt Transfer Input Report len:8 1E 20 02 20 09 00 00 00 in Success Dados são lidos do dispositivo (Figura 3.17d)
144 21:37:30.416 Bulk or Interrupt Transfer 8 bytes buffer in
0147-0140 21:37:30.424 15.957 ms Bulk or Interrupt Transfer Input Report len:8 00 7F 00 01 00 00 00 01 in Success Dados são lidos do dispositivo (Figura 3.17d)
148 21:37:30.424 Bulk or Interrupt Transfer 8 bytes buffer in

Final do primeiro bloco e inı́cio do segundo bloco – memória 0x0020 a 0x003F

150 21:37:30.424 Class Interface Set Report (Output len:8) A1 00 20 20 A1 00 20 20 out Dados são enviados para o endpoint 1 – co-
mando para a leitura dos 32 bytes iniciando
no endereço 0x0020
0153-0150 21:37:30.426 1.260 ms Control Transfer Set Report (Output len:8) out Success Comando é enviado para que os dados sejam
lidos do endpoint 1 e sejam processados
0155-0144 21:37:30.440 23.951 ms Bulk or Interrupt Transfer Input Report len:8 94 27 65 24 00 00 00 00 in Success Dados são lidos do dispositivo
156 21:37:30.440 Bulk or Interrupt Transfer 8 bytes buffer in
0159-0148 21:37:30.448 23.889 ms Bulk or Interrupt Transfer Input Report len:8 00 00 00 07 01 01 12 02 in Success Dados são lidos do dispositivo
160 21:37:30.448 Bulk or Interrupt Transfer 8 bytes buffer in
0163-0156 21:37:30.456 15.989 ms Bulk or Interrupt Transfer Input Report len:8 41 23 C8 00 00 00 46 2D in Success Dados são lidos do dispositivo
164 21:37:30.456 Bulk or Interrupt Transfer 8 bytes buffer in
0167-0160 21:37:30.464 16.000 ms Bulk or Interrupt Transfer Input Report len:8 2C 01 64 80 C8 00 00 00 in Success Dados são lidos do dispositivo
168 21:37:30.464 Bulk or Interrupt Transfer 8 bytes buffer in

Final do segundo bloco e inı́cio do terceiro bloco – memória 0x0040 a 0x005F

170 21:37:30.464 Class Interface Set Report (Output len:8) A1 00 40 20 A1 00 40 20 out Dados são enviados para o endpoint 1 – co-
mando para a leitura dos 32 bytes iniciando
no endereço 0x0040


0173-0170 21:37:30.465 1.131 ms Control Transfer Set Report (Output len:8) out Success Comando é enviado para que os dados sejam
lidos do endpoint 1 e sejam processados
0175-0164 21:37:30.480 24.012 ms Bulk or Interrupt Transfer Input Report len:8 64 00 64 80 A0 28 80 25 in Success Dados são lidos do dispositivo
176 21:37:30.480 Bulk or Interrupt Transfer 8 bytes buffer in
0179-0168 21:37:30.488 23.972 ms Bulk or Interrupt Transfer Input Report len:8 A0 28 80 25 00 B4 00 00 in Success Dados são lidos do dispositivo
180 21:37:30.488 Bulk or Interrupt Transfer 8 bytes buffer in
0183-0176 21:37:30.496 15.895 ms Bulk or Interrupt Transfer Input Report len:8 68 01 00 0A 00 F4 01 12 in Success Dados são lidos do dispositivo
184 21:37:30.496 Bulk or Interrupt Transfer 8 bytes buffer in
0187-0180 21:37:30.504 16.043 ms Bulk or Interrupt Transfer Input Report len:8 00 00 00 00 00 00 00 00 in Success Dados são lidos do dispositivo
188 21:37:30.504 Bulk or Interrupt Transfer 8 bytes buffer in

Final do terceiro bloco e inı́cio do quarto bloco – memória 0x0060 a 0x007F

190 21:37:30.504 Class Interface Set Report (Output len:8) A1 00 60 20 A1 00 60 20 out Dados são enviados para o endpoint 1 – co-
mando para a leitura dos 32 bytes iniciando
no endereço 0x0060
0193-0190 21:37:30.505 1.218 ms Control Transfer Set Report (Output len:8) out Success Comando é enviado para que os dados sejam
lidos do endpoint 1 e sejam processados
0195-0184 21:37:30.520 24.063 ms Bulk or Interrupt Transfer Input Report len:8 00 00 47 1C 63 0B 4D 01 in Success Dados são lidos do dispositivo
196 21:37:30.520 Bulk or Interrupt Transfer 8 bytes buffer in
0199-0188 21:37:30.528 23.898 ms Bulk or Interrupt Transfer Input Report len:8 C3 00 1E 01 0A 81 1E 01 in Success Dados são lidos do dispositivo
200 21:37:30.528 Bulk or Interrupt Transfer 8 bytes buffer in
0203-0196 21:37:30.536 15.932 ms Bulk or Interrupt Transfer Input Report len:8 0A 81 EE 00 01 00 91 24 in Success Dados são lidos do dispositivo
204 21:37:30.536 Bulk or Interrupt Transfer 8 bytes buffer in
0207-0200 21:37:30.544 16.107 ms Bulk or Interrupt Transfer Input Report len:8 F1 23 1B 28 4A 27 00 00 in Success Dados são lidos do dispositivo
208 21:37:30.544 Bulk or Interrupt Transfer 8 bytes buffer in

Final do quarto bloco – os blocos seguintes não são mostrados pois seguem padrão semelhante


Capı́tulo 3. Sistema de aquisição de dados 

3.7 Interface Ethernet e TCP/IP


Os protocolos TCP19 e IP20 assim como a interface ETHERNET são bastante complexos,
como o protocolo USB. Entretanto, como não é necessário realizar engenharia reversa neles,
não é necessário entender minúcias, mas simplesmente utilizar as bibliotecas fornecidas pelo
fabricante, assim como notas de aplicação.
Analizando a Figura 3.18, que mostra o esquemático na área pertinente a essa interface
vemos o componente ENC424J600 que é um controlador da interface ETHERNET que funciona
a partir de uma interface SPI. Ele é o responsável pela conversão dos nı́veis de tensão diferenciais
do padrão ethernet e do recebimento e envio de pacotes neste formato, comunicando-se via o
protocolo SPI (bem mais simples) com o PIC32. Este tem a pilha TCP/IP fornecida pelo
fabricante, facilitando o desenvolvimento de aplicações.

3.8 Banco de dados e servidor


Os servidores de banco de dados, captura os dados do hub e interface com usuário estão
todos hospedados no mesmo servidor virtual no provedor Linode.com. A vantagem de servidores
virtuais (nos quais várias máquinas rodam virtualizadas na mesma máquina fı́sica) é seu preço
atrativo, mantendo controle total da máquina.
O banco de dados que foi utilizado é o PostgreSQL, que é um banco de dados relacional com
15 anos de desenvolvimento ativo e com bancos de dados hoje em uso maiores que 4 Terabytes.
A estrutura dos campos criados na principal tabela do banco de dados segue o seguinte
padrão da Tabela 3.20.
Como se pode ver, não há distinção de tabela por tipo de dado armazenado, seja tempera-
tura, pressão, humidade, intensidade de vento ou qualquer outra grandeza. O propósito desta
arquitetura é estimular a diversidade de parâmetros medidos com o mı́nimo possı́vel de adap-
tações ao sistema. Hoje a matriz de equivalência numérica a cada uma das grandezas medidas
é mostrada na Tabela 3.21, e pode ser facilmente expandida.
A inserção de dados no servidor é feita através de um script que recebe um pacote de dados
do hub e o insere de maneira apropriada no banco de dados. Seu papel é desencapsular uma
requisição POST feita pelo hub, ler um pacote codificado na estrutura JSON21 e colocar cada
dado em uma nova entrada no banco de dados.
Este programa de captura é capaz de lidar com um conjunto singular de dados instantâneos,
e também com uma requisição que envia simultaneamente uma grande quantidade de dados
passados, como ocorre quando o hub permanece sem conexão com a internet e seus dados são
guardados temporariamente no cartão de memória. Neste caso, somente após o restabelecimento
da conexão o hub fará upload da carga de dados.
Não é necessário detalhar as outras tabelas do sistema, mas vale mencioná-las:

• hubs: descrição textual do hub, informações de georeferenciamento, e código do dono


19
Transmission Control Protocol
20
Internet Protocol
21
Esta estrutura exerce um papel semelhante ao XML, mas é notavelmente mais leve.
Capı́tulo 3. Sistema de aquisição de dados 

Quadro 3.20: Campos da principal tabela do bando de dados: datapoints


campo tipo observação
id inteiro auto gerada e utili-
zada como chave pri-
mária
sensorid inteiro tipo de sensor (tempe-
ratura, pressão, humi-
dade, etc)
hubid inteiro identificação do hub,
que é uma chave es-
trangeira referenciada
pela tabela de hubs
value float ponto flutuante valor armazenado
(temperatura, pres-
são, ...)
version inteiro campo interno utili-
zado pelo sistema do
aplicativo web
timestamp data e hora hora da medição
statistical classification inteiro para uso futuro, neste
campo diferencia-
remos uma média,
máxima, mı́nima,
mediana, etc

Quadro 3.21: Grandezas suportadas atualmente


codificação grandeza unidade
1 pluviometria mm desde a instalação
2 pressão atmosférica mPa
3 temperatura interna C
4 temperatura externa C
5 humidade interna % de saturação de
H2 O
6 humidade externa % de saturação de
H2 O
7 direção do vento codificação:
0: Norte
4: Leste
8: Sul
12: Oeste
8 média de velocidade de vento m/s
9 máxima de velocidade de vento m/s


• owners: cadastro dos donos de hubs

• sensors: cadastro dos tipos de sensores (descritos na Tabela 3.21)

3.9 Interface com usuário


Nesta primeira versão da interface com usuário, ele apresenta as diversas estações meteo-
rológicas instaladas como pontos em uma tela do Google Maps. Na Figura 3.19 mostramos
um exemplo de uma captura de tela que exemplifica estes marcadores. Quando pressionados os
marcadores, os dados referentes a esta estação são mostrados na metade inferior da tela e podem
ser selecionados por um menu drop-down que apresenta todas as variáveis medidas. Também se
pode selecionar as estações através de um drop-down que realiza uma busca no banco de dados
de localidades disponı́veis para consulta.
O sistema BhuuApp permite exportar estes dados no formato .xls do Microsoft Excel. Esta
propriedade é interessante para que profissionais possam fazer análises numéricas mais pro-
fundas dos dados armazenados no sistema. Deseja-se construir uma API22 para que outros
usuários possam construir aplicativos que utilizam a infra-estrutura existente e possam fornecer
funcionalidades adicionais, como regressões temporais e regras de negócio entre vários dados de
entrada.
O site está disponı́vel para acesso na data de publicação deste trabalho no endereço Site:
http://www.bhuunet.com/bhuuapp/.

3.10 Montagem
A parte interna da estação WH-1080 foi instalada dentro de uma caixa impermeável. Junto
a ela foi instalada uma fonte de alimentação e um roteador para redes de telefonia celular,
permitindo que fosse feito o upload de dados sem conexão fı́sica à internet.

22
Application Programming Interface


Figura 3.20: Caixa de Instalação da estação meteorológica mostrada aberta

Figura 3.21: Visão inferior da montagem


Capı́tulo 3. Sistema de aquisição de dados 

Figura 3.22: Momento de instalação da estação no mastro

Figura 3.23: Visão geral do local de instalação da estação meteorológica de testes


Capı́tulo 4
Testes e Validação

Os dados presentes no Banco de Dados foram extraı́dos e importados no Matlab, aplicativo


utilizado para realizar as análises numéricas deste trabalho. Os dados de geração são baseados
em uma turbina GE TC3 2.5MW que possui a curva aproximada de resposta de geração mos-
trada na Figura 4.2. Supõe-se uma instalação com o hub a 100m do solo para a extrapolação
dos dados eólicos.
Também comparamos estes dados com uma estação meteorológica do CEPAGRI. Inicial-
mente esta estação esteve instalada no mesmo local de nossa estação, mas depois ela foi movida
para um local próximo (22 48’56.0”S 47 03’28.0”O), enquanto a nossa estação está instalada em
(22 49’07.0”S 47 03’43.5”O). Ambas as estações têm seus anemômetros a 5m do solo.
Dada a natureza ainda experimental do sistema, foi necessário trabalhar os dados quanto às
interrupções das séries temporais e variações dos intervalos entre medições. A maior parte dos
pontos de medição de nossa estação têm intervalos de 1min, mas também há outros intervalos
de medição. A estação meteorológica do CEPAGRI tem medições com intervalos de 10min.
A Figura 4.1 mostra este processo. Os dados de velocidade de vento crus medidos a 5m são
multiplicados pelo fator de correção para a altura de um hub (100m) e interpolados na curva
de geração do aerogerador. A potência resultante é então multiplicada pela representatividade
temporal do ponto, que é o menor valor entre (a) o intervalo entre ele e o próximo ou (b) 20min.
O tempo e a energia gerada resultantes são então integrados para a obtenção do parâmetro de
potência média de geração.
Os dados obtidos foram os seguintes: a Rosa dos Ventos a z = 5m (Figura 4.3) mostra uma
maior incidência de ventos nas direções S e SE, a maior parte na faixa de 0–4 m/s. A rosa dos
ventos da estação meteorológica do CEPAGRI está mostrada na Figura 4.4.
A Figura 4.6 mostra a integral da geração estimada no local. Nota-se um platô estagnado de
geração durando o mês de setembro/2013. Isso se deve a um problema na estação, que deixou
de enviar dados nesse perı́odo. Na Figura 4.6 vemos os sete primeiros dias de geração. Com o
seu “zoom” temporal maior é possı́vel perceber a variação na geração estimada para as diferentes
horas do dia.
O histograma da figura 4.5 mostra o perfil estocástico dos ventos na estação, lembrando de
fato a tı́pica curva de distribuição Weibull esperada.
A Figura 4.8 contempla as integrais de geração potencial de ambas as medições (FEAGRI


Capı́tulo 4. Testes e Validação 

Figura 4.3: Rosa dos Ventos a 5m

Figura 4.4: Rosa dos Ventos a 5m (estação FEAGRI)




Figura 4.5: Histograma de incidência de velocidades de vento

Figura 4.6: Integralização da energia gerada estimada


Capı́tulo 4. Testes e Validação 

Figura 4.7: Integralização da energia gerada estimada nos 7 primeiros dias de medição

Figura 4.8: Integralização da energia gerada (intervalo contı́nuo nas duas sequências)


e sistema montado). Embora os sinais sejam sinais muito correlacionados, eles não podem ser
comparados diretamente pois são instalações em locais distintos e com intervalos de medição
muito diferentes. Ainda sim, para esta série de dados podemos afirmar que a divergência da
integral de energia foi menor que 20%.
Capı́tulo 5
Conclusão

Neste trabalho procurou-se disponibilizar o substrato técnico para avaliações de potencial


eólico utilizando recursos de baixo custo e visando a sua utilização por agentes que tipicamente
não teriam acesso a esse tipo de tecnologia, como prefeituras de pequenas cidades e comunidades
onde se crê que há potencial de geração eólica, mas não se possui as ferramentas para prová-lo.
Seria possı́vel que essas regiões se beneficiassem dos royalties provenientes da geração eólica.
Hoje a questão dos royalties da energia eólica é muito discutida em diversas partes do mundo,
como na Alemanha, onde as usinas do norte rural alimentam a indústria tipicamente instalada
no sul do paı́s.
Ainda que no Brasil essa discussão ainda não tenha sido formulada pelo percentual pequeno
do aproveitamento eólico no paı́s, assim como o peso das discussões de royalties do petróleo
do pré-sal, acredita-se que seja uma questão de tempo para que o tópico surja pois os maio-
res potenciais eólicos brasileiros se encontram em localidades com ı́ndices de desenvolvimento
humano mais baixo, assim como acontece com as recentes obras de grandes usinas hidrelétri-
cas. Além disso, as recentes estiagens no centro-sul e o fantasma de apagões têm questionado a
sustentabilidade de nossa atual matriz energética baseada em hidroeletricidade.
Provou-se com este trabalho que embora os resultados levantados por uma estação meteoro-
lógica doméstica tenham divergências em relação a estações profissionais calibradas e aferidas,
é possı́vel sim utilizá-los como parâmetro base para da estimativa dos padrões eólicos e sua
conseqüente geração de energia elétrica.
Uma possı́vel ampliação dos resultados deste trabalho seria uma ampliação da análise para
outros parâmetros ambientais pertinentes à geração de outras categorias de energia renovável,
especialmente a aferição do nı́vel de insolação diário com intuito de estimar a geração de usinas
fotovoltaicas.


Bibliografia

[1] World Energy Insight 2010. OECD/IEA, 2010.

[2] J. D. Sachs, Common Wealth: Economics for a Crowded Planet. Penguin Books, 2009.

[3] U. Nations, World Population to 2300. New York: United Nations, Department of Econo-
mic and Social Affairs, 2004.

[4] P. Kruger, Alternative Energy Resources: The Quest for Sustainable Energy. John Wiley
& Sons, Inc, 2006.

[5] Setor Elétrico Brasileiro Oportunidades na Expansão de Geração. 2011.

[6] S. C. Russell, “Wind Energy for the Perplexed.”

[7] J. F. Manwell, J. G. McGowan, and A. L. Rogers, Wind energy explained: theory, design
and application. John Wiley & Sons, Inc, 2002.

[8] M. Brower, J. Zack, and C. Eolica, “Atlas do Potencial Eólico Brasileiro,” tech. rep., 2001.

[9] “microSD Card,” PQI, 2006.

[10] Wikipedia, “Universal Serial Bus,” 2012.

[11] “We are 7 billion – A quick guide to the population of the planet,” The Economist Online,
2011.

[12] B. Metz, O. Davidson, P. Bosch, R. Dave, and Ipcc, “Summary for policymakers,” Climate
change, vol. 1, 2007.

[13] “G-20: Declaração dos lı́deres,” (Pittsburgh), pp. 1–28, G-20, Cúpula de Pittsburgh, 2009.

[14] World Energy Outlook, vol. 23. 2008.

[15] J. J. A. Alves, “Análise regional da energia eólica no Brasil,” Revista Brasilera de Gestão e
Desenvolvimento Regional, vol. 6, no. 1, pp. 165–188, 2010.

[16] Vaisala Wind Tower System WTS140. 2011.




[17] J. Counihan, “Adiabatic atmospheric boundary layers: a review and analysis of data from
the period 1880–1972,” Atmospheric Environment (1967), vol. 9, no. 10, pp. 871–905, 1975.

[18] Universal Serial Bus (USB) Device Class Definition. 2001.

[19] S. Justice, “AN1163: USB HID Class on an Embedded Device,” tech. rep., Microchip
Technologies Inc, 2008.

[20] C. Peacock, USB in a Nutshell. 2002.

[21] E. Abreu, Consolidação no Setor Elétrico Brasileiro. 2011.

Você também pode gostar