Skip to topic | Skip to bottom
www.postcogito.org
          ...sine propero notiones
Kiko
Você está aqui: Kiko > PostsEmPortugues > PtBrBlogEntry2008Feb02A Imprimível | fim do tópico


Start of topic | Skip to actions
English Version

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:

Gráfico com a forma de onda

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 105 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).

Figura do Sistema de Monitoração da Rede Elétrica Brasileira no ONS

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


Você está aqui: Kiko > PostsEmPortugues > PtBrBlogEntry2008Feb02A

topo

Creative Commons License   O conteúdo deste site está disponibilizado nos termos de uma Licença Creative Commons, exceto onde dito em contrário.
  The content of this site is made available under the terms of a Creative Commons License, except where otherwise noted.