DIY loggingstermometer med 2 sensorer: 3 trinn (med bilder)

2024 Forfatter: John Day | [email protected]. Sist endret: 2024-01-30 11:22

Dette prosjektet er en forbedring av mitt forrige prosjekt "DIY Logging Thermometer". Den logger temperaturmålingene til et micro SD -kort.

Maskinvareendringer

Jeg la til en DS18B20 temperatursensor i sanntidsklokke -modulen, der det er plass på kretskortet for denne enheten; og la den passende ledningen fra "DS" -pinnen til RTC til D2 på Arduino.

Programvareendringer

Deretter la jeg til og endret programvaren. De viktigste endringene er:

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

Loggfilene som er registrert på SD -kortet har to temperaturfelt, "temperatur inn" og "temperatur ut".

På grunn av den lengre posten på SD -kortet, var arbeidsbufferne for EEPROM større, og som et resultat av dette begynte jeg å få problemer med minnekonflikter. Jeg gjorde en rekke endringer for å redusere bruken av dynamisk minne, inkludert bruk av tegnoppsett for alle strenger i stedet for String -objekt.

Den delen av programvaren som får temperaturene har store modifikasjoner, mye av det har å gjøre med å identifisere hvilken sonde som er "inn" og hvilken som er "ute". Denne identifikasjonen er for det meste automatisk. Hvis probene av en eller annen grunn er slått på, kan den korrigeres ved å koble fra "sonden" og deretter koble den til igjen. Jeg har ikke opplevd denne reverseringen selv. Programmereren eller brukeren trenger ikke å skrive inn sensoradressene, programvaren oppdager temperatursensoradressene av seg selv.

I henhold til testen jeg har gjort, fungerer identifiseringen av temperatursondene og responsen på fjerning og utskifting av SD -kortet fortsatt sømløst.

Trinn 1: Programvareutvikling

Dette trinnet gir deg full programvare for det fullførte prosjektet. Jeg kompilerte den med Arduino IDE 1.6.12. Den bruker 21, 400 byte programminne (69%) og 1, 278 byte dynamisk minne (62%).

Jeg har lagt kommentarer i koden i håp som vil gjøre det klart hva som skjer.

Trinn 2: Arbeide med to temperatursensorer - Detaljer

Denne programvaren bruker biblioteket "OneWire". Den bruker ikke noen "DallasTemperature" eller lignende biblioteker. I stedet blir kommandoer til og data fra temperatursensorene utført av skissen og kan sees og forstås ganske enkelt. Jeg fant en nyttig liste over OneWire -bibliotekskommandoer på

www.pjrc.com/teensy/td_libs_OneWire.html

Når det er to (eller flere) temperatursensorer, blir det nødvendig å identifisere hvilken som er hvilken.

Jeg kalte mine to sensorer "inn" og "ut", som er typisk for kommersielle enheter som har en sensor i displaymodulen som normalt er "inne", og den andre sensoren på en kabel slik at den kan settes på den andre siden av en yttervegg og dermed være "utenfor".

Den vanlige tilnærmingen for å identifisere de forskjellige sonder er å oppdage enhetsadressene og sette dem i programvaren sammen med en identifiseringsetikett. Alle de andre prosjektene jeg har sett bruker denne tilnærmingen, enten de bruker DallasTemperature -biblioteket eller ikke.

Min intensjon var at programvaren automatisk skulle identifisere sensorene og riktig tildele dem til "inn" og "ut". Dette er enkelt nok å gjøre ved å sette dem på separate Arduino -pinner. I dette prosjektet er A0 til A3 og A6 og A7 alle ubrukte, så en av disse kunne ha blitt brukt i dette tilfellet. Imidlertid lyktes jeg med å få den automatiske identifikasjonen til å fungere med sensorene begge på den samme OneWire -bussen.

Det fungerer slik.

OneWire -biblioteket har en kommando "OneWireObject.search (adresse)" hvor "adresse" er en matrise på 8 byte og "OneWireObject" er navnet på en forekomst av OneWire -objektet som tidligere er opprettet. Den kan ha hvilket som helst navn du liker. Mitt kalles "ds". Når du sender ut denne "søk" -kommandoen, signaliserer OneWire -biblioteket litt på én -trådsbussen. Hvis den finner en svarende sensor, returnerer den en "SANN" boolsk verdi og fyller ut "adresse" -matrisen med 8 bytes unike identifikator for sensoren. Denne identifikatoren inkluderer en familiekode (i begynnelsen) og en sjekksum (på slutten). I mellom er det 6 byte som unikt identifiserer sensoren i familien.

