W poprzednim wpisie opisałem łamanie protokołu termometru ThermoPro TP-08. W tym umieszczam kawałek kodu, pozwalający skorzystać ze zdobytej wiedzy!

Kod wypróbowałem z odbiornikiem MX-RM-5V, który jest naprawdę słaby, zasięg całości w pomieszczeniu to ledwie kilka metrów, myślę że odbiornik superheterodynowy sprawdził by się lepiej (sprawdzę jak tylko listonosz przyniesie).

Oto schemat podłączenia do Arduino nano:

Antena o długości ok 170mm jest konieczna.

Kod korzysta z biblioteki TimerOne, odpowiedzialnej za generowanie przerwań z timera1.

Dane przesyłane są do terminala w następującym formacie:

Temp1: 20.70; Temp2: 20.40
Temp1: 20.60; Temp2: 20.40
Temp1: 20.70; Temp2: 20.40
Temp1: 20.60; Temp2: 20.40
Temp1: 20.70; Temp2: 20.40

Aby z nich wygodnie skorzystać, użyłem terminala RealTerm z opcją logowania do pliku wraz ze znacznikiem czasu, następnie dane wyeksportowałem do Excela i utworzyłem wykres temperatury w funkcji czasu dla przebiegu zacierania mojego Oatmeal Stouta:

I to by było na tyle dzisiaj!

Tymczasem!

Skomentuj!

Dzisiaj wpadł mi w ręce termometr ThermoPro TP-08, to bardzo fajne narzędzie z dwoma sondami pomiarowymi oraz co najciekawsze – przesyłaniem mierzonych temperatur z czujnika do “bazy” za pośrednictwem sygnału radiowego 433 MHz.

Niestety baza nie ma ani możliwości podłączenia do komputera ani innego logowania danych, co jest niezmiernie bolesne kiedy uwielbia się różnego rodzaju wykresy, logi itp. Z tego powodu postanowiłem dobrać się do danych wykorzystując dodatkowy odbiornik na 433 MHz, aby to zrobić musiałem poznać protokół komunikacyjny jakim posługuje się termometr i o tym będzie dzisiejszy wpis.

Zacząłem od pozyskania danych do analizy. Większość tanich urządzeń działających na 433MHz działa w modulacji OOK czyli ON – OFF Keying najprostszej z możliwych modulacji polegającej po prostu na włączaniu i wyłączaniu fali nośnej. Odbiornik ma jedną linię “data” która w zależności od tego czy w danym momencie nadawana jest nośna, znajduje się w stanie wysokim bądź niskim.

Jest wiele sposobów na podejrzenie danych do analizy, można to zrobić za pomocą odbiornika SDR, taniego odbiornika 433 MHz podłączonego do karty dźwiękowej itp. Ja skorzystałem z analizatora stanów logicznych, który kupiłem kiedyś z myślą, że może się kiedyś przydać (w końcu się przydał!). Jako software użyłem sigroka z PulseView.

Do analizatora podłączyłem najtańszy, parszywej jakości odbiornik MX-RM-5V, który akurat w tym zastosowaniu spisał się wyśmienicie. Podłączyłem sondę temperatury do jednego wejścia termometru i uruchomiłem PulseView.

Jak widać pulsogram (chrome podświetla uparcie słowo “pulsogram” na czerwono, czyli pewnie takie nie istnieje) jest bardzo czytelny, widać preambułę, składającą się z bardzo krótkiego impulsu i następującej po nim dłuższej przerwy. Następnie przesyłane są trzykrotnie te same dane oddzielone dłuższą przerwą.

Po przybliżeniu łatwo zorientować się jak są zakodowane bity:

Stan wysoki ma zawsze ~500 us i oddziela krótkie (500us) lub długie (1500us) przedziały stanu niskiego. Przyjąłem jak się później okazało całkiem słusznie, że krótsze niskie impulsy to “1” a dłuższe to “0”. Mając tą wiedzę zabrałem się do transkrypcji pulsogramów na zapis zerojedynkowy. Zrobiłem kilka różnych pomiarów dla różnych temperatur – im więcej danych tym lepiej, przynajmniej do pewnego momentu.

I wygląda to tak:

Na pierwszy rzut oka widać, że pierwszy bajt, jest zawsze niezmienny, kierując się wrodzoną intuicją, uznałem go za adres urządzenia nadawczego. Drugi bajt zmienia się. trzeci i czwarty pozostają niezmienne. A piąty znowu się zmienia, ale piąty bajt jako że jest na końcu uznałem za jakąś sumę kontrolną i postanowiłem skupić się na początku na trzech środkowych bajtach.

Najpierw sprawdziłem czy jest jakaś korelacja między drugim bajtem a temperaturą wskazywaną przez termometr:

10000110 = 134 // 19st
10001100 = 140 // 20st
10011011 = 100 // 21st
10100010 = 155 // 22st
10110101 = 181 // 24

No i widać że im wyższa temperatura tym drugi bajt ma większą wartość. Na razie jest nieźle.

Termometr obsługuje temperatury od 0 do 300 stopni z rozdzielczością jednego stopnia, to się oczywiście w jednym bajcie nie zmieści, pora odkryć który bajt to dalsza część danych. Odłączyłem sondę od wejścia nr 1 i podłączyłem do wejścia 2:

01010011 10000110 00011101 01001000 00111011 // 19st - podłączony tylko pierwszy termometr
01010011 01001000 11010001 10000110 11011011 // 19st - podłączony tylko drugi termometr

Teraz widać, że miejscami zamieniły się bajt drugi z czwartym oraz pierwsza połowa trzeciego bajtu zamieniła się z drugą jego połową!

Temperatury, które zmierzyłem zbierając dane do analizy niewiele się od siebie różniły (19 – 24 st dla termometru o skali do 300 stopni) a pierwsza połowa trzeciego bajtu jest niezmienna dla wszystkich pomiarów uznałem więc, że to raczej będą najstarsze bity 12 bitowej liczby oznaczającej temperaturę:

000110000110 = 390 // 19st
000110001100 = 396 // 20st
000110011011 = 411 // 21st
000110100010 = 418 // 22st
000110110101 = 437 // 24

Tutaj zajęło mi chwilę wpatrywanie siew te liczby, dzieliłem je przez siebie, mnożyłem przez siebie szukając rozwiązania aż w końcu znalazłem!

390 / 10 - 20 = 19   // 19st
396 / 10 - 20 = 19,6 // 20st
411 / 10 - 20 = 21,1 // 21st
418 / 10 - 20 = 21,8 // 22st
437 / 10 - 20 = 23,7 // 24

Wygląda przekonująco 🙂 Wygląda na to, że nie tylko wiem już kal odczytać temperatury, to jeszcze przesyłane są one z większą rozdzielczością, niż można się było spodziewać – oryginalny odbiornik ma rozdzielczość jednego stopnia C.

Oczywiście to nie wszystko. Nadal nie sprawdziłem, czy pierwszy bajt to rzeczywiście adres urządzenia, nie rozszyfrowałem też jak wyliczana jest suma kontrolna w piątym bajcie (jeśli to rzeczywiście suma kontrolna). Próbowałem chwilę różnymi popularnymi algorytmami wyliczania tej sumy ale mi się nie udało. Na szczęście do zwykłego sniffowania przesyłania danych nie jest to potrzebne!

Tymczasem!

[Tutaj kolejna część zawierająca kod arduino do odbioru danych]

Skomentuj!