calibrating an rtl-sdr with PMR

The cheapness of the dvb-t style SDR comes with a price of it's own - an internal oscillator has not the highest possible precision and it's oscillating frequency tends to float a bit as the device gets warmer during an operation.

Thankfully there are ways to somewhat mitigate this issue in SDR software by setting the crystal's ppm offset. But how to determine the required value? Well, by comparing the SDR capture to something own like the PMR frequencies.
Via this simple method I found out the the freq. correction value for my dongle: -107 ppm.

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...

  

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...