Decoding data of Oregon Scientific
radio frequency sensors
by the example of THN128 sensor.

Wireless weather sensors have many known advantages. Ordinary they are used with autonomic weather stations.

Communication is based on internal protocol which is not publishing by manufacturers.
This article describes how to decode radio-frequency (RF) packets from Oregon Scientific sensors and use them in your own applications (home automation task, weather monitoring etc).

Example is given for THN128 OS sensor that I used but searching minds can apply the obtained information for other sensors.

First of all we need a hardware that is compatible with OS sensors. Almost all known for me OS sensors working with ASK modulation type at 433.92 MHz frequency.

Laipac Technology, Inc makes RLP434A receiver that is excellent suitable for our task.

Next, we need to log the received signal to have the ability to decode it. If you have not an expensive digital oscilloscope you can use your PC soundcard with some sound editor (Sound Forge for example). Just plug the output of RF receiver module via resistive divider to Line-In of your sound card and capture RF packets (they are sending approx. in 30 seconds).   When all described above are done you are ready for decoding procedure.   Let’s take for example a real captured datagram shown on Figure.1.  

Figure 1.  
As we can see the THN128 RF packet consists of following parts:

 - Preamble (this part consist no useful information and used for RF receiver tuning);
- Synchronization bits;
- Three information’s bytes;
- One byte of CRC;

The bytes are sending in reverse order and they are coded in a Manchester-type manner. I think that explanations given at Figure 1 are well enough for understanding that

 Next step is the determination what the information each bit is carry on.

First of all let’s write the received bits in a normal binary mode.

So we have:
 - Byte #1: 00100011;
 - Byte #2: 01110000;
 - Byte #3: 00000001;
 - Byte #4 (CRC): 10010100.

Table 1 gives a detailed description of bits representations.

Where:

CH – Channel number 0 is 1st channel, 1 is 2nd channel and 2 is 3d channel used to send information.

TH1 – First digit of temperature represented in a BCD mode.

TH2 – Second digit of temperature represented in a BCD mode.

TH3 – Third digit of temperature (after decimal point) represented in a BCD mode.

BAT – Sensor battery status bit 0-good, 1- battery need a replacement;

H – Unknown bit when equal to 1 the receiver MTR102 shows HH.H values (may be used for sensor failure indications);

SIGN – The sign of temperature, 0 – positive temperature, 1- negative temperature.  

So following by described above information we can determinate that RF packet shown at Fig. 1 is representing the next information: 

Sensor THN128 uses channel #1.
Temperature is +17.0 degrees of Celsius.
Battery status is good. 

 At last step we need to find out how CRC is calculated.

It’s easy to see that CRC byte is just the algebraic sum of three information bytes (CRC=Byte1+Byte2+Byte3). Overflowed bits are escaped.

NB!
In practice sometimes the received CRC is the sum with overflowed bit (especially when works at 3d channel).
That's why I am using both checksum calculation with and without 9th bit. (see sources for details)

I hope that this article will very useful for those who want to use OS RF sensors in your own hobby projects.

NEW! Currently I am shared the sources and firmware for the receiver and you can view it at following link at Google project hosting.

This project includes receiver and decoder parts for Oregon Scientific wireless sensor THN128. The signal  transmitted by THN128 is receipted with RLP434A 433.92MHz ASK receiver that is connected to INT1 pin of ATmega16 MCU.

Then signal is decoded using Manchester data coding scheme and printed via UART (RS-232 if MAX232 IC is connected). So it is simple 433.92Mhz to RS-232 converter for Oregon Scientific THN128 sensor.

The schematics of RLP434A connection is very similar with the one used in my Embedded Web Server project.

It looks like this (click to enlarge):

The only difference is that it use ATmega16 instead of ATmega32 and you don't need to install J3 and J4 connectors.

The presented software is written with plain C language in IAR5.11b compiler. But I think that it is easy to modify sources for GCC or other compilers.

If you are interested the project I have done or have a questions then feel free to e-mail me!

© Alexander Yerezeyev 17/01/2008

http://alyer.frihost.net

E-mail:

Last modified:18.03.2009 10:10:30 +0300.