Go Down

Topic: Help me decode this 434mhz signal...? (Read 29242 times) previous topic - next topic


One thing to consider: if the values sent back are raw data from the two sensors then there is no guarantee that they will have the same bit-order.  Also I suspect the encoder chip used will be a standard part for IR remote controls - this link at ladyada seems worth reading:
[ I will NOT respond to personal messages, I WILL delete them, use the forum please ]


Hi Riva,

Wow, you're on to something.  I never considered the transmitter sending different sensor data each burst, but that makes a lot of sense. Here are some consecutive samples that I took earlier:

Code: [Select]

Reading 1 (93.7F 16%) - 101010110101 000000010000ss
Reading 2 (93.6F 16%) - 101010110101 001101001010ss
Reading 3 (93.6F 16%) - 101010110101 000000010000ss
Reading 4 (93.2F 16%) - 101010110101 001101001000ss
Reading 5 (93.2F 16%) - 101010110101 000000010000ss
Reading 6 (93.2F 16%) - 101010110101 001101001000ss
Reading 7 (93.2F 16%) - 101010110101 000000010000ss

It looks like Reading 2, Reading 4, and Reading 6 all seem to work out with your formula (after converting to C)!  I wonder what reading 1, 3 and 7 mean...  Perhaps "no change" or some sort of ack/ping packet?

I'll go see what happens with bits 8 and 9 with negative C temps.


Jun 26, 2012, 08:39 am Last Edit: Jun 27, 2012, 12:25 pm by Riva Reason: 1
Reading 1,3,5 & 7 are humidity (binary 0010000 = 16 decimal).

I can only assume that as 0.0C = 12 then the unit only reads to -12.0C and not the -20.0C as stated in the manual. It also seems the minimum humidity is 16% and not 20% as stated in the manual.
The interesting one is as below that I can only assume to be battery level of transmitter.
101010110101 0001xxxxxxxxss

***IGNORE THIS The complete breakdown as I see it.
Code: [Select]
101010110101    Preamble
00              ?Possible device ID (when more than one transmitter used)
xx              Control bits to define Data bits meaning. 00=Humidity, 01=?Battery, 10=Temperature
xxxxxxxx        Data bits. For humidity it's the correct value.
               For temperature divide by 10 and add 12 to get Centegrade value.
               For ?Battery unknown.
01              Postamble
Once I almost saw Elvis but then my shovel broke. :(


Hey Riva, here are some negative C temperature values:

Code: [Select]

-14.9C  5.2F 16% h:             101010110101 00 0101011111ss
-15.3C  4.5F 16% h: 101010110101 00 0101011011ss
-15.5C  4.1F 16% h: 101010110101 00 0101011001ss
-13.6C  7.5F 16% h: 101010110101 00 0101101100ss
-13.2C  8.2F 16% h: 101010110101 00 0101110000ss


Hi joshhawk,

I think I really do have it now (honest)

Code: [Select]
101010110101    Preamble
0               ?Unknown. Possible extra data bit OR device ID (when more than one transmitter used)
xxxxxxxxxxx     Data bits.
                If number <=100 then it's humidity.
                If number >=300 then subtract 500 and divide by 10 to get Centegrade temperature,
01              Postamble
Once I almost saw Elvis but then my shovel broke. :(


Hi Riva,

That is exactly the calculation I came up with.  Thank you again so much for all of your help!!

Now I am off to write the arduino sketch to read the packets :-)


So I've written a preliminary sketch (basically just modified "Thermor", someone else's weather station code).  I'm having trouble actually reading the packets - it seems to miss bits or miss entire packets altogether.  Any idea what I could be doing wrong?

Code: [Select]

