Termómetro de registro de bricolaje con 2 sensores: 3 pasos (con imágenes)

2024 Autor: John Day | [email protected]. Última modificación: 2024-01-30 08:41

Este proyecto es una mejora de mi proyecto anterior "Termómetro de registro de bricolaje". Registra las medidas de temperatura en una tarjeta micro SD.

Cambios de hardware

Agregué un sensor de temperatura DS18B20 al módulo de reloj en tiempo real, donde hay una disposición en la placa de circuito impreso para este dispositivo; y agregó el cable apropiado desde el pin "DS" del RTC al D2 del Arduino.

Cambios de software

Luego agregué y modifiqué el software. Los principales cambios son:

La pantalla LCD muestra dos temperaturas "In" y "Out".

Los archivos de registro registrados en la tarjeta SD tienen dos campos de temperatura, "temperatura de entrada" y "temperatura de salida".

Debido al registro más largo en la tarjeta SD, los búferes de trabajo para la EEPROM eran más grandes y como resultado de esto comencé a tener problemas de conflictos de memoria. Hice una serie de cambios destinados a reducir el uso de memoria dinámica, incluido el uso de matrices de caracteres para todas las cadenas en lugar del objeto String.

La parte del software que obtiene las temperaturas tiene modificaciones importantes, muchas de las cuales tienen que ver con identificar qué sonda está "dentro" y cuál está "fuera". Esta identificación es principalmente automática. Si por alguna razón las sondas se cambian, se puede corregir desenchufando la sonda "out" y luego volviéndola a enchufar. Yo mismo no he experimentado este cambio. El programador o usuario no necesita ingresar las direcciones del sensor, el software descubre las direcciones del sensor de temperatura por sí mismo.

Según las pruebas que he realizado, la identificación de las sondas de temperatura y la respuesta a la extracción y sustitución de la tarjeta SD siguen funcionando sin problemas.

Paso 1: desarrollo de software

Este paso le brinda el software completo para el proyecto terminado. Lo compilé usando Arduino IDE 1.6.12. Utiliza 21, 400 bytes de memoria de programa (69%) y 1, 278 bytes de memoria dinámica (62%).

He incluido comentarios en el código con la esperanza de que se aclare lo que está sucediendo.

Paso 2: Trabajar con dos sensores de temperatura - Detalles

Este software utiliza la biblioteca "OneWire". No utiliza ninguna "DallasTemperature" o bibliotecas similares. En cambio, los comandos y los datos de los sensores de temperatura se realizan mediante el boceto y se pueden ver y comprender con bastante facilidad. Encontré una lista útil de los comandos de la biblioteca OneWire en

www.pjrc.com/teensy/td_libs_OneWire.html

Cuando hay dos (o más) sensores de temperatura, es necesario identificar cuál es cuál.

Llamé a mis dos sensores "adentro" y "afuera", lo cual es típico de las unidades comerciales que tienen un sensor en el módulo de pantalla que normalmente está "adentro", y el otro sensor en un cable para que pueda colocarse en el otro lado. de una pared exterior y así estar "fuera".

El enfoque habitual para identificar las diferentes sondas es descubrir las direcciones del dispositivo y colocarlas en el software junto con una etiqueta de identificación. Todos los demás proyectos que he visto utilizan este enfoque, utilicen o no la biblioteca DallasTemperature o no.

Mi intención era que el software identificara automáticamente los sensores y los asignara correctamente a "entrada" y "salida". Esto es bastante fácil de hacer colocándolos en pines Arduino separados. En este proyecto, A0 a A3 y A6 y A7 están todos sin usar, por lo que uno de estos podría haberse usado en este caso. Sin embargo, logré que la identificación automática funcionara con los sensores en el mismo bus OneWire.

Funciona así.

La biblioteca OneWire tiene un comando "OneWireObject.search (dirección)" donde "dirección" es una matriz de 8 bytes y "OneWireObject" es el nombre de una instancia del objeto OneWire que se ha creado previamente. Puede tener el nombre que desee. El mío se llama "ds". Cuando emite este comando de "búsqueda", la biblioteca OneWire realiza algunas señales en el bus de un cable. Si encuentra un sensor que responde, devuelve un valor booleano "VERDADERO" y llena la matriz de "dirección" con el identificador único de 8 bytes del sensor. Este identificador incluye un código de familia (al principio) y una suma de control (al final). En el medio hay 6 bytes que identifican de forma única al sensor dentro de su familia.

