DIY-registratiethermometer met 2 sensoren - Ajarnpa

2024 Auteur: John Day | [email protected]. Laatst gewijzigd: 2024-01-30 11:16

Dit project is een verbetering van mijn vorige project "DIY Logging Thermometer". Het logt de temperatuurmetingen op een micro SD-kaart.

Hardwarewijzigingen

Ik heb een DS18B20 temperatuursensor toegevoegd aan de real-time klokmodule, waar op de printplaat een voorziening is voor dit apparaat; en voegde de juiste draad toe van de "DS"-pin van RTC naar D2 van de Arduino.

Softwarewijzigingen

Daarna heb ik de software toegevoegd en aangepast. De belangrijkste wijzigingen zijn:

Het LCD-display toont twee temperaturen "In" en "Out".

De logbestanden die op de SD-kaart zijn opgeslagen, hebben twee temperatuurvelden, "temperature In" en "temperature Out".

Vanwege de langere opname op de SD-kaart waren de werkbuffers voor de EEPROM groter en als gevolg hiervan begon ik geheugenconflictproblemen te krijgen. Ik heb een aantal wijzigingen aangebracht om het gebruik van dynamisch geheugen te verminderen, waaronder het gebruik van tekenreeksen voor alle strings in plaats van String-objecten.

Het deel van de software dat de temperaturen ontvangt, heeft grote wijzigingen ondergaan, waarvan een groot deel te maken heeft met het identificeren welke sonde "in" en welke "uit" is. Deze identificatie is grotendeels automatisch. Als de sondes om de een of andere reden worden verwisseld, kan dit worden gecorrigeerd door de "uit"-sonde los te koppelen en vervolgens weer aan te sluiten. Zelf heb ik deze omkering niet meegemaakt. De programmeur of gebruiker hoeft de sensoradressen niet in te voeren, de software ontdekt de temperatuursensoradressen zelf.

Volgens de tests die ik heb gedaan, werken de identificatie van de temperatuursondes en de reactie op het verwijderen en vervangen van de SD-kaart nog steeds naadloos.

Stap 1: Softwareontwikkeling

Deze stap geeft u de volledige software voor het voltooide project. Ik heb het gecompileerd met Arduino IDE 1.6.12. Het gebruikt 21.400 bytes programmageheugen (69%) en 1.278 bytes dynamisch geheugen (62%).

Ik heb opmerkingen in de code geplaatst in de hoop dat het duidelijk maakt wat er aan de hand is.

Stap 2: Werken met twee temperatuursensoren - Details

Deze software maakt gebruik van de "OneWire"-bibliotheek. Het gebruikt geen "DallasTemperature" of vergelijkbare bibliotheken. In plaats daarvan worden de commando's naar en gegevens van de temperatuursensoren gedaan door de schets en kunnen ze vrij gemakkelijk worden gezien en begrepen. Ik vond een handige lijst met de OneWire-bibliotheekopdrachten op

www.pjrc.com/teensy/td_libs_OneWire.html

Wanneer er twee (of meer) temperatuursensoren zijn, wordt het noodzakelijk om te identificeren welke welke is.

Ik heb mijn twee sensoren "in" en "uit" genoemd, wat typerend is voor commerciële eenheden die een sensor in de displaymodule hebben die normaal "binnen" is, en de andere sensor op een kabel zodat deze aan de andere kant kan worden geplaatst van een buitenmuur en dus "buiten" zijn.

De gebruikelijke benadering voor het identificeren van de verschillende sondes is om de apparaatadressen te ontdekken en deze samen met een identificatielabel in de software te plaatsen. Alle andere projecten die ik heb gezien, gebruiken deze aanpak, of ze nu de DallasTemperature-bibliotheek gebruiken of niet.

Mijn bedoeling was dat de software de sensoren automatisch zou identificeren en correct zou toewijzen aan "in" en "uit". Dit is eenvoudig genoeg om te doen door ze op afzonderlijke Arduino-pinnen te plaatsen. In dit project zijn A0 tot A3 en A6 en A7 allemaal ongebruikt, dus in dit geval zou een van deze kunnen zijn gebruikt. Het is me echter gelukt om de automatische identificatie te laten werken met de sensoren beide op dezelfde OneWire-bus.

Het werkt zo.

De OneWire-bibliotheek heeft een opdracht "OneWireObject.search(address)" waarbij "address" een array van 8 bytes is en "OneWireObject" de naam is van een instantie van het OneWire-object dat eerder is gemaakt. Het kan elke gewenste naam hebben. De mijne heet "ds". Wanneer u deze "zoekopdracht" geeft, doet de OneWire-bibliotheek wat signalering op de eendraadsbus. Als het een reagerende sensor vindt, retourneert het een "TRUE" booleaanse waarde en vult het de "adres"-array in met de 8 byte unieke identifier van de sensor. Deze identifier bevat een familiecode (aan het begin) en een controlesom (aan het einde). Daartussen bevinden zich 6 bytes die de sensor binnen zijn familie op unieke wijze identificeren.

