Termometro di registrazione fai da te con 2 sensori: 3 passaggi (con immagini)

2024 Autore: John Day | [email protected]. Ultima modifica: 2024-01-30 10:01

Questo progetto è un miglioramento del mio precedente progetto "Termometro di registrazione fai da te". Registra le misurazioni della temperatura su una scheda micro SD.

Modifiche hardware

Ho aggiunto un sensore di temperatura DS18B20 al modulo dell'orologio in tempo reale, dove è previsto sul circuito stampato per questo dispositivo; e aggiunto il filo appropriato dal pin "DS" di RTC a D2 di Arduino.

Modifiche al software

Poi ho aggiunto e modificato il software. Le principali modifiche sono:

Il display LCD mostra due temperature "In" e "Out".

I file di registro registrati sulla scheda SD hanno due campi di temperatura, "temperatura in" e "temperatura in uscita".

A causa della registrazione più lunga sulla scheda SD, i buffer di lavoro per la EEPROM erano più grandi e di conseguenza ho iniziato ad avere problemi di conflitto di memoria. Ho apportato una serie di modifiche volte a ridurre l'utilizzo della memoria dinamica, incluso l'utilizzo di array di caratteri per tutte le stringhe invece dell'oggetto String.

La parte del software che rileva le temperature ha importanti modifiche, molte delle quali hanno a che fare con l'identificazione di quale sonda è "dentro" e quale è "fuori". Questa identificazione è per lo più automatica. Se per qualche motivo le sonde vengono invertite, può essere corretto scollegando la sonda "out" e quindi ricollegandola. Non ho sperimentato personalmente questo capovolgimento. Il programmatore o l'utente non ha bisogno di digitare gli indirizzi del sensore, il software scopre da solo gli indirizzi del sensore di temperatura.

Secondo i test che ho fatto, l'identificazione delle sonde di temperatura e la risposta alla rimozione e sostituzione della scheda SD funzionano ancora perfettamente.

Passaggio 1: sviluppo software

Questo passaggio fornisce il software completo per il progetto completato. L'ho compilato usando Arduino IDE 1.6.12. Utilizza 21.400 byte di memoria di programma (69%) e 1.278 byte di memoria dinamica (62%).

Ho inserito commenti nel codice nella speranza che chiariscano cosa sta succedendo.

Passaggio 2: utilizzo di due sensori di temperatura - Dettagli

Questo software utilizza la libreria "OneWire". Non utilizza alcuna libreria "DallasTemperature" o simili. Invece i comandi e i dati dai sensori di temperatura sono eseguiti dallo schizzo e possono essere visti e compresi abbastanza facilmente. Ho trovato un elenco utile dei comandi della libreria OneWire su

www.pjrc.com/teensy/td_libs_OneWire.html

Quando sono presenti due (o più) sensori di temperatura, diventa necessario identificare quale è quale.

Ho chiamato i miei due sensori "in" e "out", che è tipico delle unità commerciali che hanno un sensore nel modulo display che normalmente è "dentro", e l'altro sensore su un cavo in modo che possa essere messo dall'altra parte di un muro esterno e quindi essere "fuori".

L'approccio consueto per identificare le diverse sonde consiste nel rilevare gli indirizzi del dispositivo e inserirli nel software insieme a un'etichetta identificativa. Tutti gli altri progetti che ho visto utilizzano questo approccio, indipendentemente dal fatto che utilizzino o meno la libreria DallasTemperature.

La mia intenzione era che il software identificasse automaticamente i sensori e li assegnasse correttamente a "in" e "out". Questo è abbastanza facile da fare mettendoli su pin Arduino separati. In questo progetto, da A0 a A3 e A6 e A7 sono tutti inutilizzati, quindi uno di questi potrebbe essere stato utilizzato in questo caso. Tuttavia sono riuscito a far funzionare l'identificazione automatica con i sensori entrambi sullo stesso bus OneWire.

Funziona così.

