Help me decode this 434mhz signal...?

Hi Riva,

Sure, I can give as many examples as you’d like.

I’ve attached several raw wav files of a bit stream with values fairly close together to be able to hopefully find the difference between them. I can give more broad ranged values too if you’d like.

Sample B: transmitter read 71.2F and 39% humidity
Sample C: transmitter read 70.3F/21.3C and 40% humidity
Sample E: transmitter read 70.0F/21.1C and 41% humidity
Sample F: transmitter read 70.2F/21.2C and 41% humidity

The transmitter sends the burst of new data approximately every 75 seconds.

Thanks for any insights whatsoever, no matter how small!

sampleC.wav (88.2 KB)

sampleE.wav (87.1 KB)

sampleF.wav (80.6 KB)

sampleB.wav (96.9 KB)

Hi joshhawk,

Thanks for the samples. They are quite low level but with a bit of amplification I get the idea. Looking at them stacked on top of each other (see picture) and I wonder if it is maybe not Manchester encoded. It looks more like a MFM encode but that’s normally used for magnetic media use.
Can you open the transmitter case without damage and maybe see what components are inside?

Forgot to ask if you could supply more samples over larger ranges please.

Hi Riva,

Yes, I agree, it does not seem to be manchester encoded… I did not consider MFM encoding, but that may be a possibility.

Here are a few more samples, plus some photos of the inside boards.

Sample J: transmitter read 80.6F/27.0C and 26% humidity
Sample K: transmitter read 43.0F/6.1C and 19% humidity

I can get more samples and more pictures if you’d like. Thanks so much for your help!

sampleJ.wav (90.4 KB)

sampleK.wav (99.1 KB)

Hi joshhawk,

Just to let you know what my thinkings are sofar. As transmission length varies depending on content and no long highs I feel sure it’s not Manchester encoding. I wonder if it’s far simpler than that in that a 1 is a single peak and a 0 is a peak followed by a trough (see image for better idea). The bit values could be reversed (peak for 0 & peak/trough for 1).
I had a quick look at the online manual and it says humidity ranges from 20% to 99% in 1% increments (though one of the samples you sent said 19% humidity?) so the range is 79 (99-20) that can fit in 7 bits. Temperature range is stated as -20 to +70 in 0.1 increments that fit’s in 10 bits if you multiply by 10 to remove decimal point.
I also wonder if the last 2 bits are stop bits

A couple of samples of minus C temperatures would be helpful please.

Hi Riva,

Yes, we were talking about the possibility of that encoding scheme in a few of the earlier posts on this thread. It’s still interesting to me though because with that scheme, all of the samples I have taken begin with the same bit sequence 101010110101. Perhaps a preamble/device id/“channel number” of some sort…

But that does not leave many bits left to represent temperature and humidity. Despite the manual, I have seen humidities much less than 20% before, reported on the interior and exterior display. I’ve attached a quick photo as proof (showing a 16% value).

I’ve got the transmitter in the freezer now so I will be able to give you some very cold samples very shortly.

Thank you for your help!!!


Hi Riva, here are several more samples.

Sample L: transmitter read 21.9F/-5.6C and 16% humidity
Sample M: transmitter read 16.3F/-8.7C and 16% humidity
Sample N: transmitter read 28.4F/-2.0C and 16% humidity
Sample O: transmitter read 28.4F/-2.0C and 43% humidity

sampleL.wav (98 KB)

sampleM.wav (70.8 KB)

sampleN.wav (78.4 KB)

sampleO.wav (51.2 KB)

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:

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:

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.

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.

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

Hey Riva, here are some negative C temperature values:

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

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

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 :slight_smile:

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?

 * 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 
 * ( 
 * For more info: 

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

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.

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 :slight_smile:

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.

WeatherRF.ino (5.44 KB)