A log of random stuff that interests me.

Decoding the Oregon Scientific Remote Weather Temperature Sensor

A while ago, I bought a set of Oregon Scientific weather station on special. The package came with the clock and temperature display unit (BAR283) and a remote temperature sensor (RTHR328N), which is normally put outside of the house. The remote sensor then regularly sends temperature and humidity wirelessly to the display indoors. It has been a dream of mine to tap into the temperature data sent over the air and log it in database. Fortunately, there are a few tutorials online (jeelabsinstructables) online and blog posts of people who have done the exact thing successfully.

To receive the signal, you need a Amplitude-shift keying (ASK) 433.92MHz receiver. I bought the Aurel AC-RX2 on advice of one the blog posts, but in reality, there are probably better 433.92 receivers such as the RXB6 as documented here.

To get the best reception, you need an antenna. I used a 17.2cm wire for the antenna. The full wire up of the Arduino and AC-RX2 is shown below:

Breadboard diagram

Data is connected to Pin 2.

I downloaded the source code and loaded onto my Arduino, unfortunately, nothing came out of the console. Changing pins and rewiring didn’t yield anything useful – It just would not work. The source code was not straightforward to understand and it wasn’t like I could just add breakpoints and step through the code. That’s when I decided that I needed to start from scratch. Fortunately, the Oregon Scientific protocol is quite well documented here.

The first thing I decided to do was to make sure that data is actually coming through to the output pin. I attached a USB logic analyser and used PulseView to see if there were any data coming through. Sure enough there was, but there were a lot of data which meant nothing to me. Removing the antenna, that was a lot less data coming through, which proved that everything was hooked up correctly.

In the protocol, there were some samples of what the signal should look like. It was a Manchester encoded signal on a 1024Hz clock. The other consideration was that the sensor was not sending data all the time, but only at certain intervals. Know the exact moment that data was sent would be key to identifying the signal. Fortunately, there was a clue in the form of an LED that would blink.

The blink would come every 106 seconds and sure enough, I got a very distinct signal when it blinked. The pattern of the signal was definitely artificial and not random.

Oregon Scientific RF Signal

Decoding the Manchester encoded signal

The signal is in Manchester coding with a clock of 1kHz. This means that sampling the state every 1ms should give us a stream of bits of the transmission. Unfortunately this naive approach is error prone due to slight variations in sampling time and signal. If sampling becomes offset then errors will accumulate.

Oregon Scientific 1kHz signal

A better approach is to look at the timings of a the HIGH and LOWs and classifying each HIGH and LOW into short and long pulses. Because the signal is Manchester coded, the signal should oscillate between HIGH and LOW at least every 1ms. A long pulse should not be longer than 1ms. and a short pulse should be around 0.5ms.

However, as mentioned above, these timings can have slight variations. Therefore, we should allow for some leeway for long and short pulses.

Now that we have identified HIGHs and LOWs, long and short pulse, we need to convert them into a bit stream.

The logic I came up with is quite simple:

A HIGH long pulse is basically a 0 followed by 1

A LOW long pulse then a HIGH short pulse is 0

A LOW short pulse then a HIGH short pulse should repeat the previous bit

Oregon Scientific Protocol

Oregon Scientific Protocol 2 actually sends each bit in pairs, the inverse of the bit and then the actual bit. We only need to look at every second bit. To identify a valid signal, we look for the preamble and the sync, which is 16 1 bits followed by 0101. After finding this pattern, we then convert the rest of the bitstream into BCD to get the textual representation. The nibble format is LSB first.

Few questions:
You coded an interrupt pin and ISr that are not used : any specific reason?
I would like to have humidity values: is the message fully decoded?
I’ve almost always a checksum error: is it a real error?

That’s actually a good question about the interrupt. It’s been a while since I did this code, but the general idea was that the interrupt actually interrupts a sleep that I had in the loop, but evidently, for whatever reason I didn’t actually have a sleep or delay in the loop, so it can probably be removed.

Regarding humidity, my remote sensor doesn’t report humidity. If yours does, then it would probably be in the message after the temperature octets, where I’m currently assuming is the checksum – which would explain your checksum errors. See if the checksum it was expecting is the humidity value? Adding humidity should be fairly easy. Just reference the protocol documentation linked in the blog post to find out the exact message format.

The “01010101010101010101010101100110011001100110100101011001010101101001101001100110010101011001101010101010011010101001011010101010101010010110100110100101100101011” looks like a DCF77 signal. Google it.