DIY loggningstermometer med 2 sensorer: 3 steg (med bilder)

2024 Författare: John Day | [email protected]. Senast ändrad: 2024-01-30 12:41

Detta projekt är en förstärkning av mitt tidigare projekt "DIY Logging Thermometer". Det loggar temperaturmätningarna till ett micro SD -kort.

Hårdvaruändringar

Jag lade till en DS18B20 temperatursensor i realtidsklockemodulen, där det finns plats på kretskortet för denna enhet; och tillsatte lämplig tråd från "DS" -nålen på RTC till D2 på Arduino.

Programvaruändringar

Sedan lade jag till och ändrade programvaran. De viktigaste förändringarna är:

LCD -displayen visar två temperaturer "In" och "Out".

Loggfilerna som spelats in på SD -kortet har två temperaturfält, "temperatur in" och "temperatur ut".

På grund av den längre posten på SD -kortet var arbetsbuffertarna för EEPROM större och som ett resultat av detta började jag få problem med minneskonflikter. Jag gjorde ett antal ändringar som syftar till att minska användningen av dynamiskt minne, inklusive att använda teckenuppsättningar för alla strängar istället för String -objekt.

Den del av programvaran som får temperaturerna har stora modifieringar, mycket av dem har att göra med att identifiera vilken sond som är "in" och vilken som är "ute". Denna identifiering är mestadels automatisk. Om proberna av någon anledning är omkopplade kan det korrigeras genom att koppla ur "ut" -sonden och sedan ansluta den igen. Jag har inte själv upplevt denna vändning. Programmeraren eller användaren behöver inte skriva in sensoradresserna, programvaran upptäcker temperatursensoradresserna av sig själv.

Enligt de tester jag har gjort fungerar identifiering av temperatursonderna och svaret på borttagning och byte av SD -kortet fortfarande sömlöst.

Steg 1: Programutveckling

Detta steg ger dig fullständig programvara för det slutförda projektet. Jag kompilerade det med Arduino IDE 1.6.12. Den använder 21, 400 byte programminne (69%) och 1, 278 byte dynamiskt minne (62%).

Jag har lagt kommentarer i koden i hopp om att det ska bli tydligt vad som händer.

Steg 2: Arbeta med två temperatursensorer - Detaljer

Denna programvara använder biblioteket "OneWire". Det använder inga "DallasTemperature" eller liknande bibliotek. Istället görs kommandona till och data från temperatursensorerna enligt skissen och kan ses och förstås ganska enkelt. Jag hittade en användbar lista över OneWire -bibliotekskommandon på

www.pjrc.com/teensy/td_libs_OneWire.html

När det finns två (eller flera) temperatursensorer blir det nödvändigt att identifiera vilken som är vilken.

Jag kallade mina två sensorer "in" och "out", vilket är typiskt för kommersiella enheter som har en sensor i displaymodulen som normalt är "inuti", och den andra sensorn på en kabel så att den kan sättas på andra sidan av en yttervägg och därmed vara "utanför".

Det vanliga sättet att identifiera de olika sonderna är att upptäcka enhetsadresserna och lägga dem i programvaran tillsammans med en identifieringsetikett. Alla andra projekt som jag har sett använder detta tillvägagångssätt, oavsett om de använder DallasTemperature -biblioteket eller inte.

Min avsikt var att programvaran automatiskt skulle identifiera sensorerna och korrekt fördela dem till "in" och "out". Detta är enkelt nog att göra genom att lägga dem på separata Arduino -stift. I detta projekt är A0 till A3 och A6 och A7 alla oanvända, så en av dessa kunde ha använts i det här fallet. Men jag lyckades få den automatiska identifieringen att fungera med sensorerna båda på samma OneWire -buss.

Det fungerar så här.

OneWire -biblioteket har ett kommando "OneWireObject.search (address)" där "address" är en array med 8 byte och "OneWireObject" är namnet på en instans av OneWire -objektet som tidigare har skapats. Den kan ha vilket namn du vill. Min heter "ds". När du utfärdar detta "sök" -kommando gör OneWire -biblioteket viss signalering på entrådsbussen. Om den hittar en svarande sensor returnerar den ett "SANT" boolskt värde och fyller i "adress" -matrisen med sensorns 8 byte unika identifierare. Denna identifierare inkluderar en familjekod (i början) och en check summa (i slutet). Däremellan finns 6 byte som unikt identifierar sensorn inom sin familj.

