DIY Logging Thermometer mit 2 Sensoren - Gunook

2024 Autor: John Day | [email protected]. Zuletzt bearbeitet: 2024-01-30 07:17

Dieses Projekt ist eine Erweiterung meines vorherigen Projekts "DIY Logging Thermometer". Es protokolliert die Temperaturmessungen auf einer Micro-SD-Karte.

Hardware-Änderungen

Ich habe dem Echtzeituhrmodul einen DS18B20-Temperatursensor hinzugefügt, wo auf der Leiterplatte für dieses Gerät vorgesehen ist; und fügte den entsprechenden Draht vom "DS" -Pin von RTC zu D2 des Arduino hinzu.

Softwareänderungen

Dann habe ich die Software ergänzt und modifiziert. Die wichtigsten Änderungen sind:

Das LCD-Display zeigt zwei Temperaturen "In" und "Out".

Die auf der SD-Karte aufgezeichneten Log-Dateien haben zwei Temperaturfelder, "Temperature In" und "Temperature Out".

Aufgrund der längeren Aufzeichnung auf der SD-Karte waren die Arbeitspuffer für das EEPROM größer und als Folge davon bekam ich Probleme mit Speicherkonflikten. Ich habe eine Reihe von Änderungen vorgenommen, die darauf abzielen, die Nutzung des dynamischen Speichers zu reduzieren, einschließlich der Verwendung von Zeichenarrays für alle Strings anstelle des String-Objekts.

Der Teil der Software, der die Temperaturen erhält, hat große Änderungen, von denen ein Großteil damit zu tun hat, zu erkennen, welche Sonde "in" und welche "out" ist. Diese Identifizierung erfolgt meist automatisch. Wenn die Sonden aus irgendeinem Grund vertauscht sind, kann dies korrigiert werden, indem die "out"-Sonde aus- und wieder eingesteckt wird. Diese Umkehrung habe ich selbst noch nicht erlebt. Der Programmierer oder Benutzer muss die Sensoradressen nicht eintippen, die Software erkennt die Temperatursensoradressen selbst.

Nach den von mir durchgeführten Tests funktioniert die Erkennung der Temperaturfühler und die Reaktion auf das Entfernen und Ersetzen der SD-Karte immer noch reibungslos.

Schritt 1: Softwareentwicklung

In diesem Schritt erhalten Sie die vollständige Software für das abgeschlossene Projekt. Ich habe es mit Arduino IDE 1.6.12 kompiliert. Es verwendet 21.400 Byte Programmspeicher (69 %) und 1.278 Byte dynamischen Speicher (62 %).

Ich habe Kommentare in den Code eingefügt, in der Hoffnung, dass dadurch klar wird, was vor sich geht.

Schritt 2: Arbeiten mit zwei Temperatursensoren - Details

Diese Software verwendet die "OneWire"-Bibliothek. Es verwendet keine "DallasTemperature" oder ähnliche Bibliotheken. Stattdessen werden die Befehle und Daten von den Temperatursensoren durch die Skizze ausgeführt und können ganz einfach gesehen und verstanden werden. Eine nützliche Liste der OneWire-Bibliotheksbefehle habe ich unter gefunden

www.pjrc.com/teensy/td_libs_OneWire.html

Wenn zwei (oder mehr) Temperatursensoren vorhanden sind, muss identifiziert werden, welcher welcher welcher ist.

Ich habe meine beiden Sensoren "in" und "out" genannt, was typisch für kommerzielle Geräte ist, die einen Sensor im Anzeigemodul haben, der normalerweise "innen" ist, und den anderen Sensor an einem Kabel, damit er auf die andere Seite gesteckt werden kann einer Außenwand und somit "draußen" sein.

Der übliche Ansatz zur Identifizierung der verschiedenen Sonden besteht darin, die Geräteadressen zu ermitteln und sie zusammen mit einem Identifizierungsetikett in die Software einzugeben. Alle anderen Projekte, die ich gesehen habe, verwenden diesen Ansatz, unabhängig davon, ob sie die DallasTemperature-Bibliothek verwenden oder nicht.

Meine Intention war, dass die Software die Sensoren automatisch erkennt und richtig "in" und "out" zuordnet. Dies ist einfach genug, indem Sie sie auf separate Arduino-Pins setzen. In diesem Projekt sind A0 bis A3 sowie A6 und A7 alle unbenutzt, sodass in diesem Fall einer davon hätte verwendet werden können. Es ist mir jedoch gelungen, die automatische Identifikation mit den Sensoren beide am selben OneWire-Bus arbeiten zu lassen.

Es funktioniert so.

Die OneWire-Bibliothek hat einen Befehl "OneWireObject.search(address)", wobei "Adresse" ein Array von 8 Bytes ist und "OneWireObject" der Name einer Instanz des zuvor erstellten OneWire-Objekts ist. Es kann einen beliebigen Namen haben. Meins heißt "ds". Wenn Sie diesen "Suchbefehl" ausführen, führt die OneWire-Bibliothek einige Signale auf dem One-Wire-Bus aus. Wenn es einen antwortenden Sensor findet, gibt es einen "TRUE"-Booleschen Wert zurück und füllt das "address"-Array mit der 8-Byte-eindeutigen Kennung des Sensors aus. Dieser Identifikator enthält einen Familiencode (am Anfang) und eine Prüfsumme (am Ende). Dazwischen liegen 6 Bytes, die den Sensor innerhalb seiner Familie eindeutig identifizieren.

