DIY Logging Termometer med 2 sensorer: 3 trin (med billeder)

2024 Forfatter: John Day | [email protected]. Sidst ændret: 2024-01-30 08:27

Dette projekt er en forbedring af mit tidligere projekt "DIY Logging Thermometer". Det logger temperaturmålingerne til et micro SD -kort.

Hardwareændringer

Jeg tilføjede en DS18B20 temperatursensor til realtidsurmodulet, hvor der er mulighed for printkortet til denne enhed; og tilføjede den passende ledning fra "DS" stiften af RTC til D2 på Arduino.

Software ændringer

Derefter tilføjede jeg til og ændrede softwaren. De vigtigste ændringer er:

LCD -displayet viser to temperaturer "In" og "Out".

Logfilerne registreret på SD -kortet har to temperaturfelter, "temperatur ind" og "temperatur ud".

På grund af den længere registrering på SD -kortet var arbejdsbufferne til EEPROM større, og som følge heraf begyndte jeg at have problemer med hukommelseskonflikter. Jeg lavede en række ændringer med det formål at reducere brugen af dynamisk hukommelse, herunder brug af tegnfiler til alle strenge i stedet for String -objekt.

Den del af softwaren, der får temperaturerne, har store ændringer, hvoraf meget har at gøre med at identificere, hvilken sonde der er "ind", og hvilken der er "ude". Denne identifikation er for det meste automatisk. Hvis proberne af en eller anden grund skiftes rundt, kan det rettes ved at tage "out" -proben ud og derefter tilslutte den igen. Jeg har ikke selv oplevet denne vending. Programmereren eller brugeren behøver ikke at indtaste sensoradresserne, softwaren opdager temperatursensoradresserne af sig selv.

Ifølge den test, jeg har foretaget, fungerer identifikationen af temperaturproberne og reaktionen på fjernelse og udskiftning af SD -kortet stadig problemfrit.

Trin 1: Softwareudvikling

Dette trin giver dig den fulde software til det gennemførte projekt. Jeg kompilerede det ved hjælp af Arduino IDE 1.6.12. Det bruger 21, 400 bytes programhukommelse (69%) og 1, 278 bytes dynamisk hukommelse (62%).

Jeg har lagt kommentarer i koden i håb om, at det vil gøre det klart, hvad der foregår.

Trin 2: Arbejde med to temperatursensorer - Detaljer

Denne software bruger biblioteket "OneWire". Det bruger ikke nogen "DallasTemperature" eller lignende biblioteker. I stedet udføres kommandoer til og data fra temperatursensorerne efter skitsen og kan ses og forstås ganske let. Jeg fandt en nyttig liste over OneWire -bibliotekskommandoer på

www.pjrc.com/teensy/td_libs_OneWire.html

Når der er to (eller flere) temperatursensorer, bliver det nødvendigt at identificere, hvilken der er hvilken.

Jeg kaldte mine to sensorer "ind" og "ud", hvilket er typisk for kommercielle enheder, der har en sensor i displaymodulet, der normalt er "indeni", og den anden sensor på et kabel, så den kan sættes på den anden side af en ydervæg og dermed være "udenfor".

Den sædvanlige tilgang til at identificere de forskellige sonder er at opdage enhedsadresserne og lægge dem i softwaren sammen med en identificerende etiket. Alle de andre projekter, jeg har set, bruger denne tilgang, uanset om de bruger DallasTemperature -biblioteket eller ej.

Min hensigt var, at softwaren automatisk skulle identificere sensorerne og korrekt tildele dem til "ind" og "ud". Dette er let nok at gøre ved at sætte dem på separate Arduino -ben. I dette projekt er A0 til A3 og A6 og A7 alle ubrugte, så en af disse kunne have været brugt i dette tilfælde. Det lykkedes mig dog at få den automatiske identifikation til at fungere med sensorerne begge på den samme OneWire -bus.

Det fungerer sådan her.

OneWire -biblioteket har en kommando "OneWireObject.search (adresse)", hvor "adresse" er en matrix på 8 bytes, og "OneWireObject" er navnet på en forekomst af OneWire -objektet, der tidligere er blevet oprettet. Det kan have ethvert navn, du kan lide. Min hedder "ds". Når du udsender denne "søg" -kommando, foretager OneWire -biblioteket en vis signalering på den ene ledningsbus. Hvis den finder en reagerende sensor, returnerer den en "SAND" boolsk værdi og udfylder "adresse" arrayet med sensorens 8 byte unikke identifikator. Denne identifikator indeholder en familiekode (i begyndelsen) og en checksum (i slutningen). I mellem er 6 bytes, der entydigt identificerer sensoren inden for sin familie.

