decoding wireless thermo ASK signal

A weekend project

I happen to have an old and reliable (!) wireless temperature station with alarm clock functionality operating in an ISM band at about 433Mhz. The main unit has in capital letters "DENVER" printed on it but no model name anywhere. (Even after opening the casing I could not find any markings which could be used in google searching)

The company still produces similar gadgets (http://www.denver-electronics.com) and I think that the current models like DENVER TRC-1480 can be seen as a grand-grand-grand son of my unit :)

Features:

- up to two wireless temperature sensors (I've got just one)
- temperature sensor inside the main (indoor temp) unit with C and F conversion capability and memory option about min and max temp within some time (72h perhaps?) window.
- digital alarm clock with really annoying beeping sound ;) (never used)
- long battery life (batt replacement occures so seldom I cannot even recall how often in general. once per 2 years perhaps?)

Preparations

By tuning the an SDR to 433 Mhz and warming the outdoor unit's thermistor a bit between fingers I received loud and clear signal at 433.92 Mhz. To aqcuire the session samples to decode later I captured four radio transmissions (I was still warming the thermistor) and noted down the temperature readings on main unit. How? I just recorded with gqrx the entire bandwidth the RTL-SDR dongle was set to operate on (in this case 1.5 MHz) - quick and dirty but worked fine for this purpose).

To be able to start guessing about the data coding methods used, I had to zoom in to the demodulated (audio) waveform. This is OK since the high rates (48000 Hz) of audio sampling and relativey slow datarate of the device.

As (AM) demodulation was done by gqrx already I just had to record the audio-sample (note the record button on the right pane)

Waveform analysis

From the waveform it is visible that a RZ coding is used. The pulse indicates a start of the next bit and the length of the pause between pulses indicates either the bit is 0 or 1. If the pause is longer (approx 4 x 1) then it signals the end of current message. (reading direction: LTR)

(click here to listen to the recorded sample. it's in FLAC encoding.)

The payload consists of 24 bits. First byte indicates the sensor ID, second byte is the full decimal of the temperature measured (in Celsius) while the last byte's lower nibble indicates what's behind the comma. 

For example: 10000011 00011001 10001000 translates to (according to my interpretation): The latest temperature measurement by sensor with ID= 10000011 is 25.8 degrees in Celsius. (And besides, sensor's battery is OK)

The message is repeated 24 times within a single transmission which is in total about 2.09 seconds long.

Data processing

Audacity has a nice feature of exporting the sampled data to a txt/csv file so I just had to do a trivial (!) textfile processing to get the desired bitstring. No need to process the structred audiofile (wav for example) via custom (python) scripts. Nice.

Tip: From audacity, on selected portion of the waveform, choose from menu: Analyze -> Sample Data Export... and now tune the selections to your taste. I selected 'all headers' and 'indexed sample format' options. 

I must admit that the offline signal processing was a lot easier than I'd expected thus given the right tools and appropriate hints it should'nt be a problem for anyone.

The exportfile (pure ASCII text) has a very easy format:

A sample sequence number, tabulator character ('/t'), sample value in dB notation and newline character ('/n'). Armed with some scripting skills, it's easy to count, sum, detect etc. the dynamics of measured values and finally reach the goal by getting an easily readable/comparable bitstream.

Perhaps some additional notes to be added later...

  

discovering OBD-II

Every modern car has a diagnostic port called OBD-II (On-Board Diagnostics ver. 2) which enables external devices to communicate with the ECU - the brain of the car.

Well, if your vehicle is brand-new there is no real reason to peek under the hood but if it's a second-hand then one should be prepared to encounter all sort of problems used cars might run into... with the help of live data and logged failure codes the reparation just got a small step easier.

On eBay you can find cheap bluetooth OBD-II adapter (like the ELM327) that make a perfect match with any smart-phone with proper software installed on it.

I have an Android phone and there are quite many applications just for this purpose. Most notable perhaps is the Torque by Ian Hawkins.

As modern phones have an impressive assortment of on-board sensors, it makes it a perfect drive-computer and allows all sorts of analysis be made in real time and later on, based on collected data.


Just to name a few:

- engine load (%)
- turbo pressure (kPa)
- in-take air pressure and temp

- fuel consumption (l/100 km)
- speed by ECU
- throttle position

- acceleration
- speed, direction and position (GPS)

Software on a smart-phone nicely bundles it all together and is capable of keeping a log file with for example 1 second interval.

investigating the sdr world

Gqrx tuned to local FM station at 100.0 MHz

Hardware

The RTL2832U based SDR is a very capable little gadget that anyone can set up without having to spend too much on dedicated hardware.

I got mine ("mini digital TV stick" as written on the package) from eBay for about £15. It's yet another no-name USB DVB-T dongle with just suitable hardware combination inside.

Basically it captures raw RF packets and let's the PC software to decode/demodulate those. Thus exactly what an SDR does! Still, it's a hack since some undocumented chip features are used to make it behave like one. Great thanks to Antti Palosaari for discovering this! More on that subject can be read here.

Software

Firstly, I consider only Linux here and all my suggestions are based on that.

Depending on your operating system the support out-of-the-box varies a bit but there is nothing too serious to build all the necessary tools from tarball.

Seems that setting the system up on OpenSuse 12.1 means bit more work than on Ubuntu for example since one has to build some system packages to meet the GNU Radio dependencies that have not yet reached to the official repositories.

Waterfall shows some sensor activity

For beginning the Qt based gqrx application is really neat and as many instructions on the net I also suggest starting from this.

Later on you will find yourself discovering the gnuradio-companion IDE with a certain amazement bout how truly complex and fun the SDR world really is!

As the Elonics E4000 tuner can be  tuned from 52 MHz - 2.194 GHz it really opens up the radio spectrum for any hobbyist like me never minding the 161 Mhz band-gap starting from 1.098 GHz

Applications

After having scanned the radio spectrum over and over I started to wonder what else can be done with it. And thus I decided to try to decode the wireless thermo RF ASK modulated messages captured from the air.

Work in progress...

measuring energy consumption

1. Theory of operation

The energy meter used in our house is a Siemens ZMD120AMtr53 which capable of measuring 3x230/400V (e.g. industrial power) electricity consumption in preprogrammed day and night shift. The energy company charges less for nighttime usage (EUR 0.08 cents) and considerably more during daytime use (0.14 cents)

The meter has three ways of communicating it's readings to interested users:

•  dedicated DLMS port for programming and data readouts;
•  IR test diode pulses (each 0.2 ms long) with a rate of 10000 = 1 kWh;
•  via on-board LCD "graph" (regular users, simple inspection)

The formula for calculating present power consumption via short pulsing IR light is brought by the data sheet:

Example: Meter constant R = 1000
Power P = 36 kW
f-LED = R x P / 3600 = 1000 x 36 / 3600 = 10 imp/s

In my case, the meter was programmed to have the constant 10 times bigger to achieve more precise readings. Thus, once you have an impulse count in seconds, it's easy to calculate real-time power usage.

2. Selecting an IR sensor

A sample graph for 12h power consumption with RRD

There are several ways to detect IR radiation. Though some detectors might not be as suitable as others thus some consideration has to be made. Firstly, how far would you place the micro-controller? If the wiring will be considerably long (> 10 meters) it would be a good idea to use a sensor with an in-built OP amplifier to get a strong signal over the long wires. That's how I saw it and therefore a sensor TSL262R was chosen. If I would have planned to put the controller inside the same metal box where the meter was located, perhaps a simple IR photo resistor would have done the same good job.

3. Building a prototype

Prototyping is fun! Although I googled for some samples of other fine projects I came up with a more simple and straightforward solution. Firstly, as I formulated the problem very precisely, I ended up getting exactly what I needed. No additional calculations were expected from my 8-bit AVR microcontroller. It's quite the opposite I saw around. Thus I really count pulses and deliver the pulse count in selected timeframe to a logfile.

From software perspective, the key is utilizing the power of AVR chip's interrupts thus leaving more room for other interesting tasks.

volatile long pulseCount = 0;

// interrupt attached to IRQ 1 = pin3
attachInterrupt(1, onPulse, RISING);

and the function to perform is simply

void onPulse() {
 pulseCount++;
}