Termômetro de registro faça você mesmo com 2 sensores: 3 etapas (com fotos)

2024 Autor: John Day | [email protected]. Última modificação: 2024-01-30 11:36

Este projeto é um aprimoramento do meu projeto anterior "DIY Logging Thermometer". Ele registra as medições de temperatura em um cartão micro SD.

Mudanças de hardware

Acrescentei um sensor de temperatura DS18B20 ao módulo de relógio de tempo real, onde há previsão na placa de circuito impresso para este dispositivo; e adicionou o fio apropriado do pino "DS" do RTC ao D2 do Arduino.

Mudanças de software

Então eu adicionei e modifiquei o software. As principais mudanças são:

O display LCD mostra duas temperaturas "In" e "Out".

Os arquivos de registro gravados no cartão SD têm dois campos de temperatura, "temperatura de entrada" e "temperatura de saída".

Por causa do registro mais longo no cartão SD, os buffers de trabalho para a EEPROM eram maiores e como resultado disso comecei a ter problemas de conflito de memória. Fiz uma série de alterações com o objetivo de reduzir o uso de memória dinâmica, incluindo o uso de matrizes de caracteres para todas as strings em vez do objeto String.

A parte do software que obtém as temperaturas tem grandes modificações, muitas das quais têm a ver com a identificação de qual sonda está "dentro" e qual está "fora". Essa identificação é quase sempre automática. Se por algum motivo as pontas de prova forem trocadas, isso pode ser corrigido desconectando a ponta de prova de "saída" e conectando-a novamente. Eu mesmo não experimentei essa reversão. O programador ou usuário não precisa digitar os endereços dos sensores, o software descobre os endereços dos sensores de temperatura por si mesmo.

De acordo com os testes que fiz, a identificação das sondas de temperatura e a resposta à remoção e substituição do cartão SD ainda funcionam perfeitamente.

Etapa 1: Desenvolvimento de software

Esta etapa fornece o software completo para o projeto concluído. Eu o compilei usando o Arduino IDE 1.6.12. Ele usa 21.400 bytes de memória de programa (69%) e 1.278 bytes de memória dinâmica (62%).

Coloquei comentários no código na esperança de deixar claro o que está acontecendo.

Etapa 2: trabalhar com dois sensores de temperatura - detalhes

Este software usa a biblioteca "OneWire". Ele não usa nenhuma "DallasTemperature" ou bibliotecas semelhantes. Em vez disso, os comandos para e os dados dos sensores de temperatura são feitos pelo esboço e podem ser vistos e compreendidos com bastante facilidade. Encontrei uma lista útil dos comandos da biblioteca OneWire em

www.pjrc.com/teensy/td_libs_OneWire.html

Quando existem dois (ou mais) sensores de temperatura, torna-se necessário identificar qual é qual.

Chamei meus dois sensores de "dentro" e "fora", o que é típico de unidades comerciais que têm um sensor no módulo de exibição que normalmente está "dentro", e o outro sensor em um cabo para que possa ser colocado do outro lado de uma parede externa e, portanto, estar "fora".

A abordagem usual para identificar as diferentes sondas é descobrir os endereços dos dispositivos e colocá-los no software junto com um rótulo de identificação. Todos os outros projetos que vi usam essa abordagem, independentemente de usarem ou não a biblioteca DallasTemperature.

Minha intenção era que o software identificasse automaticamente os sensores e os alocasse corretamente para "dentro" e "fora". Isso é fácil de fazer, colocando-os em pinos Arduino separados. Neste projeto, A0 a A3 e A6 e A7 não são usados, então um deles poderia ter sido usado neste caso. No entanto, consegui que a identificação automática funcionasse com os dois sensores no mesmo barramento OneWire.

Funciona assim.

A biblioteca OneWire tem um comando "OneWireObject.search (address)" onde "address" é um array de 8 bytes e "OneWireObject" é o nome de uma instância do objeto OneWire que foi criado anteriormente. Ele pode ter o nome que você quiser. O meu é chamado de "ds". Quando você emite este comando de "pesquisa", a biblioteca OneWire faz alguma sinalização no barramento de um fio. Se encontrar um sensor respondendo, ele retorna um valor booleano "VERDADEIRO" e preenche a matriz "endereço" com o identificador exclusivo de 8 bytes do sensor. Este identificador inclui um código de família (no início) e uma soma de verificação (no final). No meio estão 6 bytes que identificam exclusivamente o sensor dentro de sua família.