Ét resultat (adresse og retur SAND) opnås hver gang denne kommando gives, og cykler gennem alle enhederne på OneWire -bussen. Når hver enhed har reageret, er næste gang "søgning" udsendes, retur "FALSK", hvilket angiver, at hver enhed på bussen allerede har reageret. Hvis "søgningen" udstedes igen, reagerer den første enhed igen - og så videre på ubestemt tid. Enhederne reagerer altid i samme rækkefølge. Svarrækkefølgen er baseret på identifikatorerne for enhederne på OneWire -bussen. Det ser ud til at være en binær søgning, der starter fra de mindst signifikante bits i enhedsidentifikatorerne. Protokollen, der bruges til at finde disse identifikatorer, er ret kompleks og er beskrevet på side 51 - 54 i dokumentet "Book of iButton Standards", som er et pdf -dokument på https://pdfserv.maximintegrated.com/en/an/AN937.pd …

Jeg testede denne søgeproces med fra 1 til 11 sensorer på en enkelt bus, og fandt svarordren for et givet sæt enheder altid den samme, men da jeg tilføjede en ny enhed til slutningen af bussen, var der ingen måde Jeg kunne forudsige, hvor i søgerækkefølgen det skulle vises. For eksempel kom den 11. sensor, jeg tilføjede, ind på position nr. 5; og den første sensor jeg satte på bussen var altid den sidste i søgerækkefølgen.

I dette projekt med to sensorer er en af dem loddet på plads på RTC -modulet; den anden er tilsluttet ved hjælp af en hanhoved på tavlen og en kvindelig overskrift på kablet. Det kan let løsnes.

Når sensoren på kablet ("out" -sensoren) er løsnet, returnerer kommandoen "search" skiftevis "TRUE" og "FALSE" tilbage.

Når sensoren på kablet er tilsluttet, producerer kommandoen "søg" en 3-trins cyklus med to "TRUE" og en "FALSE" returnerer.

Min procedure er at udstede 1, 2 eller 3 "søg" -kommandoer, indtil et FALSKT resultat returneres. Derefter udsender jeg yderligere 2 "søg" kommandoer. Hvis den anden fejler (dvs. FALSK) ved jeg, at der kun er en sensor på bussen, og at den er "in" sensoren. Enhedsidentiteten registreres og tildeles til "in" -sensoren.

På et senere tidspunkt, hvis både første og andet retur er SAND, ved jeg, at der er to sensorer på bussen. Jeg kontrollerer, hvilken af dem der har en identitet, der er lig med "in" -sensoren, og tildeler den anden som "out" -sensoren.

Det andet mindre punkt er, at indsamlingen af resultaterne fra de to sensorer sker ved at sende "startkonvertering" med en såkaldt "skip ROM" -kommando. Vi har mulighed for at sende kommandoer til en enkelt enhed (ved hjælp af dens unikke identifikator) eller til alle enheder på bussen (spring ROM over). Koden ser sådan ud:

ds.reset (); //

// send kommandoen "spring ROM" over (så næste kommando fungerer i begge sensorer) ds.write (0xCC); // Spring over ROM -kommando ds.write (0x44, 0); // start konvertering i begge sonder temperatur_stat = ventekonvertering; // gå til forsinket tilstand

Når den krævede forsinkelsestid er gået, modtages temperaturerne fra hver sensor individuelt. Her er koden til den anden sensor (dvs. OUT -sensoren).

hvis (flag2) {

nuværende = ds.reset (); ds.select (DS18B20_addr_out); ds.write (0xBE); // Læs Scratchpad med "out" sondata [0] = ds.read (); data [1] = ds.read (); temperatur_out = (data [1] << 8) + data [0]; temperaturudgang = (6 * temperaturudgang) + temperaturudgang / 4; // gang med 6,25} else {// ikke flag2 - dvs. Out sensor ikke tilsluttet temperatur_out = 30000; // fix ved 300,00 C, hvis temp -sensor ikke virker} // end of if (flag2)

Jeg udarbejdede det meste af denne software i en enkeltstående skitse, der lige havde temperatursensorerne i den, uden komplikationer ved LCD-, RTC- og SD-kortunderstøttelse. Denne udviklingsskitse er i filen herunder.

Trin 3: Foreløbige resultater

Dette skema er en kombination af de to første deldage af aflæsninger.