help decode 433Mhz wireless temperature sender

Forum 2005-2010 (read only) Hardware Interfacing
1

I have one of these temperature sensors that sends the temperature wirelessly to a main station

I have been trying to read the sent temperature using the Practical Arduino weather station example with no success.

I then decided to make a recording of the signal to see what the sensor is sending, here is the result:

This is saved as a WAV file, here is how I got it: http://davehouston.org/learn.htm

Is there a way to see what this means? Somehow to convert this into HEX values?

What is needed to read this protocol and adjust the Practical Arduino weather station sample to read this data?

Thanks

2

The first thing to notice on that chart is the actual voltage values. The Arduino is not going to like those negative voltages.

The second thing to notice is that there is no horizontal scale identification. Are those pulses 20 nanoseconds apart or two weeks?

The third thing you would need to know is what was being transmitted during that measurement period. Is that temperature data only? Temp and humidity? What was the temperature?

3

I got the sensor from ebay, it has Weather Station (transmitter) Model "WH3" on the back, not a particularly famous brand "SmartWeather"

http://cgi.ebay.com/Wireless-Outdoor-Temperature-Sensor-Weather-Station-/270655788238?pt=LH_DefaultDomain_0&hash=item3f045794ce#ht_3749wt_1139

The signal was recorded at edit: 44100Khz with audio card and the visualization is indeed using Audacity

4

counting the dips = 48 = 6 * 8 => think 6 bytes
looking at the dips I can see short ones and long ones

The big assumption show! :slight_smile:

suppose shorts are 1 and long are 0

BIN : 11111111 01001011 01010000 10001010 11111111 01010111 (check this)
HEX : 0xFF     0X4B     0x50     0x8A     0xFF     0x57
DEC : 255      75       80       138      255      87
ASC :   ?

Notice 2 bytes of 0xFF, think these are markers or separators to get the receiver in sync or so.

leaving 2 values { 75-80-138 } and { 87 }

assumption 1: the single byte is humidity - 87% would be a nice reading

assumption 2: the triplet is the temperature, three values 2 with first bit 0 and 1 with first bit set

assumption 3: The one with the first bit set is the fraction part and the other 2 are the decimal part.

So we have { 75, 80 } . {138}
If we "remove" the decimal point bit we are left with {75, 80} . {10} But I have no idea what value was on the receiver or how to translate it further......

can you confirm any of this?

5

Thanks,

The sensor makes up random sensor ID value when powered up that is included in the transmitted code
http://forums.adafruit.com/viewtopic.php?f=8&t=16344

I suspect that the graph i see is inverted, so I will try that as well.

Also, probably the most significant bit of the temperature is reserved for negative values.

silly from me, i didn't write up the values reading on the screen when recording the signal.. but I recall it was something around 10-14 degrees Centigrade as I just brought it indoors. will repeat that later.

This sensor only sends temperature. I suspect the last byte is a CRC

Thanks again

6

OK, as promised here is how 24.0 degrees C gets coded:

Note the timing scale.

I have two challenges

  1. Capturing this with Arduino
  2. Decoding it
7

try sampling more values, with double figures or triple, e.g.
22.0
20.2
22.2

This would make it easier to figure out a pettern.

My Oregon Scientific temperature sensor gives this signal for 30.0 °C:

But I don't think your sensor uses same coding: manchester coding can be quickly indetified as you never see three consecutive identical figures (111, or 000), while your picture appears to be something like:
01101101101101101101101100011011000110001101100011011011011011000110001100011000110001100011011011011011000110001100011000

Bold sequences (I didn't highlight them all) can't exist in manchester coding, made of sequences of "01" and "01".

Anyway, looking at your two images, I think I can see the "preamble", used to "tune up" the receiver, the same in both images:
01101101101101101101101100011011000110001101100011011011011011000

Maybe you can find some tips here:

http://alyer.frihost.net/thn128decoding.htm

We're also discussing this topic in this thread:
http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1289953701/30