Termometr rejestrujący DIY z 2 czujnikami: 3 kroki (ze zdjęciami)

2024 Autor: John Day | [email protected]. Ostatnio zmodyfikowany: 2024-01-30 11:29

Ten projekt jest rozwinięciem mojego poprzedniego projektu "Termometr rejestrujący DIY". Rejestruje pomiary temperatury na karcie micro SD.

Zmiany sprzętowe

Do modułu zegara czasu rzeczywistego dodałem czujnik temperatury DS18B20, gdzie jest zapis na płytce drukowanej dla tego urządzenia; i dodałem odpowiedni przewód z pinu „DS” RTC do D2 Arduino.

Zmiany oprogramowania

Następnie dodałem i zmodyfikowałem oprogramowanie. Główne zmiany to:

Wyświetlacz LCD pokazuje dwie temperatury „In” i „Out”.

Pliki dziennika zapisane na karcie SD mają dwa pola temperatury, „temperatura wejścia” i „temperatura wyjścia”.

Z powodu dłuższego zapisu na karcie SD bufory robocze dla EEPROM były większe i w wyniku tego zacząłem mieć problemy z konfliktem pamięci. Wprowadziłem szereg zmian mających na celu zmniejszenie zużycia pamięci dynamicznej, w tym użycie tablic znaków dla wszystkich ciągów zamiast obiektu String.

Część oprogramowania, która pobiera temperatury, została poddana poważnym modyfikacjom, z których większość ma związek z identyfikacją, która sonda jest „włożona”, a która „wyłączona”. Ta identyfikacja jest w większości automatyczna. Jeśli z jakiegoś powodu sondy są przełączane, można to naprawić, odłączając sondę „out” i ponownie ją podłączając. Sam nie doświadczyłem tego odwrócenia. Programista lub użytkownik nie musi wpisywać adresów czujników, oprogramowanie samo wykrywa adresy czujników temperatury.

Według przeprowadzonych przeze mnie testów identyfikacja sond temperatury oraz reakcja na wyjęcie i wymianę karty SD nadal działają bezproblemowo.

Krok 1: Rozwój oprogramowania

Ten krok daje pełne oprogramowanie do ukończonego projektu. Skompilowałem go przy użyciu Arduino IDE 1.6.12. Wykorzystuje 21 400 bajtów pamięci programu (69%) i 1 278 bajtów pamięci dynamicznej (62%).

Umieściłem komentarze w kodzie w nadziei, że wyjaśnią, co się dzieje.

Krok 2: Praca z dwoma czujnikami temperatury - szczegóły

To oprogramowanie korzysta z biblioteki „OneWire”. Nie używa żadnych bibliotek "DallasTemperature" ani podobnych. Zamiast tego polecenia i dane z czujników temperatury są wykonywane przez szkic i można je dość łatwo zobaczyć i zrozumieć. Przydatną listę poleceń biblioteki OneWire znalazłem pod adresem

www.pjrc.com/teensy/td_libs_OneWire.html

Gdy istnieją dwa (lub więcej) czujniki temperatury, konieczne staje się określenie, który z nich jest który.

Swoje dwa czujniki nazwałem "in" i "out", co jest typowe dla jednostek komercyjnych, które mają czujnik w module wyświetlacza który normalnie jest "wewnątrz", a drugi czujnik na kablu więc można go włożyć z drugiej strony ściany zewnętrznej i tym samym być „na zewnątrz”.

Typowym podejściem do identyfikacji różnych sond jest odkrycie adresów urządzeń i umieszczenie ich w oprogramowaniu wraz z etykietą identyfikacyjną. Wszystkie inne projekty, które widziałem, stosują to podejście, niezależnie od tego, czy korzystają z biblioteki DallasTemperature, czy nie.

Moim zamiarem było, aby oprogramowanie automatycznie identyfikowało czujniki i poprawnie przydzielało je do „wejścia” i „wyjścia”. Jest to dość łatwe, umieszczając je na osobnych pinach Arduino. W tym projekcie A0 do A3 oraz A6 i A7 są nieużywane, więc jeden z nich mógł zostać użyty w tym przypadku. Udało mi się jednak, aby automatyczna identyfikacja działała z czujnikami na tej samej magistrali OneWire.

To działa tak.

Biblioteka OneWire zawiera polecenie „OneWireObject.search(adres)”, gdzie „adres” to tablica 8 bajtów, a „OneWireObject” to nazwa wcześniej utworzonego wystąpienia obiektu OneWire. Może mieć dowolną nazwę. Mój nazywa się „ds”. Po wydaniu tego polecenia „szukaj”, biblioteka OneWire wykonuje pewną sygnalizację na magistrali jednoprzewodowej. Jeśli znajdzie odpowiadający czujnik, zwraca wartość logiczną „PRAWDA” i wypełnia tablicę „adres” 8-bajtowym unikalnym identyfikatorem czujnika. Ten identyfikator zawiera kod rodziny (na początku) i sumę kontrolną (na końcu). Pomiędzy nimi znajduje się 6 bajtów, które jednoznacznie identyfikują czujnik w jego rodzinie.