Se obtiene un resultado (dirección y retorno VERDADERO) cada vez que se da este comando, pasando por todos los dispositivos en el bus OneWire. Una vez que todos los dispositivos han respondido, la próxima vez que se emite la "búsqueda", el resultado es "FALSO", lo que indica que todos los dispositivos del bus ya han respondido. Si se vuelve a emitir la "búsqueda", el primer dispositivo responde de nuevo, y así indefinidamente. Los dispositivos siempre responden en el mismo orden. El orden de las respuestas se basa en los identificadores de los dispositivos en el bus OneWire. Parece ser una búsqueda binaria a partir de los bits menos significativos de los identificadores de dispositivo. El protocolo utilizado para encontrar estos identificadores es bastante complejo y se describe en las páginas 51 a 54 del documento "Book of iButton Standards", que es un documento pdf en https://pdfserv.maximintegrated.com/en/an/AN937.pd …

Probé este proceso de búsqueda con de 1 a 11 sensores en un solo bus y encontré que el orden de respuesta para un conjunto dado de dispositivos era siempre el mismo, pero cuando agregué un nuevo dispositivo al final del bus, no había forma de Podría predecir en qué lugar del orden de búsqueda aparecería. Por ejemplo, el undécimo sensor que agregué se ubicó en la posición número cinco; y el primer sensor que puse en el autobús siempre fue el último en el orden de búsqueda.

En este proyecto con dos sensores, uno de ellos está soldado en su lugar en el módulo RTC; el otro se conecta mediante un conector macho en la placa y un conector hembra en el cable. Se puede desmontar fácilmente.

Cuando se desconecta el sensor del cable (el sensor de "salida"), el comando de "búsqueda" produce retornos alternativos de "VERDADERO" y "FALSO".

Cuando el sensor en el cable está conectado, el comando "buscar" produce un ciclo de 3 etapas, con dos retornos "VERDADERO" y uno "FALSO".

Mi procedimiento es emitir 1, 2 o 3 comandos de "búsqueda", hasta que se devuelva un resultado FALSO. Luego publico 2 comandos más de "búsqueda". Si el segundo falla (es decir, FALSO), sé que solo hay un sensor en el bus y que es el sensor "de entrada". La identidad del dispositivo se registra y se asigna al sensor "de entrada".

Más adelante, si tanto el primer como el segundo retorno son VERDADEROS, sé que hay dos sensores en el bus. Verifico cuál de ellos tiene una identidad igual al sensor "de entrada" y asigno el otro como sensor de "salida".

El otro punto menor es que la recopilación de los resultados de los dos sensores se realiza enviando la "conversión de inicio" mediante lo que se conoce como un comando "omitir ROM". Tenemos la opción de enviar comandos a un solo dispositivo (usando su identificador único) oa todos los dispositivos en el bus (omitir ROM). El código se ve así:

ds.reset (); //

// envía el comando "omitir ROM" (por lo que el siguiente comando funciona en ambos sensores) ds.write (0xCC); // Omitir el comando de ROM ds.write (0x44, 0); // iniciar la conversión en ambas sondas temperature_state = wait_convert; // ir al estado de retraso

Cuando ha pasado el tiempo de retardo requerido, las temperaturas se reciben de cada sensor individualmente. Aquí está el código para el segundo sensor (es decir, el sensor de SALIDA).

si (bandera2) {

presente = ds.reset (); ds.select (DS18B20_addr_out); ds.write (0xBE); // Leer el Bloc de notas de los datos de la sonda "fuera" [0] = ds.read (); datos [1] = ds.read (); temperatura_salida = (datos [1] << 8) + datos [0]; temperatura_salida = (6 * temperatura_salida) + temperatura_salida / 4; // multiplicar por 6.25} else {// no flag2 - es decir, el sensor de salida no está conectado temperature_out = 30000; // arreglar a 300.00 C si el sensor de temperatura no funciona} // fin de if (flag2)

Trabajé la mayor parte de este software en un boceto independiente que solo tenía los sensores de temperatura, sin las complicaciones de la compatibilidad con LCD, RTC y tarjetas SD. Este boceto de desarrollo se encuentra en el archivo a continuación.

Paso 3: Resultados preliminares

Esta tabla es una combinación de los dos primeros días parciales de lecturas.