La libreria OneWire ha un comando "OneWireObject.search(address)" dove "address" è un array di 8 byte e "OneWireObject" è il nome di un'istanza dell'oggetto OneWire che è stato precedentemente creato. Può avere qualsiasi nome tu voglia. Il mio si chiama "ds". Quando si invia questo comando di "ricerca", la libreria OneWire esegue alcuni segnali sul bus a un filo. Se trova un sensore che risponde, restituisce un valore booleano "TRUE" e riempie l'array "address" con l'identificatore univoco di 8 byte del sensore. Questo identificatore include un codice famiglia (all'inizio) e un checksum (alla fine). In mezzo ci sono 6 byte che identificano in modo univoco il sensore all'interno della sua famiglia.

Si ottiene un risultato (indirizzo e ritorno TRUE) ogni volta che viene dato questo comando, scorrendo tutti i dispositivi sul bus OneWire. Una volta che ogni dispositivo ha risposto, alla successiva emissione di "ricerca", il ritorno è "FALSE", indicando che ogni dispositivo sul bus ha già risposto. Se la "ricerca" viene emessa di nuovo, il primo dispositivo risponde di nuovo e così via all'infinito. I dispositivi rispondono sempre nello stesso ordine. L'ordine delle risposte si basa sugli identificatori dei dispositivi sul bus OneWire. Sembra essere una ricerca binaria a partire dai bit meno significativi degli identificatori del dispositivo. Il protocollo utilizzato per trovare questi identificatori è piuttosto complesso ed è descritto nelle pagine 51 - 54 del documento "Book of iButton Standards" che è un documento pdf all'indirizzo https://pdfserv.maximintegrated.com/en/an/AN937.pd …

Ho testato questo processo di ricerca con da 1 a 11 sensori su un singolo bus e ho scoperto che l'ordine di risposta per un determinato insieme di dispositivi era sempre lo stesso, ma quando ho aggiunto un nuovo dispositivo alla fine del bus, non c'era modo Potrei prevedere dove nell'ordine di ricerca sarebbe apparso. Ad esempio, l'undicesimo sensore che ho aggiunto è arrivato nella posizione n.5; e il primo sensore che ho messo sull'autobus è stato sempre l'ultimo nell'ordine di ricerca.

In questo progetto con due sensori, uno dei quali è saldato in posizione sul modulo RTC; l'altro è collegato utilizzando un connettore maschio sulla scheda e un connettore femmina sul cavo. Può essere facilmente staccato.

Quando il sensore sul cavo (il sensore "fuori") viene staccato, il comando "ricerca" produce i ritorni alternati "VERO" e "FALSO".

Quando il sensore sul cavo è collegato, il comando "ricerca" produce un ciclo a 3 fasi, con due ritorni "VERO" e uno "FALSO".

La mia procedura consiste nell'emettere 1, 2 o 3 comandi di "ricerca", fino a quando non viene restituito un risultato FALSE. Quindi emetto altri 2 comandi di "ricerca". Se il secondo fallisce (cioè FALSE) so che c'è un solo sensore sul bus e che è il sensore "in". L'identità del dispositivo viene registrata e assegnata al sensore "in".

In un secondo momento, se sia il primo che il secondo ritorno sono VERI, so che ci sono due sensori sul bus. Controllo quale di loro ha un'identità uguale al sensore "in" e assegno l'altro come sensore "out".

L'altro punto minore è che la raccolta dei risultati dai due sensori avviene inviando il comando "start conversion" tramite il cosiddetto comando "skip ROM". Abbiamo la possibilità di inviare comandi a un singolo dispositivo (utilizzando il suo identificatore univoco) oa tutti i dispositivi sul bus (salta ROM). Il codice è simile a questo:

ds.reset(); //

// invia il comando "skip ROM" (quindi il comando successivo funziona in entrambi i sensori) ds.write(0xCC); // Salta il comando ROM ds.write(0x44, 0); // avvia la conversione in entrambe le sonde temperature_state = wait_convert; // vai allo stato di ritardo

Trascorso il tempo di ritardo richiesto, le temperature vengono ricevute singolarmente da ciascun sensore. Ecco il codice per il secondo sensore (cioè il sensore OUT).

if (flag2) {

presente = ds.reset(); ds.select(DS18B20_addr_out); ds.write(0xBE); // Leggi Scratchpad di "out" probe data[0] = ds.read(); data[1] = ds.read(); temperatura_uscita = (data[1] << 8) + data[0]; temperatura_uscita = (6 * temperatura_uscita) + temperatura_uscita / 4; // moltiplica per 6,25 } else { // not flag2 - cioè Out sensore non connesso temperature_out = 30000; // fissato a 300,00 C se il sensore di temperatura non funziona } // fine di if (flag2)

Ho elaborato la maggior parte di questo software in uno schizzo autonomo che conteneva solo i sensori di temperatura, senza le complicazioni del supporto per LCD, RTC e schede SD. Questo schizzo di sviluppo è nel file sottostante.

Passaggio 3: risultati preliminari

Questo grafico è una combinazione delle prime due giornate di letture.