Elke keer dat deze opdracht wordt gegeven, wordt één resultaat (adres en retour TRUE) verkregen, waarbij alle apparaten op de OneWire-bus worden doorlopen. Zodra elk apparaat heeft gereageerd, is de volgende keer dat "zoeken" wordt uitgevoerd, "FALSE", wat aangeeft dat elk apparaat op de bus al heeft gereageerd. Als de "zoekopdracht" opnieuw wordt uitgevoerd, reageert het eerste apparaat opnieuw - en zo verder voor onbepaalde tijd. De apparaten reageren altijd in dezelfde volgorde. De volgorde van antwoorden is gebaseerd op de identifiers van de apparaten op de OneWire-bus. Het lijkt een binaire zoekopdracht te zijn die begint met de minst significante bits van de apparaat-ID's. Het protocol dat wordt gebruikt om deze identifiers te vinden is behoorlijk complex en wordt beschreven op pagina's 51 - 54 van het document "Book of iButton Standards", een pdf-document op https://pdfserv.maximintegrated.com/en/an/AN937.pd …

Ik testte dit zoekproces met 1 tot 11 sensoren op een enkele bus en ontdekte dat de antwoordvolgorde voor een bepaalde set apparaten altijd hetzelfde was, maar toen ik een nieuw apparaat aan het einde van de bus toevoegde, was er geen manier om Ik kon voorspellen waar in de zoekvolgorde het zou verschijnen. De 11e sensor die ik heb toegevoegd, kwam bijvoorbeeld binnen op positie nr. 5; en de eerste sensor die ik op de bus plaatste, was altijd de laatste in de zoekvolgorde.

In dit project met twee sensoren is er één op zijn plaats gesoldeerd op de RTC-module; de andere is aangesloten met een mannelijke header op het bord en een vrouwelijke header op de kabel. Het kan gemakkelijk worden losgemaakt.

Wanneer de sensor op de kabel (de "uit"-sensor) wordt losgemaakt, produceert het "zoeken"-commando afwisselend "TRUE" en "FALSE" retourneringen.

Wanneer de sensor op de kabel is aangesloten, produceert het "zoek"-commando een 3-traps cyclus, met twee "TRUE" en één "FALSE" retouren.

Mijn procedure is om 1, 2 of 3 "zoek"-commando's te geven, totdat een FALSE resultaat wordt geretourneerd. Dan geef ik nog 2 "zoek"-commando's. Als de tweede faalt (dwz FALSE), weet ik dat er maar één sensor op de bus is en dat dit de "in" -sensor is. De apparaatidentiteit wordt geregistreerd en toegewezen aan de "in"-sensor.

Op een later tijdstip, als zowel de eerste als de tweede retour WAAR zijn, weet ik dat er twee sensoren op de bus zitten. Ik controleer welke van hen een identiteit heeft die gelijk is aan de "in" -sensor en wijs de andere toe als de "uit" -sensor.

Het andere kleine punt is dat het verzamelen van de resultaten van de twee sensoren wordt gedaan door het verzenden van de "start conversie" door wat bekend staat als een "skip ROM"-opdracht. We hebben de mogelijkheid om opdrachten naar een enkel apparaat te sturen (met behulp van de unieke identifier) of naar alle apparaten op de bus (ROM overslaan). De code ziet er als volgt uit:

ds.reset(); //

// stuur "skip ROM" commando (dus volgende commando werkt in beide sensoren) ds.write(0xCC); // Sla ROM-opdracht over ds.write (0x44, 0); // start conversie in beide sondes temperature_state = wait_convert; // ga naar vertragingsstatus

Wanneer de vereiste vertragingstijd is verstreken, worden de temperaturen van elke sensor afzonderlijk ontvangen. Hier is de code voor de tweede sensor (dwz de OUT-sensor).

als (vlag2) {

aanwezig = ds.reset(); ds.select(DS18B20_addr_out); ds.write(0xBE); // Lees kladblok van "uit" sondegegevens [0] = ds.read (); data[1] = ds.lezen(); temperatuur_uit = (data[1] << 8) + data[0]; temperatuur_uit = (6 * temperatuur_uit) + temperatuur_uit / 4; // vermenigvuldig met 6,25 } else { // not flag2 - dwz Out sensor niet aangesloten temperature_out = 30000; // fix op 300.00 C als temperatuursensor niet werkt } // einde van if (vlag 2)

Ik heb het grootste deel van deze software uitgewerkt in een op zichzelf staande schets die alleen de temperatuursensoren bevatte, zonder de complicaties van LCD-, RTC- en SD-kaartondersteuning. Deze ontwikkelschets staat in onderstaand bestand.

Stap 3: Voorlopige resultaten

Deze grafiek is een combinatie van de eerste twee dagdelen.