Cálculos para o Monitor de Energia Elétrica
Rec 02-fev-2008 19:08
Leitores habituais deste
blog já sabem que eu venho projetando um
dispositivo para registrar horários e durações de quedas de energia,
juntamente com alguns parâmetros tais como voltagem e freqüência.
Se você é novo por aqui, primeiro leia os
posts sobre o
conceito e requisitos iniciais,
o conversor de nível serial isolado que projetei
e a
escolha do microcontrolador e pinagem.
Hoje é dia de pensar como faremos as medidas. Há dois conjuntos delas: as
usadas para detectar as falhas no fornecimento de energia e as usadas para
exibirmos no mostrador. Vamos começar pelos últimos, apesar de serem mais
complicados que os primeiros.
A propósito: à medida em que for lendo este
post, pode ser útil conferir os
valores correspondentes na
planilha do Excel
com todos esses cálculos.
Antes de mais nada, decidi usar um cristal de 8MHz como fonte do
clock porque
intuitivamente antevejo que vai nos dar velocidade de sobra e eu por acaso tenho
um aqui que tem escrito "8.000000". Eu duvido que ele seja tão preciso quanto
a quantidade de dígitos decimais sugere, mas, ora, vamos experimentar.
Definindo os registradores do divisor de freqüência da UART para 51, obteremos
9.615 bps, que está a negligíveis 0,2% da velocidade padrão de 9.600bps, de
sorte que podemos esperar comunicação serial confiável e descomplicada.
O projeto original da unidade de condicionamento de sinal (UCS), combinado
com o transformador de 200V-6V resultou no que eu considerei uma pequena
desvantagem: o dispositivo não funcionará em 110V -- a essa voltagem, o
enrolamento secundário do transformador produzirá apenas 3V e precisamos de
pelo menos 5,6V na entrada do regulador de voltagem. Poderíamos colocar um
seletor de voltagem 110-220V, mas isso seria irritante -- teríamos de
recalibrar o dispositivo após trocar a voltagem de operação, tornando-se
uma fonte potencial para erros do usuário.
Ao invés, troquei o transformador original por um de 220V-12V. Assim,
nosso dispositivo se torna "auto-volt". De fato, quando operando sob
220V, o transformador vai jugar 17VDC no regulador, que se encarregará
de baixá-la para 5V. Como planejamos manter o consumo por volta de 10mA,
chuto que mesmo essa diferença não fará com que o regulador esquente
demais. Quando rodando sob 110V, o regulador receberá 8,5VDC, bem acima
dos 5,6V mínimos que o regulador precisa para manter os 5V de saída bem
regulados. Um problema potencial é esses 8,5V estão abaixo dos 9V
providos pelas baterias, de sorte que um simples diodo não dará conta.
Nota para mim mesmo: projetar um comutador baseado em transistor com
uma voltagem de comutação específica.
Outra conseqüência da troca de transformador é que precisamos aumentar
o valor de R1 na UCS para manter as voltagens de pico indo para os
pinos do ADC0 e ICP do AVR abaixo de 5V. Aumentei-o para 33k, de forma
que uma voltagem de 220Vrms deve gerar um pico de 3,95V após a UCS.
À voltagem máxima de 5V, o dispostivo pode aceitar uma entrada de no
máximo 278Vrms (cerca de 26% de sobrevoltagem). Se passar disto, os
diodos de proteção embutidos nos pinos do AVR e o zener de 5,1V
na UCS deverão evitar que o microcontrolador frite -- ou pelo menos
essa é a esperança.
A figura abaixo mostra a onde após a SCU -- isto é, após a retificação
de onda completa pela ponte de didos e após os resitores divisores
de voltagem:
Primeiro, se definirmos o divisor de entrada do Timer1 para 64, o clock do Timer1
será de 8MHz/64=125KHz. Como a figura acima mostra, isso significa que cada três
semiciclos durarão exatamente 3125 contagens do Timer1 e que cada semiciclo durará
1041.666 contagens -- assumindo uma freqüência de examente 60Hz vindo da linha elétrica.
Medir a freqüência será bem fácil usando o recurso de
Input Capture (ICP) do Timer1.
Lembre-se, o pino ICP (na realidade, todos os pinos de entrada digitais) têm
Schmitt triggers. Assim, sempre
que a voltagem cair abaixo do limite inferior do Schmitt trigger, obteremos uma
transição do nível digital alto para baixo. Configurando o bit "Interrupt Capture Edge Select"
para detetar essa transição de nível e ligando a interrupção de Captura de Entrada,
nossa rotina de tratamento será executada a cada semiciclo. Ou melhor, um pouco antes --
segundo a seção "Características Elétricas" do
datasheet do ATmega8, o limite inferior
do Schmitt trigger é de 1,35V. Em todo caso, a cada interrupt acumulamos o valor atual
do registrador ICR (Input Capture Registrer) -- um recurso legal do sistema de captura
de eventos do AVR: o valor do contador Timer1 é copiado para o registrador ICR no mesmo
cliclo em que a transição de nível é detectada, permitindo medidas extremamente precisas
sem nos preocuparmos muito com a latência da interrupção (quantos ciclos a CPU gasta
pulando para nosso vetor de interrupção, salvando o contexto, e tudo mais que precisa
ser feito antes de realmente chegar ao nosso código). Ao acumularmos esses resultados
por 120 semiciclos, podemos computar a freqüência f = 60 * 125.000 / acumulador.
Uma vez que o
clock do Timer1 roda a uma velocidade superior a 10
5 Hz,
a precisão da medida poderia ter, em teoria, cinco casas decimais, ou três casas após
do pono decimal. Dado que a precisão da medida depende apenas da precisão e estabilidade
do cristal (tipicamente por volta de 100 partes por milhão), eu imagino que a medição
de freqüência do nosso dispositivo monitor de energia elétrica será melhor do que
duas casas após o ponto decimal. Conjecturo que na maioria do tempo ele dará exatamente
igual ao valor exibido na sala de controle da
ONS
(a agência que controla a rede elétrica nacional brasileira), do qual podemos ver
uma foto abaixo (o número "60,016" na tela gigante).
O que nós estamos realmente calculando aqui é a freqüência média a cada 120 semiciclos;
não estamos calculando a freqüência
a cada semiciclo porque não precisamos dela
tão freqüentemente -- precisamos dela apenas para exibir no LCD e cerca de uma vez
por segundo está bom demais.
Mas a vida não é tão simples: devemos tentar evitar aritmética de
vírgula flutuante,
pois é lenta e aumenta sobremaneira o tamanho do código. Por isso, reescreveemos nossa
fórmula como f = 60.000 * 125.000 / acumulador, com o "60.000" representando 60 com
três dígitos decimais à esquerda (ou seja, "60,000"). Mas 60.000 * 125.000 é 7.500.000.000, que
não cabe em 32 bits (por um fio -- cabe em 33). O GCC suporta artimética inteira de 64-bits até
mesmo no AVR, mas me parece exagero. Então vamos fazer assim: dividimos o acumulador por dois
(um rápido deslocamento para a esquerda) e calculamos f = 3.750.000.000 / acumulador. Perdemos
um pouco de precisão, mas torna a vida bem mais simples.
A má notícia é que não temos como escapar da necessidade de uma rotina de divisão de 32 bits --
a operação de divisão consome várias centenas de ciclos de CPU. A boa notícia é que o GCC gera
o código da divisão para nós automaticamente, então nem precisamos nos preocupar tanto assim.
Medir a voltagem é uma história completamente diferente. Há vários possíveis abordagens;
optei por implementar primeiro a que me pareceu mais simples e quem sabe depois implementar
uma mais sofisiticada. A estratégia simples é o que o Jerry Whitaker, no capítiulo 10 do
seu livro
"
AC Power Systems Handbook",
chamaria de "detector de voltagem de pico calibrado pela raiz-da-média-dos-quadrados".
Por causa da temporização precisa descrita anteriormente ao discutirmos a medição da
freqüência, sabemos com precisão bem alta quando o pico da senóide deveria acontecer:
a linha vertical no gráfico acima mostra que ela deve acontecer quando o contador do Timer1
estiver por volta de 637. Então, alguns ciclos antes nós engatilhamos o ADC de sorte que
o momento da amostragem aconteça precisamente no pico da onda, o que nos retornará o valor
da voltagem de pico. Acumulamos isso ao longo dos 120 ciclos e os reescalamos para nos dar
o resultado diretamente em Volts-RMS.
Na planilha em Excel, você pode ver como fiz o cálculo do fator de conversão, levando
em conta as voltagens do transformador, os valores dos resistores divisores de voltagem,
a voltagem de referência do ADC, a acumulação e o "fator de crista"
(o fator de conversão "voltagem de pico" para "volts RMS"), também abordando a necessidade
de usarmos apenas aritmética inteira. No final, fica bem simples: multiplicamos o acumulador
de 16 bits por 2798 e descartamos os 16 bits menos significativos. Os 16 bits de cima conterão
a voltagem RMS vezes 10, para termos um dígito decimal.
Pela matemática, esse dígito decimal parece ser justificável: 220V divididos pela
resolução de 1024 passos do ADC é ~0,2V, mas o ADC do AVR é um tanto ruidoso nos
últimos dois bits. Por outro lado, estaremos tirando a média de 120 medidas, de
forma que isso deveria melhorar nossa resolução aparente por algo da ordem da
raiz quadrada de 120, ou cerca de 11 vezes. A despeito disso tudo, muitos fatores
contribuem para que essa precisão não seja lá tão boa assim -- os resistores só
têm precisão de 1% e sabe-se lá que precisão o transformador genérico baratinho
(custou R$ 7,00) dá. Por causa disso tudo, vou me dar por muito satisfeito se
chegarmos a +/- 5V do valor correto. Será mais que suficiente para o propósito
primário deste dispositivo, que é registrar as quedas de energia.
A maneira sofisticada seria calcular a voltagem RMS verdadeira diretamente: teríamos
de medir vários pontos a cada semiciclo, elevá-los ao quatrado (multiplicação de 10
bits por 10 bits, resultado de 20 bits), acumulá-los ao longo de 120 ciclos (27
bits) e calcular a raiz quadrada no final. É um bocado de contas pra fazer que,
ainda que pareça perfeitamente viável, certamente vai complicar a temporização.
Por outro lado, seria muito legal: não só promete mais exatidão, mas dará resultados
corretos mesmo para formas de onda não-senoidais.
Mas, por enquanto, vamos manter as coisas simples. O mero ato de integrar todos
os subsistemas e fazê-los funcionar em conjunto é diversão bastante. "Fazer
funcionar primeiro, melhorar depois", já diziam os sábios.
Estou convencido de que tenho um plano razoavelmente decente. O próximo passo
seria desenhar o esquema final, mas estou ansioso por testar tudo isso; por isso,
vou partir direto para montar o protótipo e documento tudo retroativamente depois.
Fique ligado!
Próximos posts sobre esse assunto:
topo
