Czujniki, pomiary, przekazywanie informacji czyli małe, ale ważne szczegóły
Jak zawsze przypominam o poprzednich częściach, jeśli ktoś jeszcze nie czytał – tutaj.
W tej części zajmę się pomiarami, wysyłaniem ich wartości, a także opowiem o tym, jak rozwija się moja szklarnia.
Temat pomiarów jest, moim zdaniem, trochę zaniedbany w poradnikach. Często opis zawiera tylko instrukcję podłączenia czujnika oraz sposób odczytywania danych. Rzeczywistość pokazuje, że dokonywanie pomiarów stwarza więcej problemów, niż zakładają popularne poradniki.
Zacznę jednak od swojego przykładu. Zobaczcie, jakie zmiany zaszły w moim projekcie.
Zainstalowałem oświetlenie
Elektronika szklarni została obudowana, pojawiły się gniazda i wtyczki, aby wszystko można było łatwo łączyć. Zamontowałem też płytę z pierwszymi elementami.
Gwiazdy wpisu czyli czujniki
Czujniki wilgoci i temperatury są montowane do obudowy szklarni na taśmie dwustronnej z goldpinami, do których przygotowałem sobie wtyczki
Pomiar naświetlenia znajduje się na zewnątrz (fotorezystor w dzielniku napięć)
Przy wyborze czujnika warto dokładnie przeczytać notę katalogową przed dokonaniem zakupu. Należy zwrócić uwagę na sposób jego montażu. Odpowiednio od sytuacji wybieramy produkt zadowalający nas stosunkiem ceny do jakości, np. tak popularny DHT-11 jest moim zdaniem złym wyborem – czujnik dokonuje niedokładnego pomiaru wilgotności powietrza, a przy tym jest stosunkowo drogi.
Kolejny czujnik, przed którym chciałem ostrzec, to ten do pomiaru wilgotności gleby. Po kilku tygodniach w ziemi jego poszczególne elementy ulegają destrukcji. Niestety była to moja wina, z tym czujnikiem trzeba ostrożnie i nie zbierać pomiaru co sekundę, bo każdorazowy pomiar wywołuje reakcję elektrolizy. Kiedy będziemy z niego korzystać rozważnie posłuży długo.
W przypadku większości popularnych czujników łatwo znaleźć biblioteki z bardzo dobrymi instrukcjami. Podam tu przykład termometru DS18B20, jest tani i z zadowalająca dokładnością dokonuje pomiarów; tu znajdziecie opis, jak z niego korzystać.
Dużo tego rodzaju instrukcji znajdziecie w sieci i z pewnością uda wam się podłączyć czujnik i odczytać jego pomiar. Jeśli napotkacie jakieś problemy z tym związane, piszcie (;
Teraz nadszedł moment, w którym możemy składać nasze urządzenia w całość z uwzględnieniem kilku ważnych szczegółów.
Często pojawiającym się problemem są przekłamane pomiary, których oznaką jest występowanie pomiarów znacznie odbiegających wartością od normy. Powodem tego rodzaju przekłamań może być wiele: problemy z samym czujnikiem, problemy ze sterownikiem itd. Co wtedy robić?
Rozwiązań jest kilka. Można zacząć od porównania ostatnio zmierzonej wartości z gradientem przyrostu i spadku poprzednich pomiarów. Jeśli występują duże rozbieżności, a wiemy, że warunki otoczenia (temperatura, wilgotność) nie uległy drastycznej zmianie, należy pominąć kwestionowany pomiar. Przy okazji, warto zapisywać, jak często pojawiają się tego rodzaju anomalie. Jeśli będą one występować często należy zgłosić błąd lub przyjąć, że faktycznie doszło do drastycznej zmiany warunków otoczenia. W szklarni dobrym rozwiązaniem jest zastosowanie pomiaru oświetlenia, które może się przecież gwałtownie zmienić.
Innym rozwiązaniem jest uznawanie za ostateczny pomiar średniej ważonej pomiarów. Aby zastosować to rozwiązanie, należy ustalić najpierw stałą czasową czyli taki specyficzny odcinek czasu, którym możemy określić, jak szybko układ dochodzi do stanu ustalonego. Polega to na tym, że naszą średnia wartość mnożymy n razy, dodajemy nowy pomiar i dzielimy przez n+1. Im większe n tym owa stała czasowa jest dłuższa. Taki sposób ustalania ostatecznego pomiaru sprawia, że mocno odstający od innych pomiar nie ma dużego wpływu na pozostałe wartości. Jeśli jednak taki anomalny, odchylony od normy pomiar będzie się powtarzał, to zmienią się wartości pomiarów, które wysyłamy.
Reakcja wynikowego pomiaru na gwałtowną zmianę
Obie metody można oczywiście ze sobą łączyć. Warto też pomyśleć o dywersyfikacji urządzeń i wyników ich pomiarów. Na przykład, niektóre warunki otoczenia mogą być mierzone za pomocą różnych urządzeń. Taka redundancja wyników pomiarów jest, w przypadku mojego układu, efektem ubocznym działania niektórych czujników. Czujnik DHT22 poza wilgotnością powietrza mierzy bowiem także temperaturę. Dzięki temu, mogę porównywać wyniki tych pomiarów, z wynikami, jakie odczytuję z czujnika zainstalowanego tylko i wyłącznie na potrzeby pomiaru temperatury (DS18B20). Jeśli wartości pomiarów temperatury z obu urządzeń byłyby znacząco różne to znak, że któreś z urządzeń nie działa poprawnie.
A oto przykład na kodzie z jednym czujnikiem:
#include <OneWire.h>
#include <DS18B20.h>
#define DS18B20_PIN 5
const byte ds18b20Address[8]= {0x28, 0xE3, 0xE2, 0x22, 0x6, 0x0, 0x0, 0x91};
OneWire onewire(DS18B20_PIN);
DS18B20 sensors(&onewire);
float averageTemp;
bool firstLoop;
int error;
int errorCounter_ds18b20;
const int maxErrorCounter = 5;
const int maxDifferenceTemp = 10;
const int timeConstant = 10;
void setup()
{
firstLoop = true;
errorCounter_ds18b20 = 0;
error = 0;
while(!Serial);
Serial.begin(9600);
sensors.begin();
}
void loop()
{
MeasurementTemp();
PrintMeasurements();
firstLoop = false;
delay(2);
}
void MeasurementTemp()
{
float nowTemp;
sensors.request(ds18b20Address);
while (!sensors.available());
nowTemp = sensors.readTemperature(ds18b20Address);
//testowo
Serial.print(” now Temp: „);
Serial.print(nowTemp);
if (firstLoop){
averageTemp = nowTemp;
}else{
averageTemp = (timeConstant * averageTemp + nowTemp) / (timeConstant + 1);
TempTest(nowTemp);
}
}
void PrintMeasurements()
{
Serial.print(” Temp: „);
Serial.print(averageTemp);
Serial.print(” error code: „);
Serial.print(error);
Serial.println();
}
void TempTest(float tempToTest)
{
if (tempToTest != constrain(tempToTest, averageTemp – maxDifferenceTemp, averageTemp + maxDifferenceTemp)){
errorCounter_ds18b20++;
if (errorCounter_ds18b20 > maxErrorCounter){
error = 1;
}
}
}
Pamiętajcie o takich szczegółach jak:
const int maxErrorCounter = 5;
const int maxDifferenceTemp = 10;
const int timeConstant = 10;
Definiujmy takie stałe na początku, aby łatwo edytować zachowanie naszego urządzenia i nie mieć potem linii z tak zwanymi „magic numbers”, do których wrócimy za miesiąc i nie będą one dla nas czytelne.
Dzielimy też kod na osobne metody. Zapisywanie wszystkiego jednym ciągiem z bardzo nieczytelnymi zagnieżdżeniami nie ułatwia pracy. Dobre nazwy i małe metody to dobry nawyk.
Dobrym nawykiem jest także stosowanie nazw zapożyczonych z języka angielskiego.
Teraz trochę o mechanizmach, które są może mniej potrzebne w tym projekcie, ale z pewnością są warte poznania i zastosowania w innych układach.
Jeśli mamy już poprawnie przeprowadzane pomiary, to rzeczą jasną jest, że powinniśmy je w odpowiedni sposób przesyłać. Ja używam UARTa, docelowo przesyłam dane do ESP8266, ale na początek, dzięki wbudowanemu konwerterowi CH340, do komputera. Warto już na tym etapie mieć zaplanowany sposób wykonywania tej komunikacji. Często na początku projektu pomija się temat sumy kontrolnej.
Przykładowy wygląd planu przesyłanych paczek danych (oczywiście „Zawartość” należy rozpisywać dokładniej)
Suma kontrolna to najczęściej kilka bajtów, które dzięki prostej matematyce sprawdzają czy to, co wysłaliśmy, zostało odebrane i nie zostało w żaden sposób przekłamane. Najpopularniejszym systemem sum kontrolnych jest CRC, można o nim poczytać w Wikipedii. Można też stosować na przykład MD5.
Kolejnym dobrym mechanizmem wysyłania danych może być sprawdzanie czy nasza komunikacja działa stabilnie. Po każdej wysłanej paczce można wymieniać informacje, wysyłać potwierdzenie przyjścia czy też nadać paczkom licznik i w ten sposób sprawdzać, czy wymiana danych działa bez przerw. Ciekawym zabiegiem są także „timeouty”, które sprawdzają czy kolejne paczki danych są odbierane w oczekiwanym czasie.
Jak widać po pytaniach publikowanych na forach problemy związane z opisanym tematem pojawiają się często, a sprawa jest dość ważna. Polecam zatem jej nie bagatelizować i solidnie przygotowywać moduły odpowiedzialne za pomiary (;
Jeśli macie jeszcze jakieś pytania lub własne pomysły, piszcie!
Jeśli artykuł w jakiś sposób Tobie pomógł , możesz wpierać blog, aby nowych materiałów przybywało więcej. Zapraszam TUTAJ.
Polecam odwracac kierunek pradu przy pomiarze wilgotnosci. Tak jak przedmowca juz wspomnial lepiej nie miezyc zby czesto ale… Gdy przez metal plynie prad to chroni to przed korozja. Ja uzywam kawalek przewodu elektrycznego 2×1.5 i zasilam z dwoch pinow arduino na zmiane 10 razy. W ten sposob nic nie koroduje.
Dht22 ponoc lepiej zasilac przez 3v3 z powodu samoistnego nagrzewania. Ew. Mozna odlaczac pinem lub tranzystorem.
Pozdrawiam 🙂
Dzięki za pomysły, o tym z DHT nie pomyślałem. Może jak znowu będę w posiadaniu kamerki termowizyjnej to zrobię pomiary żeby zobaczyć czy oddaje coś ciepło.
Co do tych czujników wilgotności to ścieżki miedziane na nich ulegają rozkładowi przez przepływ prądu przez sondy czujnika(ciągły pomiar). Jeśli zasilanie czujnika byłoby załączane przez tranzystor co 10 minut na czas pomiaru to proces niszczenia ścieżek czujnika opóźni się znacznie 🙂
To brzmi jak pomysł! Mam kilka takich, zrobię porównanie zasilanego stale i tylko na pomiar, potem zamieszczę wyniki, dzięki wielkie!