* Modified from "Thermor" DG950R Weather Station receiver v 0.3
* Receives data from a Weather Station receiver, via
* a 433Mhz RF receiver connected to pin 8 of the arduino, and outputs
* to serial.
* Based on the Practical Arduino Weather Station Receiver project
* (http://www.practicalarduino.com/projects/weather-station-receiver).
* For more info:
* http://kayno.net/2010/01/15/arduino-weather-station-receiver-shield/

#define INPUT_CAPTURE_IS_RISING_EDGE()    ((TCCR1B & _BV(ICES1)) != 0)

#define WEATHER_RX_LED_ON()         ((PORTD &= ~(1<<PORTD6)))
#define WEATHER_RX_LED_OFF()        ((PORTD |=  (1<<PORTD6)))

#define WEATHER_RESET()             { short_count = packet_bit_pointer = long_count = 0; weather_rx_state = RX_STATE_IDLE; current_bit = BIT_ZERO; WEATHER_RX_LED_OFF(); packet_start = false; }

#define TIMER_PERIOD_US             4

// pulse widths. short pulses ~500us, long pulses ~1000us. 50us tolerance

// number of bits in a row before the stream is treated as valid
#define SHORT_COUNT_SYNC_MIN        2
#define LONG_COUNT_SYNC_MIN         2

// states the receiver can be
#define RX_STATE_IDLE               0 // waiting for incoming stream
#define RX_STATE_RECEIVING          1 // receiving valid stream
#define RX_STATE_PACKET_RECEIVED    2 // valid stream received

#define BIT_ZERO                    0
#define BIT_ONE                     1

//byte locations of generic weather data in weather_packet[] array
#define WEATHER_STATION_ID          0
#define WEATHER_PACKET_TYPE         1

//types of packets
#define PACKET_TYPE_HUM             0
#define PACKET_TYPE_TEMP            1

#define DEBUG

// Type aliases for brevity in the actual code
typedef unsigned int       uint; //16bit
typedef signed int         sint; //16bit

uint captured_time;
uint previous_captured_time;
uint captured_period;
uint current_bit;
uint packet_bit_pointer;
uint short_count;
uint long_count;
uint weather_rx_state;

boolean packet_start = false;

// byte arrays used to store incoming weather data
byte weather_packet[(WEATHER_PACKET_BIT_LENGTH)];
byte last_weather_packet[(WEATHER_PACKET_BIT_LENGTH)];

// packet counter - 4 identical packets in a row means the packet is valid
int packet_count = 0;

/* Overflow interrupt vector */
ISR(TIMER1_OVF_vect){                 // here if no input pulse detected

/* ICR interrupt vector */
//void rise() {
  // Immediately grab the current capture time in case it triggers again and
  // overwrites ICR1 with an unexpected new value
  captured_time = ICR1;

  //immediately grab the current capture polarity and reverse it to catch all the subsequent high and low periods coming in
    SET_INPUT_CAPTURE_FALLING_EDGE();      //previous period was low and just transitioned high   
  } else {
    SET_INPUT_CAPTURE_RISING_EDGE();       //previous period was high and transitioned low   

  // calculate the current period just measured, to accompany the polarity now stored
  captured_period = (captured_time - previous_captured_time);

  // Analyse the incoming data stream. If idle, we need to detect the start of an incoming weather packet.
  // Incoming packet starts with a big pulse and the sequence 101010.
  if(weather_rx_state == RX_STATE_IDLE) {
    if(((captured_period >= BIG_PULSE_MIN_WIDTH) && (captured_period <= BIG_PULSE_MAX_WIDTH))) {
      // received a big pulse - indicating the start of a packet
#ifdef DEBUG     
      // Serial.println("packet start");
       packet_start = true;
    } else {

    if(((captured_period >= LONG_PULSE_MIN_WIDTH) && (captured_period <= LONG_PULSE_MAX_WIDTH)) && packet_start) {
      // long pulse, continue counting long pulses
#ifdef DEBUG     
      if (long_count >= 2) { Serial.println(long_count); }
    } else if(((captured_period >= SHORT_PULSE_MIN_WIDTH) && (captured_period <= SHORT_PULSE_MAX_WIDTH)) && packet_start) {
      // long pulse. if there has been enough short pulses beforehand, we have a valid bit stream, else reset and start again
#ifdef DEBUG     
      if (short_count >= 2) { Serial.println(short_count); }
    } else {
      // not a long or short pulse, therefore not a valid bitstream
#ifdef DEBUG     
   //    Serial.println("reset");
    if((short_count >= SHORT_COUNT_SYNC_MIN) && (long_count >= LONG_COUNT_SYNC_MIN)) {
        weather_rx_state = RX_STATE_RECEIVING;
  } else if(weather_rx_state == RX_STATE_RECEIVING) {
    // incoming pulses are a valid bit stream, non manchester encoded.
    if(((captured_period >= SHORT_PULSE_MIN_WIDTH) && (captured_period <= SHORT_PULSE_MAX_WIDTH))) { 
      // short pulse
    //    Serial.print("0");
        weather_packet[packet_bit_pointer] = 0;
     else if(((captured_period >= LONG_PULSE_MIN_WIDTH) && (captured_period <= LONG_PULSE_MAX_WIDTH))) {
      // long pulse
   //   Serial.print("1");     
      weather_packet[packet_bit_pointer] = 1;
    else if(((captured_period >= BIG_PULSE_MIN_WIDTH) && (captured_period <= BIG_PULSE_MAX_WIDTH))) {
     // got another long pulse, which marks a repeat of the bitstream
      weather_rx_state = RX_STATE_PACKET_RECEIVED;
    // check to see if a full packet has been received
/*    if(packet_bit_pointer >= WEATHER_PACKET_BIT_LENGTH) {
    // full packet received, switch state to RX_STATE_PACKET_RECEIVED
      weather_rx_state = RX_STATE_PACKET_RECEIVED;
  // save the current capture data as previous so it can be used for period calculation again next time around
  previous_captured_time = captured_time;

void setup() {
  DDRB = 0x2F;   // B00101111
  DDRB  &= ~(1<<DDB0);    // PBO(ICP1) input
  PORTB &= ~(1<<PORTB0);  // ensure pullup resistor is also disabled
  DDRD  |=  B11000000;    // (1<<PORTD6);   //DDRD  |=  (1<<PORTD7); (example of B prefix)

  //ICNC1: Input Capture Noise Canceler         On, 4 successive equal ICP1 samples required for trigger (4*4uS = 16uS delayed)
  //ICES1: Input Capture Edge Select            1 = rising edge to begin with, input capture will change as required
  //CS12,CS11,CS10   TCNT1 Prescaler set to 0,1,1 see table and notes above
  TCCR1A = B00000000;   //Normal mode of operation, TOP = 0xFFFF, TOV1 Flag Set on MAX
                        //This is supposed to come out of reset as 0x00, but something changed it, I had to zero it again here to make the TOP truly 0xFFFF
  TCCR1B = ( _BV(ICNC1) | _BV(CS11) | _BV(CS10) );
  //Timer1 Input Capture Interrupt Enable, Overflow Interrupt Enable 
  TIMSK1 = ( _BV(ICIE1) | _BV(TOIE1) );
  //  attachInterrupt(0, rise, RISING);
  Serial.println("\"joshhawk\" Weather Station receiver v0.01");
  Serial.println("Ready to receive weather data");

* main loop

void loop() {
  // weather packet ready to decode
  if(weather_rx_state == RX_STATE_PACKET_RECEIVED) {
#ifdef DEBUG
      for(int i = 0; i < ((WEATHER_PACKET_BIT_LENGTH)); i++) {
        Serial.print(weather_packet[i], BIN);
        Serial.print(" ");



So I've written a preliminary sketch (basically just modified "Thermor", someone else's weather station code).  I'm having trouble actually reading the packets - it seems to miss bits or miss entire packets altogether.  Any idea what I could be doing wrong?

Does this weather station use the same bit encoding scheme as the one your hacking?

The code is at the limits of my Amtel & C++ language knowledge (only started just after xmas). Many years ago I wrote a similar program to decode SMPTE timecode on a PIC microcontroller in assembly. I used a similar principle though only bothered with rising edges for interrupts. A quick look makes me think you could do the same using just falling edge with this signal.
Once I almost saw Elvis but then my shovel broke. :(


Hey Riva,

No, the bit encoding scheme is different, hence the code I've written...  I'm going to keep poking at it.  If anyone else with some experience in this area sees where the flaw is in my code, definitely let me know!


Hey Riva, do you think that the timing of the edges can be accurately measured by what we've been doing through audacity?  I've made a rough estimate that the short pulses are ~1000us from edge to edge, long edges are ~2000us, and the "big" pulse that starts and ends a packet is ~3500us.  Does that seem right?


Hey Riva, do you think that the timing of the edges can be accurately measured by what we've been doing through audacity?  I've made a rough estimate that the short pulses are ~1000us from edge to edge, long edges are ~2000us, and the "big" pulse that starts and ends a packet is ~3500us.  Does that seem right?

I had looked at this a while back when thinking of best algorithm for reading pulses and concluded a 1-2-3 ratio. 1 being a clear bit , 2 being a set bit & 3 being packet start. You could maybe create some clean sequences in audacity using copy & paste and play them to your code that logs interrupt periods so you can fine tune the timings.
I think it's possible to read the burst successfully using falling edge interrupts only. The interrupt code would be a simple state machine that determine duration between edges and this duration would drive the states.
1. Wait for a 3x duration then start reading bits
2. if duration < 1x  then back to state 1. if duration > 3x then back to state 1 if all bits have not been read
3. check correct preamble and stop bits, back to state 1 if wrong
4. copy value to buffer and set flag for main code to read it. revert back to state 1

Main code would wait for flag and then compare/copy value with previous value(s) if you have 2 or more same values then assume it's a good reading and decode as needed.
Once I almost saw Elvis but then my shovel broke. :(


I finally picked up this project again after a couple months and have started writing a sketch.  Have a look at this thread here:


Having a bit of trouble...  Would appreciate any insight from some of you smart minds :)


I finally managed to pull together enough time/resources to tackle this reading/decoding problem.
*** First off I don't have a weather sensor so none of this code is confirmed working in the real world.  ***

I captured the sample .wav files attached to several of the posts in this thread into my UNO to convert to logic level so I could record them with a logic analyser. I then wrote the attached test code for reading the playback from my analyser and it seems to work okay with the samples I have.
It uses pin 2 interrupts to read the data and interacts with the main program using flag bits.
To signal data available F_HAVE_DATA is set, because the data does not contain any form of CRC if 2 or more consecutive reads are the same then F_GOOD_DATA is also set. You read the unsigned long result from 'read_Buffer' and should then clear F_HAVE_DATA so you know when another reading arrives.
Once I almost saw Elvis but then my shovel broke. :(

Go Up

Please enter a valid email to subscribe

Confirm your email address

We need to confirm your email address.
To complete the subscription, please click the link in the email we just sent you.

Thank you for subscribing!

via Egeo 16
Torino, 10131