Sunday, January 26, 2014

From remote vacuum cleaner to my weather station

Story started quite differently than you may expect.
My initial plan was not to play with my weather station, but with remote control to my vacuum cleaner :) I have Miele brand vacuum cleaner with remote control buttons located on gripping part of pipe where you usually hold cleaning pipe.

I was trying to reverse engineer that. There were no markings on device about its working frequency so I use cheap DVB-T dongle supported by rtl_sdr libray as my spectrum analyzer and GNU Radio as a frontend. First step is of course to find working frequency. I assumed that it will work on 433MHz or 868MHz or 2.4GHz band. That was easy - I spotted nice signal on 433.82Mhz My initial step was to discover modulation used by this device.

Since this is only home appliance I was not expecting QAM256 :) I focused on trying to get some bit stream by experimenting with ASK,FSK,GMSK. I started with ASK and that was first good shot. In fact my vacum cleaner is using OOK (On Off Keying) modulation which is extreme type of ASK where you switch on/off carrier.

By using GNU Radio FFT and Scope sink with low pass filter I saw that I have regular pulses of something what was interferences from my perspective. You can see this as decaying line close to the right of main signal. It is hard to catch < 1 s pulse..
I knew that this must be some other devices in my vicinity. Since pulses were rare this must be something energy efficient. My first suspects were SMART Water meter with radio transmitter or heat logger mounted on my water powered heaters. Both are made by Ista and have radio interface. They are waiting for my free time to start hacking them :) After some walking over my house with laptop and DVB-T dongle I ruled out both of them, and then I remembered about my weather station since signal was strongest near part of house where it was located.

Some time ago I bought cheap 30 PLN (~7,5 EURO) weather station in Biedronka shop. For those who are not familiar with this name it is a shop network directly competing with Lidl on Polish market. They sell mostly grocery but they have some home cheap china electronic stuff also. Quality is mostly crap but you can find some rare oportunieties..


Remote unit model part number is WS-9941-M. As you can see there is a mark that it is working on  433 MHz band. Clearly it was my source of interference. Unfortunatelly I'm still learning GNURadio and I was able to see data on screen however I was unable to make setup to dump this data to file. I went to my neighbor radio shack shop AVT. It is really neat to have such well stocked electronics shop just 10 minutes bike drive. I bought  ZS-RR10-433MHZ  433.92 MHz radio reciever for 20 PLN (~5 EURO). This is really neat device - you just plug in to power, put some antena and you get demodulated signal on one of the pins.
After connecting Salae Logic Analyzer look what I got:



As you can see there is clearly pattern here. First what you see is sync packet contains three pulses and then delay ~ 9ms.  Then is pattern repeated 10 times. We have pattern here but what exacly "0" and "1" are represented ?


I search web page for any similar devices. Unfortunately there is not many such pages. I found Fred's webpage, and rc-switch Arduino library. I looked into source files and none protocol was similar to mine.

I dumped data from Salae to CSV file and started  write some python stuff that will try to get something from those data.
As you can see this signal have constant high pulse time so no duty modulation was possible. Period is changing and this was the clue. Like in every reverse hack you must start with some assumptions and check if they are wrong or not. I made one that bits are coded with time distance between two rising edges or two falling edges (since high state period is constant). With such assumption and data in csv file i wrote simple python code that will check time between two rising edges and if one is smaller than <VALUE_0> it is one bit, and second time period <VALUE_1> is zero bit. Of course you need some samples with knowledge what is expected to be inside, so I dumped packets for different temperature readings  on my weather display and this is what I got
Temperature (Celsius)Data
18,8 C101001101000000010111100111100000000
20,1 C101001101000000011001001111100000000
20,7 C101001101000000011010000111100000000
Definitely I have data here :) Encoding method assumption seems to be OK. First notice is weird data packet length - 36 Bits. I tought that my encoding is wrong, checked one manually. No errors. Some bits were never changed so I removed them for further analysis and focused on the ones which are changing. My another assumption - data should be contained or aligned within N x bytes. Yeah - maybe this cheap chinese stuff have 4bit MCU ..but lets start with some normal assumptions :) I converted this to decimal format and this is what I got:

Temperature (Celsius)Data
18,8 C188
20,1 C201
20,7 C207

Since such chip devices shouldn't be very efficient with float operations and temperature resolution was 0.1 deg I expected that station will multiply temp value by 10 and this should be value - and assumption was right.

I was happy and started to check my script until i measured first negative temperature. Since we have nice winter in Poland I put weather transmitter outside where it should be and started measurement. It was < -13 C deg and going down. Results were at least weird. Here is what I got with my previous method:
Temperature (Celsius)DataData decimal
-14.1 C101001101000111101110011111100000000115
-14.2 C101001101000111101110010111100000000114
-14.5 C101001101000111101101111111100000000111

