INHOUDSOPGAWE:

DIY houttermometer met 2 sensors: 3 stappe (met foto's)
DIY houttermometer met 2 sensors: 3 stappe (met foto's)

Video: DIY houttermometer met 2 sensors: 3 stappe (met foto's)

Video: DIY houttermometer met 2 sensors: 3 stappe (met foto's)
Video: Using Sharp IR GP2Y0A51SK0F Distance Sensor with Arduino (2cm to 15cm) 2024, Julie
Anonim
DIY houttermometer met 2 sensors
DIY houttermometer met 2 sensors
DIY houttermometer met 2 sensors
DIY houttermometer met 2 sensors

Hierdie projek is 'n verbetering van my vorige projek "DIY Logging Thermometer". Dit teken die temperatuurmetings aan op 'n mikro -SD -kaart.

Hardeware verander

Ek het 'n DS18B20 temperatuursensor by die real -time klokmodule gevoeg, waar daar op die printplaat vir hierdie toestel voorsiening is; en voeg die toepaslike draad van die "DS" -pen van RTC by D2 van die Arduino.

Sagteware verander

Daarna het ek die sagteware bygevoeg en aangepas. Die belangrikste veranderinge is:

Die LCD -skerm toon twee temperature "In" en "Out".

Die loglêers wat op die SD -kaart aangeteken is, het twee temperatuurvelde, "temperatuur In" en "temperatuur Uit".

As gevolg van die langer rekord op die SD -kaart, was die werkende buffers vir die EEPROM groter, en as gevolg hiervan het ek geheue -konflikprobleme ondervind. Ek het 'n aantal veranderinge aangebring wat daarop gemik was om die gebruik van dinamiese geheue te verminder, insluitend die gebruik van karakterskikkings vir alle snare in plaas van String -voorwerp.

Die deel van die sagteware wat die temperatuur kry, het groot veranderinge, waarvan baie te doen het met die identifisering van die sonde wat "in" is en watter "uit" is. Hierdie identifikasie is meestal outomaties. As die probes om een of ander rede omgeskakel word, kan dit reggestel word deur die "out" sonde uit te trek en dan weer aan te sluit. Ek het self nie hierdie ommekeer beleef nie. Die programmeerder of gebruiker hoef nie die sensoradresse in te tik nie; die sagteware ontdek self die temperatuursensoradresse.

Volgens die toetse wat ek gedoen het, werk die identifisering van die temperatuursondes en die reaksie op die verwydering en vervanging van die SD -kaart steeds probleemloos.

Stap 1: sagteware -ontwikkeling

Hierdie stap gee u die volledige sagteware vir die voltooide projek. Ek het dit saamgestel met behulp van Arduino IDE 1.6.12. Dit gebruik 21, 400 grepe programgeheue (69%) en 1, 278 grepe dinamiese geheue (62%).

Ek het kommentaar in die kode geplaas in die hoop dat dit duidelik sal maak wat aangaan.

Stap 2: Werk met twee temperatuursensors - besonderhede

Hierdie sagteware gebruik die "OneWire" -biblioteek. Dit gebruik geen 'DallasTemperature' of soortgelyke biblioteke nie. In plaas daarvan word die opdragte na en data van die temperatuursensors volgens die skets uitgevoer en kan dit maklik gesien en verstaan word. Ek het 'n nuttige lys van die OneWire -biblioteekopdragte gevind by

www.pjrc.com/teensy/td_libs_OneWire.html

As daar twee (of meer) temperatuursensors is, word dit nodig om te identifiseer watter een is.

Ek het my twee sensors "in" en "uit" genoem, wat tipies is vir kommersiële eenhede met 'n sensor in die vertoningsmodule wat normaalweg "binne" is, en die ander sensor op 'n kabel sodat dit aan die ander kant geplaas kan word van 'n buitemuur en dus "buite" wees.

Die gewone benadering om die verskillende sondes te identifiseer, is om die toesteladresse te ontdek en in die sagteware te plaas, tesame met 'n identifiserende etiket. Al die ander projekte wat ek gesien het, gebruik hierdie benadering, ongeag of hulle die DallasTemperature -biblioteek al dan nie gebruik.

My bedoeling was dat die sagteware die sensors outomaties moet identifiseer en korrek toewys aan "in" en "uit". Dit is maklik genoeg om dit op aparte Arduino -penne te plaas. In hierdie projek is A0 tot A3 en A6 en A7 almal ongebruik, so een hiervan kon in hierdie geval gebruik gewees het. Ek het egter daarin geslaag om die outomatiese identifikasie met die sensors beide op dieselfde OneWire -bus te laat werk.

Dit werk so.

Die OneWire -biblioteek het die opdrag "OneWireObject.search (address)", waar "address" 'n skikking van 8 grepe is en "OneWireObject" die naam is van 'n voorbeeld van die OneWire -voorwerp wat voorheen geskep is. Dit kan enige naam hê wat u wil. Myne word "ds" genoem. As u hierdie 'soek' -opdrag uitreik, doen die OneWire -biblioteek 'n bietjie sein op die eendraadbus. As dit 'n reagerende sensor vind, gee dit 'n 'WARE' booleaanse waarde terug en vul die 'adres' -skikking in met die 8 byte unieke identifiseerder van die sensor. Hierdie identifiseerder bevat 'n familiekode (aan die begin) en 'n tjeksom (aan die einde). Tussendeur is daar 6 grepe wat die sensor in sy familie uniek identifiseer.

Elke keer as hierdie opdrag gegee word, word een resultaat (adres en opgawe WAAR) verkry, deur al die toestelle op die OneWire -bus. Sodra elke toestel reageer het, is die opgawe 'ONWAAR' die volgende keer dat 'soek' uitgereik word, wat aandui dat elke toestel op die bus al gereageer het. As die "soektog" weer uitgereik word, reageer die eerste toestel weer - en so onbepaald. Die toestelle reageer altyd in dieselfde volgorde. Die volgorde van antwoorde is gebaseer op die identifiseerders van die toestelle op die OneWire -bus. Dit blyk 'n binêre soektog te wees, wat begin met die minste belangrike stukke van die apparaat -identifiseerders. Die protokol wat gebruik word om hierdie identifiseerders te vind, is redelik kompleks en word beskryf op bladsye 51 - 54 van dokument "Book of iButton Standards", 'n pdf -dokument op https://pdfserv.maximintegrated.com/en/an/AN937.pd …

Ek het hierdie soekproses met 1 tot 11 sensors op 'n enkele bus getoets en gevind dat die antwoordvolgorde vir 'n gegewe stel toestelle altyd dieselfde was, maar toe ek 'n nuwe toestel by die einde van die bus voeg, was daar geen manier nie Ek kon voorspel waar dit in die soekvolgorde sou verskyn. Byvoorbeeld, die 11de sensor wat ek bygevoeg het, kom in posisie 5 in; en die eerste sensor wat ek in die bus gesit het, was altyd die laaste in die soekvolgorde.

In hierdie projek met twee sensors word een daarvan op die RTC -module gesoldeer; die ander een word ingeprop met 'n manlike kop op die bord en 'n vroulike kop op die kabel. Dit kan maklik losgemaak word.

As die sensor op die kabel (die "uit" -sensor) losgemaak word, lewer die opdrag "soek" afwisselend "WAAR" en "ONWAAR" op.

As die sensor op die kabel aangeheg is, lewer die "soek" -opdrag 'n 3-trapsiklus, met twee "WAAR" en een "ONWAAR" opbrengs.

My prosedure is om 1, 2 of 3 "soek" -opdragte uit te reik totdat 'n ONWAAR resultaat teruggekeer word. Dan reik ek nog 2 "soek" opdragte uit. As die tweede een misluk (dws ONWAAR) weet ek dat daar slegs een sensor op die bus is en dat dit die 'in' sensor is. Die toestelidentiteit word aangeteken en toegeken aan die "in" sensor.

Op 'n later tydstip, as die eerste en tweede terugvoer WAAR is, weet ek dat daar twee sensors op die bus is. Ek kyk watter een van hulle 'n identiteit het wat gelyk is aan die "in" sensor, en ken die ander een toe as die "uit" sensor.

Die ander klein punt is dat die insameling van die resultate van die twee sensors gedoen word deur die 'begin -omskakeling' te stuur met 'n 'skip ROM' -opdrag. Ons het die opsie om opdragte na 'n enkele toestel te stuur (met behulp van sy unieke identifikator) of na alle toestelle op die bus (slaan ROM oor). Die kode lyk so:

ds.reset (); //

// stuur 'skip ROM' -opdrag (sodat die volgende opdrag in beide sensors werk) ds.write (0xCC); // Slaan ROM -opdrag oor ds.write (0x44, 0); // begin omskakeling in beide probes temperature_state = wait_convert; // gaan na die vertraagde toestand

As die vereiste vertragingstyd verby is, word die temperature afsonderlik van elke sensor ontvang. Hier is die kode vir die tweede sensor (dws die OUT sensor).

as (vlag2) {

present = ds.reset (); ds.select (DS18B20_addr_out); ds.write (0xBE); // Lees Scratchpad van "out" sonde data [0] = ds.read (); data [1] = ds.read (); temperatuur_uit = (data [1] << 8) + data [0]; temperatuur_uit = (6 * temperatuur_uit) + temperatuur_uit / 4; // vermenigvuldig met 6,25} anders {// nie vlag2 nie - dws Uit sensor nie gekoppel temperatuur_out = 30000; // herstel by 300.00 C as die temp sensor nie werk nie} // einde van if (flag2)

Ek het die meeste van hierdie sagteware uitgewerk in 'n losstaande skets met net die temperatuursensors, sonder die komplikasies van LCD-, RTC- en SD-kaartondersteuning. Hierdie ontwikkelingskets is in die onderstaande lêer.

Stap 3: Voorlopige resultate

Voorlopige uitslae
Voorlopige uitslae

Hierdie grafiek is 'n kombinasie van die eerste twee deels dae van lesings.

Aanbeveel: