Thermomètre de journalisation bricolage avec 2 capteurs : 3 étapes (avec photos)

2024 Auteur: John Day | [email protected]. Dernière modifié: 2024-01-30 09:06

Ce projet est une amélioration de mon projet précédent "DIY Logging Thermometer". Il enregistre les mesures de température sur une carte micro SD.

Modifications matérielles

J'ai ajouté un capteur de température DS18B20 au module d'horloge en temps réel, où il y a une disposition sur la carte de circuit imprimé pour cet appareil; et a ajouté le fil approprié de la broche "DS" de RTC à D2 de l'Arduino.

Modifications logicielles

Ensuite, j'ai ajouté et modifié le logiciel. Les principaux changements sont:

L'écran LCD affiche deux températures "In" et "Out".

Les fichiers journaux enregistrés sur la carte SD ont deux champs de température, "temperature In" et "temperature Out".

En raison de l'enregistrement plus long sur la carte SD, les tampons de travail de l'EEPROM étaient plus grands et, par conséquent, j'ai commencé à avoir des problèmes de conflit de mémoire. J'ai apporté un certain nombre de modifications visant à réduire l'utilisation de la mémoire dynamique, notamment en utilisant des tableaux de caractères pour toutes les chaînes au lieu de l'objet String.

La partie du logiciel qui obtient les températures a des modifications majeures, dont une grande partie est liée à l'identification de la sonde « in » et de celle qui est « out ». Cette identification est en grande partie automatique. Si, pour une raison quelconque, les sondes sont inversées, cela peut être corrigé en débranchant la sonde "out" puis en la rebranchant. Je n'ai pas connu ce renversement moi-même. Le programmeur ou l'utilisateur n'a pas besoin de saisir les adresses des capteurs, le logiciel découvre les adresses des capteurs de température par lui-même.

D'après les tests que j'ai effectués, l'identification des sondes de température et la réponse au retrait et au remplacement de la carte SD fonctionnent toujours de manière transparente.

Étape 1: Développement de logiciels

Cette étape vous donne le logiciel complet pour le projet terminé. Je l'ai compilé avec Arduino IDE 1.6.12. Il utilise 21 400 octets de mémoire programme (69 %) et 1 278 octets de mémoire dynamique (62 %).

J'ai mis des commentaires dans le code dans l'espoir que cela clarifie ce qui se passe.

Étape 2: Travailler avec deux capteurs de température - Détails

Ce logiciel utilise la bibliothèque "OneWire". Il n'utilise aucune bibliothèque "DallasTemperature" ou similaire. Au lieu de cela, les commandes et les données des capteurs de température sont effectuées par le croquis et peuvent être vues et comprises assez facilement. J'ai trouvé une liste utile des commandes de la bibliothèque OneWire sur

www.pjrc.com/teensy/td_libs_OneWire.html

Lorsqu'il y a deux (ou plus) capteurs de température, il devient nécessaire d'identifier lequel est lequel.

J'ai appelé mes deux capteurs "in" et "out", ce qui est typique des unités commerciales qui ont un capteur dans le module d'affichage qui est normalement "à l'intérieur", et l'autre capteur sur un câble afin qu'il puisse être mis de l'autre côté d'un mur extérieur et donc être "à l'extérieur".

L'approche habituelle pour identifier les différentes sondes est de découvrir les adresses des appareils et de les mettre dans le logiciel avec une étiquette d'identification. Tous les autres projets que j'ai vus utilisent cette approche, qu'ils utilisent ou non la bibliothèque DallasTemperature.

Mon intention était que le logiciel identifie automatiquement les capteurs et les attribue correctement à "in" et "out". C'est assez facile à faire en les mettant sur des broches Arduino séparées. Dans ce projet, A0 à A3 et A6 et A7 sont tous inutilisés, donc l'un d'eux aurait pu être utilisé dans ce cas. Cependant j'ai réussi à faire fonctionner l'identification automatique avec les deux capteurs sur le même bus OneWire.

Cela fonctionne comme ça.

La bibliothèque OneWire a une commande "OneWireObject.search(address)" où "address" est un tableau de 8 octets et "OneWireObject" est le nom d'une instance de l'objet OneWire qui a été précédemment créé. Il peut avoir n'importe quel nom que vous aimez. Le mien s'appelle "ds". Lorsque vous exécutez cette commande de « recherche », la bibliothèque OneWire effectue une signalisation sur le bus à un fil. S'il trouve un capteur qui répond, il renvoie une valeur booléenne "TRUE" et remplit le tableau "address" avec l'identifiant unique de 8 octets du capteur. Cet identifiant comprend un code famille (au début) et une somme de contrôle (à la fin). Entre les deux se trouvent 6 octets qui identifient de manière unique le capteur au sein de sa famille.