I noticed that encoded number is going down along with temperature drop. So what is minimum temperature device can measure so all bits will be zeroes ? Simple extrapolation and result is -25,6 C deg. Now this is very nice and special number for binary system :) So 0 deg will be 256 or "11111111". Simple math and we have formula for negative temperature schema:

Negative TEMP = ( VALUE - 256)/10

Where is "-" mark ? The only difference between negative and positive data are next 4  most significant bits you see on bold in table.

This is python based algorythm for decoding my wireless station data:
def decode(data):
    # convert 36 bits to long integer
    value=int(data,2)
    # remove 12 least significant bits by shifting >> 12
    value=value >> 12
    # remove preambule - only 12 least significant bits are important
    # 0xfff is in binary 111111111111. All other bits will be ignored
    value=value & 0xfff
    # lets check do we have negative temperature by comparing bits 10-12
    # 0xf00 is 111100000000. We are checking value of 3 most significant bits
    # if set to 111 - negative temp. If set 000 - positive
    if (value & 0xe00) == 0xe00:
        # Negative algorythm
        return ((value & 0xff) - 256) / 10.0
    else:
        # Positive temp algorythm
        return (value & 0x1ff)/10.0

Now it is time to make some hardware to receive data from my unit and put them to PC via USB/UART, and put my temp data public. I have some STM32, PIC32, KL25Z,Atmega MCU's laying arround. But this is story for next part.

Update:
Jakub mention in comments that maybe my assuption about positive values is not perfect because that would mean max + temperature is 25.6 C deg. He was right. This is perfect example of working with not sufficient data samples :)
In fact temperature is encoded (probably)  in 12 bits signed format. I tested only up to ~ 40 C deg by warm up sensor above 25,6 C deg. In order to check if bits 10 and 11 also containg temp data I would have to warm up device above 51.2 C deg. :-)  Maximum temperature with 9 bits  would be 51,2 C deg and this comply with sensor range from specification  which is -25 - +50 C de, and I don't need higher values so example above decodes just 9 bits.
I updated python code  

12 comments:

  1. "Some bits were never changed so I removed them for further analysis" - there was another model of similar weather station available at Biedronka - with hygrometer capabilities. I GUESS transmission module and protocol is the same but the sensor is missing, and constant part is just a placeholder for hygro- and maybe barometer data..?

    ReplyDelete
  2. Ha - I didn't know that. Knowing Biedronka this product will be available again in future. They swap shelf content periodicaly. Have to get one with hygrometer.

    ReplyDelete
  3. Why are you think the number is 8-bit and not 12-bit? In 8 bit you can represent 25.5 max temperature which is really low indeed (we often have higher in summer). Change the code to use 12 bit signed values and you'll see -204.8...204.7 possible temperature readouts.

    ReplyDelete
    Replies
    1. @Jakub
      You might be right. I will check by using hot air to warm up sensor. Negative is probably ok since if I assume 12 bit resolution after going below "0" all 4 most significant bits are "1111". On positive range you might be right.
      I will post results when I will check this.

      Delete
    2. I am right. This is ordinary 12-bit signed integer; Please try in python (>=2.6)
      bin(4096-141)
      bin(4096-142)
      bin(4096-145)
      See?

      The code is then:
      def decode(data):
      value=int(data,2)
      value=value >> 12
      return value | 0xfffff000

      or some...

      Delete
    3. Jakub
      You were right. We can treat all 12 bits as signed integer.

      Delete
  4. Hehe:) I've made a mistake :)
    Instead of last line put this:
    return value&0x800? value | 0xfffff000 : value&0xfff

    ReplyDelete
  5. Sorry, couldn't resist to.... :) "just 10 minutes bike drive" -> "It was < -13 C deg and going down." .... :P Nice article, love reverse engineer topic, but got little free time to play with hardware :/ Scope and logic analyser covered with dust. But i need small weather station, so tomorrow Biedronka or Lidl (by foot, to cold for a bike :) ). Thanks again and looking for more :)

    ReplyDelete
  6. Very interesting writeup Spock about the wireless temperature sensor decoding. The extra bits might be address bits to differentiate the correct signal, in case a second sensor is nearby. They all transmit at the same frequency, but with different address (and of course different timing). I have a similar Lidl sensor that has a 3 pos switch in battery compartment. Maybe your has also an switch like this. I may use your findings to decode my sensor in the future. Thanks for sharing

    ReplyDelete
  7. Two's complement encoding of the data so the MSb has negative sign and all other bits have positive sign.

    http://en.wikipedia.org/wiki/Two's_complement

    ReplyDelete
  8. Sounds like the auriol protocol
    http://www.tfd.hu/tfdhu/files/wsprotocol/auriol_protocol_v20.pdf

    Regards,
    Rinie

    ReplyDelete
  9. Great work!! Can't wait for next part.. I've tried in the past to make a similar weather sensor work with my arduino, but no luck at so ever.. Hope you pick the arduino as a receiver ;)

    ReplyDelete

Followers