Ett resultat (adress och retur SANT) erhålls varje gång detta kommando ges, genom att cykla genom alla enheter på OneWire -bussen. När varje enhet har svarat, nästa gång "sökning" utfärdas, är returen "FALSE", vilket indikerar att varje enhet på bussen redan har svarat. Om "sökningen" utfärdas igen, svarar den första enheten igen - och så vidare på obestämd tid. Enheterna svarar alltid i samma ordning. Svarordningen är baserad på identifierarna för enheterna på OneWire -bussen. Det verkar vara en binär sökning utgående från de minst signifikanta bitarna i enhetsidentifierarna. Protokollet som används för att hitta dessa identifierare är ganska komplext och beskrivs på sidorna 51 - 54 i dokumentet "Book of iButton Standards" som är ett pdf -dokument på https://pdfserv.maximintegrated.com/en/an/AN937.pd …

Jag testade den här sökprocessen med från 1 till 11 sensorer på en enda buss och fann att svarsordningen för en viss uppsättning enheter alltid var densamma, men när jag lade till en ny enhet i slutet av bussen fanns det inget sätt Jag kunde förutsäga var i sökordningen den skulle visas. Till exempel kom den 11: e sensorn jag lade till i position nr 5; och den första sensorn jag satte på bussen var alltid den sista i sökordningen.

I detta projekt med två sensorer är en av dem lödda på plats på RTC -modulen; den andra är ansluten med en manlig huvud på kortet och en kvinnlig rubrik på kabeln. Det kan enkelt lossas.

När sensorn på kabeln ("ut" -sensorn) kopplas loss, returnerar kommandot "sök" alternerande "TRUE" och "FALSE".

När sensorn på kabeln är ansluten ger kommandot "sök" en cykel i tre steg, med två "SANT" och en "FALSK" retur.

Min procedur är att utfärda 1, 2 eller 3 "sök" -kommandon tills ett FALSKT resultat returneras. Sedan utfärdar jag ytterligare två "sök" -kommandon. Om den andra misslyckas (dvs. FALSK) vet jag att det bara finns en sensor på bussen och att den är "in" -sensorn. Enhetsidentiteten registreras och tilldelas sensorn "in".

Vid ett senare tillfälle, om både första och andra returer är SANT, vet jag att det finns två sensorer på bussen. Jag kontrollerar vilken av dem som har en identitet som är lika med "in" -sensorn och tilldelar den andra som "ut" -sensorn.

Den andra mindre punkten är att insamlingen av resultaten från de två sensorerna sker genom att skicka "startkonvertering" med det som kallas ett "hoppa över ROM" -kommando. Vi har möjlighet att skicka kommandon till en enda enhet (med dess unika identifierare) eller till alla enheter på bussen (hoppa över ROM). Koden ser ut så här:

ds.reset (); //

// skicka "hoppa över ROM" -kommando (så nästa kommando fungerar i båda sensorerna) ds.write (0xCC); // Hoppa över ROM -kommandot ds.write (0x44, 0); // starta konvertering i båda sonderna temperature_state = wait_convert; // gå till fördröjningstillstånd

När den erforderliga fördröjningstiden har passerat mottas temperaturen från varje sensor individuellt. Här är koden för den andra sensorn (dvs. OUT -sensorn).

if (flag2) {

present = 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]; temperatur_ut = (6 * temperatur_ut) + temperatur_ut / 4; // multiplicera med 6,25} annars {// inte flag2 - dvs utgivare inte ansluten temperatur_ut = 30000; // fixa vid 300,00 C om temp -sensorn inte fungerar} // slutet av if (flag2)

Jag utarbetade det mesta av denna programvara i en fristående skiss som bara hade temperatursensorerna i den, utan komplikationer av LCD-, RTC- och SD-kortstöd. Denna utvecklingsskiss finns i filen nedan.

Steg 3: Preliminära resultat

Detta diagram är en kombination av de två första deldagarna av avläsningar.