Quem já ligou uma coisa DESTAS, sabe que por vezes o windows confunde com o Serial Ball Point Mouse.
Tenho andado a tentar ligar o Datalogger ao MATLAB, mas cada vez que começo a receber dados, o windows reconhece o conversor como um rato. Tal e qual a imagem em cima.
Já tentei várias formas, incluindo o "SerialBallPointMouseDisabler", mas ele nunca funciona por muito tempo e passado um pouco (ou desligar e voltar a ligar o conversor), o windows volta a activar o "rato".
Se alguém souber como desactivar de uma vez o Serial Ball Point Mouse, comente aqui.
Agora para conseguir, tenho de ligar o conversor ao datalogger, ir aos dispositivos, desinstalar o rato, tirar o conversor do circuito, correr o "SerialBallPointMouseDisabler", voltar a ligar o conversor ao circuito e funciona certo.
Em baixo, primeiras experiências a receber dados pelo MATLAB, usando uma porta serial.
Finalmente chegou este conversor.
É graças a ele que vou comunicar com o micro e extrair os dados da EEPROM.
Uma vez mais esta foi uma compra fantástica no ebay, pelo preço de 2.32USD.
Devido à passagem de ano, não ia poder recolher o meu datalogger do dia 31, então decidi recolher hoje.
Aproveito também para revelar algumas fotos do local.
As pilhas sofreram um desgaste menor que aquilo que eu estava há espera e, aposto eu, aguentam na perfeição 3/4 meses de funcionamento.
Desde 1 de Dezembro ás 13:30, até hoje, dia 30 de Dezembro ás 11:30, foram registadas 2777 temperaturas. O gráfico pode ser visto em baixo.
O local foi escolhido a dedo, pois trata-se de um vale "especial" e de notar que ainda não fez muito frio!
Para ver com o tamanho real, aceder AQUI e fazer o download.
Fotos do local onde se fez o registo, sem nenhum edifício em redor e a cerca de 2,5m do chão.
Dados disponibilizados para o fórum METEOPT.
Terminou o teste que referi no post anterior.
O resultado poder ser visto em baixo.
Neste momento preparo tudo para colocar o datalogger num ponto estratégico e iniciar a recolha de dados.
Posso dar por terminado este projecto... pelo menos por agora, pois serão feitas novas versões melhoradas.
Bem... após toda a correria em chegar a casa e soldar os componentes todos novamente eis que, tal como previsto, tudo está a funcionar bem.
Consumo a rondar os 650uA, que corresponde mais ou menos ao menos consumo que registei quando estava tudo na breadboard.
Para tentar apresar tudo e ver se consigo um registo completo do mês de Dezembro, esta noite o datalogger já ficou no exterior a fazer medições.
Amanhã vou interromper e fazer a leitura da EEPROM para me certificar de que não há falhas.
Não percam os próximos episódios...
Durante os testes que fiz hoje, cheguei à conclusão de que a PCB feita não está correcta.
O ARES, programa para desenhar PCB do PROTEUS, não fez a ligação da EEPROM e do sensor aos pinos do microcontrolador. Ao invés, ligou-os directamente a VCC o que faz disparar o consumo, pois estão constantemente a ser alimentados.
Deveria ter revisto todas as trilhas antes de mandar fazer a PCB... erro meu.
Assim, amanhã vou ter de fazer um novo desenho da PCB e recuperar o máximo de componentes possíveis.
Vou recorrer ao Altium designer para refazer todo o projecto.
:( :( :(
Tal como disse no tópico anterior, ao longo desta semana consegui reunir o material necessário para concluir o projecto.
Nas fotos já se pode ver o compartimento das pilhas ligado ao circuito, tudo montado numa caixa estanque, onde entra apenas os fios do sensor.
Felizmente o meu conversor 232 para USB já funciona e vou poder também fazer um post acerca disso.
Por agora, 24 post's depois, este é o aspecto actual do datalogger.
Eis que chegou o compartimento para as pilhas que comprei no ebay.
Esperava recebe-lo mais tarde, mas além desta surpresa, pude ainda ver que o próprio compartimento tem um interruptor. Assim, vou dessoldar o que tinha colocado na PCB e soldar as duas trilhas.
O suporte é para 3 pilhas AA em série, totalizando 4.5V nos seus terminais. Infelizmente, esqueci-me de tirar uma foto com a tampa frontal, mas noutros posts irei colocar! A tampa faz bom encaixe e tem aperto de parafuso.
Preço: 0.81€
Ainda não é desta que fica totalmente pronto, mas está a faltar só uma boa caixa para alojar o circuito. Depois é só esperar pelo incio do mês de Dezembro, escolher um bom local e acondicionar tudo para 1 mês de medições, período em que vai recolher cerca de 3000 medições de temperatura.
Esta semana chegou a PCB e por isso já pude libertar a breadboard dos componentes e solda-los.
Algumas fotos da montagem e do aspecto actual da placa.
Estes são os primeiros 5 dias de teste no exterior.
Foram também 5 dias importantes para ver a acumulação de erros temporais e tenho a dizer que desviou-se apenas 4 segundos da hora que tinha sido marcada no Domingo.
Domingo - 15h15min21s
Hoje - 19h45min25s
O RS cerâmico, composto apenas por 2 pratos, deixou-me muito satisfeito pois apesar de estar mal colocado, as temperaturas são bastante semelhantes relativamente a outras estações na zona.
Ás 19h de hoje (próximo a Idanha-a-Nova), a temperatura que registei é praticamente a mesma que o IM registava na sua estação em Castelo Branco.
O consumo médio é de 760uA (este MCU é bastante antigo e não é dos mais económicos) e com 3A, capacidade média das pilhas AA, permite estar em funcionamento durante 164 dias (aprox), ou seja, cerca de 5 meses...
A EEPROM, tem capacidade para guardar cerca de 5300 valores, tal como disse noutros artigos, com intervalos de 15min, resulta em 55 dias de gravação de dados.
Após algumas peripécias, lá consegui fazer o RS.
É possível ver que o prato de baixo está partido, pois foi a unica forma de lhe poder fazer um furo para passar os cabos. Furar cerâmica é tarefa complicada.... muito complicada...
Ficam alguma fotos em baixo da construção e no fim um gráfico da evolução da temperatura ao longo de uma noite, já com o sensor no exterior (obviamente).
PS: Esta semana, o circuito já ficou em teste real em casa. No fim de semana, vou ver se tudo correu bem e se está pronto a ser soldado na PCB, que também já está pronta.
Um obrigado ao Diogo V. Correia, pela ajuda dada na produção da PCB.
Após todos os testes estarem realizados é hora de fazer a PCB para implementar o circuito.
O cristal externo é mais estável com variações de temperatura do que o interno que estava usando até agora. A freq escolhida foi de 2MHz, para que na leitura e envio dos dados, conseguisse um bom baud-rate.
Usando este cristal as contas são bastante simples...
Pretendo criar uma interrupção a cada segundo e fazer contagens de 900 segundos, ou seja, 900 interrupções.
O timer utilizado é o Timer 1, que é de 16bits, com um prescaller de 8.
Os cálculos estão feitos em baixo, mas o resumo é que o Timer incrementa a cada 16us, e que o overflow aconteceria a 1.0486s. Para facilitar, inicio o Timer em 3036, para que então a interrupção seja feita a cada segundo.
Após ter tido vários problemas com a temporização do micro, tal como prova a semana de teste que passou não é fácil obter um tempo certo.
Hoje coloquei de lado a utilização do sleep mode quando vi que alimentado a 4V, com clock de 125KHz e usando o Timer1 para "cronometrar" consumia apenas 400uA. Não é tão bom como os 256uA do sleep mode, mas é muito mais preciso assim.
Agora estou a utilizar mudança da freq de clock a meio do programa, para reduzir o consumo. Durante as medições e escrita na EEPROM, utilizo 2MHz, mas para "passar o tempo" baixo para 125KHz (INFO).
Usando um timer a contar ciclos de clock, faz com que consiga ter mais precisão temporal do que usando o INTRC de 31KHz do Watch Dog Timer.
Esta é a pequenina parte do código que não existia e foi acrescentada hoje para fazer com que tudo funcione certo.
SETUP_TIMER_1(T1_INTERNAL|T1_DIV_BY_4);
(...)
setup_oscillator(OSC_125KHZ);
#USE delay(clock=125KHz)
(...)
SET_TIMER1(0);
ENABLE_INTERRUPTS(INT_TIMER1);
while(!acorda);
DISABLE_INTERRUPTS(INT_TIMER1);
(...)
#INT_TIMER1
void tempo()
{
j++;
if(j==108)
{
acorda=1;
}
}
Até ao momento, passadas já 4h30min de teste, ainda não ganhou nem perdeu um segundo de "erro", o que a meu ver é óptimo!
Próximos passos:
Esta semana que se segue vou preparar todos os componentes para a construção do Radiation Shield.
Infelizmente a montagem "definitiva" do circuito está dependente de um conversor USB-Serial que ainda não chegou. Não gosto de avançar com a produção da PCB sem ter tudo a funcionar na breadboard.
Lá para a "parte 20" já devo estar muito perto de terminar.
Cheguei à pouco a casa e vim logo ver como estava o meu datalogger.
Olhando para o relógio até que o LED piscasse, reparei no atraso de 7min, era esperável que piscasse ás 16h, mas piscou ás 15:53.
Foram gravadas 571 temperaturas, o que dá um atraso de 735ms em cada wake-up. Não é coisa que se meça com facilidade cronometrando à mão, mas com muitos registos o erro vai acumulando e resulta nestas diferenças maiores facilmente cronometradas.
Resta-me estudar melhor o que está acontecer e provavelmente este erro estará a ser provocado por um desvio no oscilador interno do micro.
Poderia usar um cristal externo, mas tal como já disse noutros posts ia aumentar o consumo e isso não me agrada nada.
No último artigo sobre este projecto, expliquei algumas modificações que foram feitas para baixar o consumo de energia de modo a que as pilhas durem ainda mais, mas também como utilizei a temporização do WDT para obter 15min quase certos.
Esta noite ficou tudo a funcionar e como é obvio o erro vai acumulando, mas na medição das 13:02, havia apenas um erro de 20 segundos, ou seja, um LED no circuito haveria de ter piscado ás 13:02 certas e não ás 13:02:20... mas já foi corrigido e atrasei um pouquinho os tempos e agora está bem.
Série de dados da noite passada.
A próxima semana deixarei tudo a funcionar para que na sexta possa ter a 1ª semana de reolha de dados, ver se tudo correu bem, qual é o atraso, etc...
Hoje tive finalmente algum tempo para poder dar mais um retoques neste projecto.
Na parte 13 tinha surgido o problema do consumo, que não era mau, mas também não era o ideal.
Após a discussão no fórum electronicapt, surgiram várias alternativas, algumas das quais já tinha pensado mas que descartei à partida por estupidez (admito).
Repensando em tudo novamente, a solução que de facto se justifica é sem dúvida a de colocar o micro em sleep mode quando não está a fazer nada... quer dizer, ele fica a contar o tempo, mas é como se não estivesse a fazer nada.
Entrando no modo sleep, o micro baixa o consumo brutalmente e tudo pára, excepto um pequena percentagem que mantém as suas funções. É o caso do Watch Dog Timer.
Daí até chegar á conclusão de como me deveria aproveitar deste temporizador, foi mais um passo. Este micro em vários prescalers que se podem adaptar a praticamente todos os tempos!
Como o intervalo de tempo que eu pretendia era 15min, calculei todas as hipóteses numa folha excel e cheguei à conclusão:
WDT_1152MS x 128 dentro de um "for" a contar até 5;
WDT_288MS x 16 dentro de um "for" a contar até 32;
Estes valores, embora apoiados em alguns cálculos, foram o resultado de várias experiências de tentativa e erro (técnica bastante valiosa :p ).
Medição do consumo de corrente
Pode parecer complicado medir alguns uA, mas até nem custa muito!
Tudo é feito com a lei de Ohm. Colocando uma resistência de 1K em série com o circuito, vai provocar uma determinada queda de tensão. Ora uma queda de 1V, significa que a resistência de 1K está a ser percorrida por uma corrente de 1mA.
Como se pode ver no multímetro em baixo, 0.286V corresponde, claro está, a 286uA, corrente durante o sleep mode, pois quando está a ler o sensor chega aos 5mA (mas por breves instantes).