Ett resultat (adresse og retur SANN) oppnås hver gang denne kommandoen gis, og sykler gjennom alle enhetene på OneWire -bussen. Når hver enhet har svart, neste gang "søk" utstedes, er returen "FALSK", som indikerer at hver enhet på bussen allerede har svart. Hvis "søket" blir utstedt igjen, svarer den første enheten igjen - og så videre på ubestemt tid. Enhetene svarer alltid i samme rekkefølge. Svarrekkefølgen er basert på identifikatorene til enhetene på OneWire -bussen. Det ser ut til å være et binært søk som starter fra de minst signifikante bitene i enhetsidentifikatorene. Protokollen som brukes for å finne disse identifikatorene er ganske 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 testet denne søkeprosessen med fra 1 til 11 sensorer på en enkelt buss, og fant svarrekkefølgen for et gitt sett med enheter alltid den samme, men da jeg la til en ny enhet i enden av bussen, var det ingen måte Jeg kunne forutsi hvor i søkeordren det skulle vises. For eksempel kom den 11. sensoren jeg la til i posisjon nr. 5; og den første sensoren jeg satte på bussen var alltid den siste i søkeordren.

I dette prosjektet med to sensorer er en av dem loddet på plass på RTC -modulen; den andre er plugget inn med en mannlig overskrift på brettet og en kvinnelig overskrift på kabelen. Den kan lett løsnes.

Når sensoren på kabelen ("ut" -sensoren) er løsnet, returnerer kommandoen "søk" vekslende "SANN" og "FALSK".

Når sensoren på kabelen er festet, gir kommandoen "søk" en 3-trinns syklus, med to "SANN" og en "FALSK" retur.

Min prosedyre er å utstede 1, 2 eller 3 "søk" -kommandoer, til et FALSKT resultat er returnert. Så utsteder jeg ytterligere 2 "søk" -kommandoer. Hvis den andre mislykkes (dvs. FALSK) vet jeg at det bare er en sensor på bussen og at den er "in" -sensoren. Enhetsidentiteten registreres og tildeles til "in" -sensoren.

På et senere tidspunkt, hvis både første og andre retur er SANN, vet jeg at det er to sensorer på bussen. Jeg sjekker hvilken av dem som har en identitet som er lik "in" -sensoren, og tildeler den andre som "ut" -sensoren.

Det andre mindre punktet er at innsamlingen av resultatene fra de to sensorene gjøres ved å sende "startkonvertering" med det som er kjent som en "hopp over ROM" -kommando. Vi har muligheten til å sende kommandoer til en enkelt enhet (ved hjelp av den unike identifikatoren) eller til alle enheter på bussen (hopp over ROM). Koden ser slik ut:

ds.reset (); //

// send "hopp over ROM" -kommando (så neste kommando fungerer i begge sensorene) ds.write (0xCC); // Hopp over ROM -kommandoen ds.write (0x44, 0); // start konvertering i begge sonder temperatur_stat = ventekonvertering; // gå til forsinket tilstand

Når den nødvendige forsinkelsestiden har passert, mottas temperaturene fra hver sensor individuelt. Her er koden for den andre sensoren (dvs. OUT -sensoren).

hvis (flag2) {

present = ds.reset (); ds.select (DS18B20_addr_out); ds.write (0xBE); // Les Scratchpad med "ut" sondata [0] = ds.read (); data [1] = ds.read (); temperatur_ut = (data [1] << 8) + data [0]; temperatur_ut = (6 * temperatur_ut) + temperatur_ut / 4; // multipliser med 6,25} annet {// ikke flag2 - dvs. Ut -sensor ikke tilkoblet temperatur_ut = 30000; // fikse ved 300,00 C hvis temp sensor ikke fungerer} // slutten av if (flag2)

Jeg utarbeidet det meste av denne programvaren i en frittstående skisse som nettopp hadde temperatursensorene i den, uten komplikasjoner av LCD-, RTC- og SD-kortstøtte. Denne utviklingsskissen er i filen nedenfor.

Trinn 3: Foreløpige resultater

Dette diagrammet er en kombinasjon av de to første deldagene med avlesninger.