Jedes Mal, wenn dieser Befehl gegeben wird, wird ein Ergebnis (Adresse und Rückgabe TRUE) erhalten, das alle Geräte am OneWire-Bus durchläuft. Nachdem jedes Gerät geantwortet hat, wird beim nächsten "Suchen" der Rückgabewert "FALSE" zurückgegeben, was anzeigt, dass jedes Gerät am Bus bereits geantwortet hat. Wird die "Suche" erneut ausgegeben, antwortet das erste Gerät erneut - und so weiter auf unbestimmte Zeit. Die Geräte reagieren immer in der gleichen Reihenfolge. Die Reihenfolge der Antworten richtet sich nach den Kennungen der Geräte am OneWire-Bus. Es scheint eine binäre Suche zu sein, die mit den niederwertigsten Bits der Gerätekennungen beginnt. Das zum Auffinden dieser Identifikatoren verwendete Protokoll ist ziemlich komplex und wird auf den Seiten 51 - 54 des Dokuments "Book of iButton Standards" beschrieben, das ein PDF-Dokument unter https://pdfserv.maximintegrated.com/en/an/AN937.pd ist …

Ich habe diesen Suchprozess mit 1 bis 11 Sensoren an einem einzigen Bus getestet und festgestellt, dass die Antwortreihenfolge für einen bestimmten Gerätesatz immer gleich war, aber als ich ein neues Gerät am Ende des Busses hinzufügte, gab es keine Möglichkeit Ich konnte vorhersagen, wo es in der Suchreihenfolge erscheinen würde. Zum Beispiel kam der 11. Sensor, den ich hinzugefügt habe, an Position Nr. 5; und der erste Sensor, den ich in den Bus gesteckt habe, war bei weitem der letzte in der Suchreihenfolge.

Bei diesem Projekt mit zwei Sensoren wird einer davon auf das RTC-Modul gelötet; der andere wird mit einem Stecker auf der Platine und einer Buchse auf dem Kabel eingesteckt. Es kann leicht abgenommen werden.

Wenn der Sensor am Kabel (der "out"-Sensor) abgenommen wird, liefert der Befehl "search" abwechselnd "TRUE" und "FALSE" zurück.

Wenn der Sensor am Kabel angeschlossen ist, erzeugt der Befehl "Suchen" einen 3-Stufen-Zyklus mit zwei "TRUE"- und einem "FALSE"-Rücklauf.

Mein Verfahren besteht darin, 1, 2 oder 3 "Such"-Befehle auszugeben, bis ein FALSCH-Ergebnis zurückgegeben wird. Dann gebe ich 2 weitere "Suchbefehle" aus. Wenn der zweite fehlschlägt (dh FALSE), weiß ich, dass es nur einen Sensor auf dem Bus gibt und dass es der "in" -Sensor ist. Die Geräteidentität wird erfasst und dem „in“-Sensor zugeordnet.

Wenn zu einem späteren Zeitpunkt sowohl die erste als auch die zweite Rückgabe WAHR sind, weiß ich, dass sich zwei Sensoren am Bus befinden. Ich überprüfe, welcher von ihnen eine Identität hat, die dem "In"-Sensor entspricht, und weise den anderen als "Out" -Sensor zu.

Der andere kleine Punkt ist, dass die Erfassung der Ergebnisse der beiden Sensoren durch Senden des "Start Conversion" durch einen sogenannten "Skip ROM"-Befehl erfolgt. Wir haben die Möglichkeit, Befehle an ein einzelnes Gerät (unter Verwendung seiner eindeutigen Kennung) oder an alle Geräte am Bus (ROM überspringen) zu senden. Der Code sieht so aus:

ds.reset(); //

// Befehl "Skip ROM" senden (damit der nächste Befehl in beiden Sensoren funktioniert) ds.write (0xCC); // ROM-Befehl überspringen ds.write (0x44, 0); // Konvertierung in beiden Sonden starten temperature_state = wait_convert; // gehe zum Verzögerungszustand

Nach Ablauf der erforderlichen Verzögerungszeit werden die Temperaturen von jedem Sensor einzeln empfangen. Hier ist der Code für den zweiten Sensor (dh den OUT-Sensor).

wenn (flag2) {

vorhanden = ds.reset(); ds.select(DS18B20_addr_out); ds.write(0xBE); // Scratchpad von "out" Probe data [0] lesen = ds.read (); data[1] = ds.read(); temperature_out = (data[1] << 8) + data[0]; temperature_out = (6 * temperature_out) + temperature_out / 4; // mit 6,25 multiplizieren} else {// nicht flag2 - dh Out-Sensor nicht angeschlossen temperature_out = 30000; // bei 300,00 C fixieren, wenn der Temperatursensor nicht funktioniert} // Ende von if (flag2)

Ich habe den größten Teil dieser Software in einer eigenständigen Skizze ausgearbeitet, die nur die Temperatursensoren enthielt, ohne die Komplikationen von LCD-, RTC- und SD-Kartenunterstützung. Diese Entwicklungsskizze befindet sich in der Datei unten.

Schritt 3: Vorläufige Ergebnisse

Dieses Diagramm ist eine Kombination der ersten beiden Teiltage der Messwerte.