Un résultat (adresse et retour VRAI) est obtenu à chaque fois que cette commande est donnée, en parcourant tous les appareils sur le bus OneWire. Une fois que chaque appareil a répondu, la prochaine fois que "search" est émis, le retour est "FALSE", indiquant que chaque appareil sur le bus a déjà répondu. Si la "recherche" est à nouveau émise, le premier appareil répond à nouveau - et ainsi de suite indéfiniment. Les appareils répondent toujours dans le même ordre. L'ordre des réponses est basé sur les identifiants des appareils sur le bus OneWire. Il s'agit d'une recherche binaire à partir des bits les moins significatifs des identifiants de l'appareil. Le protocole utilisé pour trouver ces identifiants est assez complexe, et est décrit aux pages 51 - 54 du document "Book of iButton Standards" qui est un document pdf à https://pdfserv.maximintegrated.com/en/an/AN937.pd …

J'ai testé ce processus de recherche avec de 1 à 11 capteurs sur un seul bus et j'ai trouvé que l'ordre de réponse pour un ensemble donné d'appareils était toujours le même, mais lorsque j'ai ajouté un nouvel appareil à la fin du bus, il n'y avait aucun moyen Je pouvais prédire où dans l'ordre de recherche il apparaîtrait. Par exemple, le 11ème capteur que j'ai ajouté est arrivé à la position n°5; et le premier capteur que j'ai mis dans le bus était de loin le dernier dans l'ordre de recherche.

Dans ce projet avec deux capteurs, l'un d'eux est soudé en place sur le module RTC; l'autre est branché à l'aide d'une embase mâle sur la carte et d'une embase femelle sur le câble. Il peut être facilement détaché.

Lorsque le capteur sur le câble (le capteur "out") est détaché, la commande "search" produit des retours "VRAI" et "FAUX" en alternance.

Lorsque le capteur sur le câble est connecté, la commande "recherche" produit un cycle en 3 étapes, avec deux retours "VRAI" et un "FAUX".

Ma procédure consiste à émettre 1, 2 ou 3 commandes de "recherche", jusqu'à ce qu'un résultat FAUX soit renvoyé. Ensuite, je lance 2 autres commandes de "recherche". Si le second échoue (c'est-à-dire FAUX), je sais qu'il n'y a qu'un seul capteur sur le bus et que c'est le capteur "in". L'identité de l'appareil est enregistrée et attribuée au capteur "in".

Plus tard, si les premier et deuxième retours sont VRAI, je sais qu'il y a deux capteurs sur le bus. Je vérifie lequel d'entre eux a une identité égale au capteur "in", et attribue l'autre comme capteur "out".

L'autre point mineur est que la collecte des résultats des deux capteurs se fait en envoyant le "start conversion" par ce qu'on appelle une commande "skip ROM". Nous avons la possibilité d'envoyer des commandes à un seul appareil (en utilisant son identifiant unique) ou à tous les appareils sur le bus (skip ROM). Le code ressemble à ceci:

ds.reset(); //

// envoie la commande "skip ROM" (pour que la commande suivante fonctionne dans les deux capteurs) ds.write(0xCC); // Ignore la commande ROM ds.write (0x44, 0); // lance la conversion dans les deux sondes temperature_state = wait_convert; // passe à l'état de retard

Lorsque le temps de retard requis est écoulé, les températures sont reçues de chaque capteur individuellement. Voici le code du deuxième capteur (c'est-à-dire le capteur OUT).

si (drapeau2) {

present = ds.reset(); ds.select(DS18B20_addr_out); ds.write(0xBE); // Lecture du bloc-notes de la sonde "out" data[0] = ds.read(); données[1] = ds.read(); température_out = (données[1] << 8) + données[0]; temperature_out = (6 * temperature_out) + temperature_out / 4; // multiplier par 6,25 } else { // pas flag2 - c'est-à-dire le capteur de sortie non connecté temperature_out = 30000; // fix à 300,00 C si le capteur de température ne fonctionne pas } // fin de if (flag2)

J'ai élaboré la plupart de ce logiciel dans un croquis autonome qui contenait juste les capteurs de température, sans les complications de la prise en charge des écrans LCD, RTC et des cartes SD. Cette esquisse de développement est dans le fichier ci-dessous.

Étape 3: Résultats préliminaires

Ce graphique est une combinaison des deux premiers jours partiels de lectures.