- Medir a velocidade, obviamente;
- Medir distância em dois registros: um volátil e resetável (distância percorrida) e outro inresetável com cópia na E²PROM (odômetro);
- Medir tempo trascorrido e hora;
- Medir carga da bateria com um gaussímetro;
- Consumir muito pouca energia quando ocioso;
- Display visível à noite;
- Apenas dois botões de interface para facilitar a montagem mecânica e operação;
Como tenho mais experiência com microcontroladores da Microchip, decidi usar o PIC18F14K22, pois tem bastante memória para guardar os bitmaps dos caracteres (16x16 e 32x32 mais alguns ícones), comunicação via barramento SPI, oscilador de baixo consumo de 32768Hz para base de tempo e módulo CCP (capture and compare).
Para o display, usei um OLED branco baseado no controlador Solomon Systech SSD1306 com interface SPI. Entre OLED e LCD com backlight, preferi o primeiro, pois é barato, fácil de encontrar no PicaretaLivre MercadoLivre, e mais importante: está bem documentado e cheio de exemplos já que é muito usado no Arduíno. Tentei displays LCD de celulares antigos, como o externo do NOKIA2660, mas tem muito pouca informação, usa conectores muito pequenos e estão difíceis de encontrar. A muito custo consegui fazer um funcionar perfeitamente. E tem a questão do acionamento do backlight: são dois LEDs azuis devendo usar um conversor step-up para ligá-los. Por isto, só estou usando estes displays OLED. Usando um brilho minimamente aceitável, o consumo de corrente fica entre 10~20mA, parecido com o consumo do LCD com backlight ligado.
 |
| Placa do computador vista de cima mostrando o PIC18F14K22 e o conector para o display OLED ao lado. |
 |
| Computador em ação, mostrando a velocidade e função odômetro. O B com seta em cima e circulo ao lado é para indicar o sinal do sensor que vai na roda. A cada volta, este muda de estado. |
 |
| Cheguei a considerar a usar um LCD com lâmpada eletroluminescente, como este que fiz para um relógio e cuja postagem será feita algum dia. Este LCD é do motorola C115, com interface I²C. |
O sensor da roda está sendo um grande problema. Sensores óticos, qualquer sujeira já deixa de funcionar (sem falar do consumo). De aproximação usando indução ou capacitância, consumo altíssimo. E o sensor tem que estar sempre ligado. Resta os magnéticos, que usam o efeito Hall. Comecei a pesquisa com o confiável e robusto sensor UGN3132 da Allegro, mas este não opera nem nos 4V da bateria de Li-ION e tem uma corrente típica de operação de 4,3mA. Em seguida, o A3245, que opera em com 1,5mA, menor mas inaceitável apesar de operar com o mínimo de 3,6V. Decidi fazer como é feito nos computadores comuns de bicicleta: usar um reed switch. O problema agora é como este sinal chega no microcontrolador. Para calcular a velocidade, meço o intervalo de tempo entre cada pulso (um pulso por volta da roda) através do módulo MCCP do PIC. Ele usa o oscilador de 32768Hz e conta quantos ciclos deste que estão entre os pulsos de cada volta. Tendo o perímetro do pneu, chega-se na velocidade (em km/h):
Velocidade = (32768 x 36 / PR) / (COUNT x 1000)
Onde PR = perímetro do pneu em centímetros e COUNT = contagem do MCCP do PIC. Esta fórmula é bem próxima da real, foi simplificado os valores para ficar fácil implementar na programação do microcontrolador já que estou fazendo tudo em assembler, pois ainda patino no C.
O problema é que o reed switch é um interruptor mecânico, e quando fecha e abre os contatos gera vários pulsos que são introduzidos na entrada do MCCP bagunçando a leitura. Assim deve ser feito um circuito de debouncer para filtrar este sinal. Mais um circuito para consumir energia. Usei um CMOS astável-monoestável 4047 para esta tarefa.
 |
| Circuito de debouncer do reed switch baseado no 4047. |
Funciona consumindo pouca energia. Mas tem um problema: quando a roda fica parada e o imã está ao lado do sensor, é gerado vários pulsos fazendo a velocidade variar. De vez em quando este circuito insere vários pulsos fazendo o odômetro disparar.
Nenhum comentário:
Postar um comentário