Um resultado (endereço e retorno TRUE) é obtido cada vez que este comando é dado, percorrendo todos os dispositivos no barramento OneWire. Assim que todos os dispositivos tiverem respondido, na próxima vez que "pesquisar" for emitido, o retorno será "FALSE", indicando que todos os dispositivos no barramento já responderam. Se a "pesquisa" for emitida novamente, o primeiro dispositivo responderá novamente - e assim por diante indefinidamente. Os dispositivos sempre respondem na mesma ordem. A ordem das respostas é baseada nos identificadores dos dispositivos no barramento OneWire. Parece ser uma pesquisa binária a partir dos bits menos significativos dos identificadores de dispositivo. O protocolo usado para encontrar esses identificadores é bastante complexo e é descrito nas páginas 51 - 54 do documento "Book of iButton Standards", que é um documento pdf em https://pdfserv.maximintegrated.com/en/an/AN937.pd …

Testei esse processo de pesquisa com de 1 a 11 sensores em um único barramento e descobri que a ordem de resposta para um determinado conjunto de dispositivos era sempre a mesma, mas quando adicionei um novo dispositivo ao final do barramento, não havia como Eu poderia prever onde ele apareceria na ordem de pesquisa. Por exemplo, o 11º sensor que adicionei veio na posição No.5; e o primeiro sensor que coloquei no ônibus foi sempre o último na ordem de busca.

Neste projeto com dois sensores, um deles é soldado no lugar no módulo RTC; o outro é conectado usando um conector macho na placa e um conector fêmea no cabo. Ele pode ser facilmente removido.

Quando o sensor no cabo (o sensor "out") é desconectado, o comando "search" produz retornos alternados de "TRUE" e "FALSE".

Quando o sensor no cabo é conectado, o comando "search" produz um ciclo de 3 estágios, com dois retornos "TRUE" e um "FALSE".

Meu procedimento é emitir 1, 2 ou 3 comandos de "pesquisa", até que um resultado FALSO seja retornado. Em seguida, emito mais 2 comandos de "pesquisa". Se o segundo falhar (ou seja, FALSO), sei que há apenas um sensor no barramento e que é o sensor "de entrada". A identidade do dispositivo é registrada e alocada ao sensor "de entrada".

Posteriormente, se o primeiro e o segundo retornos forem TRUE, eu sei que há dois sensores no barramento. Eu verifico qual deles tem uma identidade igual ao sensor de "entrada" e aloco o outro como o sensor de "saída".

O outro ponto menor é que a coleta dos resultados dos dois sensores é feita através do envio do "iniciar conversão" pelo que é conhecido como comando "pular ROM". Temos a opção de enviar comandos para um único dispositivo (usando seu identificador único) ou para todos os dispositivos do barramento (pular ROM). O código é parecido com este:

ds.reset (); //

// envia o comando "pular ROM" (para que o próximo comando funcione em ambos os sensores) ds.write (0xCC); // Pula o comando ROM ds.write (0x44, 0); // inicia a conversão em ambas as sondas temperature_state = wait_convert; // vai para o estado de atraso

Quando o tempo de atraso necessário tiver passado, as temperaturas são recebidas de cada sensor individualmente. Aqui está o código para o segundo sensor (ou seja, o sensor OUT).

if (flag2) {

presente = ds.reset (); ds.select (DS18B20_addr_out); ds.write (0xBE); // Lê o Scratchpad dos dados da sonda "out" [0] = ds.read (); dados [1] = ds.read (); temperatura_out = (dados [1] << 8) + dados [0]; temperatura_out = (6 * temperatura_out) + temperatura_out / 4; // multiplique por 6,25} else {// não sinalizador2 - isto é, sensor de saída não conectado temperature_out = 30000; // fixa em 300,00 C se o sensor de temperatura não está funcionando} // fim de if (sinalizador2)

Eu trabalhei a maior parte deste software em um esboço autônomo que tinha apenas os sensores de temperatura nele, sem as complicações de suporte a LCD, RTC e cartão SD. Este esboço de desenvolvimento está no arquivo abaixo.

Etapa 3: resultados preliminares

Este gráfico é uma combinação das primeiras duas leituras do dia parcial.