Po każdym wydaniu tego polecenia uzyskiwany jest jeden wynik (adres i zwrot TRUE), przechodzący przez wszystkie urządzenia na magistrali OneWire. Gdy każde urządzenie zareaguje, przy następnym wydaniu „wyszukiwania” zwrot to „FAŁSZ”, co oznacza, że każde urządzenie na magistrali już odpowiedziało. Jeśli "wyszukiwanie" zostanie wydane ponownie, pierwsze urządzenie ponownie odpowie - i tak w nieskończoność. Urządzenia zawsze reagują w tej samej kolejności. Kolejność odpowiedzi oparta jest na identyfikatorach urządzeń na magistrali OneWire. Wydaje się, że jest to wyszukiwanie binarne, zaczynając od najmniej znaczących bitów identyfikatorów urządzeń. Protokół używany do wyszukiwania tych identyfikatorów jest dość złożony i jest opisany na stronach 51-54 dokumentu „Book of iButton Standards”, który jest dokumentem pdf pod adresem https://pdfserv.maximintegrated.com/en/an/AN937.pd …

Przetestowałem ten proces wyszukiwania od 1 do 11 czujników na jednej szynie i stwierdziłem, że kolejność odpowiedzi dla danego zestawu urządzeń była zawsze taka sama, ale gdy dodałem nowe urządzenie na końcu szyny, nie było mowy Mogłem przewidzieć, gdzie w kolejności wyszukiwania się pojawi. Na przykład 11 czujnik, który dodałem, znalazł się na pozycji nr 5; a pierwszy czujnik, który założyłem do autobusu, był ostatnim w kolejności wyszukiwania.

W tym projekcie z dwoma czujnikami, jeden z nich jest przylutowany w module RTC; drugi jest podłączony za pomocą męskiego złącza na płycie i żeńskiego złącza na kablu. Można go łatwo odłączyć.

Gdy czujnik na kablu (czujnik „out”) jest odłączony, polecenie „szukaj” powoduje naprzemienne pojawienie się „PRAWDA” i powrotu „FAŁSZ”.

Gdy czujnik na kablu jest podłączony, polecenie „szukaj” tworzy 3-stopniowy cykl, z dwoma powrotami „PRAWDA” i jednym „FAŁSZ”.

Moja procedura polega na wydaniu 1, 2 lub 3 poleceń „wyszukaj”, dopóki nie zostanie zwrócony wynik FAŁSZ. Następnie wydaję jeszcze 2 polecenia "szukaj". Jeśli zawiedzie drugi (czyli FAŁSZ) to wiem, że w autobusie jest tylko jeden czujnik i że jest to czujnik "in". Tożsamość urządzenia jest rejestrowana i przypisywana do czujnika „w”.

W późniejszym czasie, jeśli zarówno pierwszy, jak i drugi zwrot są PRAWDA, wiem, że w autobusie są dwa czujniki. Sprawdzam, który z nich ma tożsamość równą czujnikowi "w", a drugi przeznaczam jako czujnik "na zewnątrz".

Inną drobną kwestią jest to, że zbieranie wyników z dwóch czujników odbywa się poprzez wysłanie polecenia „rozpocznij konwersję” za pomocą polecenia „pomiń ROM”. Mamy możliwość wysyłania komend do pojedynczego urządzenia (przy użyciu jego unikalnego identyfikatora) lub do wszystkich urządzeń na magistrali (pomiń ROM). Kod wygląda tak:

ds.reset(); //

// wyślij polecenie "pomiń ROM" (aby następne polecenie działało w obu czujnikach) ds.write(0xCC); // Pomiń polecenie ROM ds.write(0x44, 0); // rozpocznij konwersję w obu sondach stan_temperatury = wait_convert; // przejdź do stanu opóźnienia

Po upływie wymaganego czasu opóźnienia temperatury są odbierane z każdego czujnika indywidualnie. Oto kod drugiego czujnika (czyli czujnika OUT).

jeśli (flaga2) {

obecny = ds.reset(); ds.select(DS18B20_addr_out); ds.write(0xBE); // Odczytaj Scratchpad z sondy "out" data[0] = ds.read(); dane[1] = ds.odczyt(); temperatura_wyj = (dane[1] << 8) + dane[0]; temperatura_wyj = (6 * temperatura_wyj) + temperatura_wyj / 4; // pomnóż przez 6.25 } else { // not flag2 - tzn. czujnik wyj. nie podłączony temperature_out = 30000; // naprawa na 300,00 C jeśli czujnik temp nie działa } // koniec if (flaga2)

Opracowałem większość tego oprogramowania w samodzielnym szkicu, który zawierał tylko czujniki temperatury, bez komplikacji związanych z obsługą LCD, RTC i kart SD. Ten szkic rozwojowy znajduje się w poniższym pliku.

Krok 3: Wstępne wyniki

Ten wykres jest kombinacją pierwszych dwóch niepełnych dni czytania.