I have the following signal from a temperature sensor (broadcasts on 433.92 MHz, apparently as ASK).

I cannot for the life of me extract the temperature data.

I've tried reading off the bits in so many different ways (mostly by looking at the pulse widths) then searching the data for the temperature info.

For example:

pwm signal

This corresponds to a temp of 21.0.

I tried to read each pulse after the first 4 big pulses - that gives 37 bits:


Then I tried searching just for the 21 part. So I tried searching for 21, 61, 71 (in case the designer was adding 40 or 50 degrees to avoid negative numbers). I tried searching for the 2 and then the 1 bit shifted by 4. I tried negating all the bits. I tried searching in reverse.

Is it possible this is not pulse width modulation? Is it possible there are not 37 bits here?


closed as too broad by MBaz, jojek, Laurent Duval, Peter K. Mar 4 '16 at 9:45

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    $\begingroup$ Reverse engineering data stream can be tough (yet funny). From only one temperature information, this seems quite difficult. Digital information is often digitized with offset and scale. Can you record other temperatures? Do you have the datasheet of the sensor? $\endgroup$ – Laurent Duval Mar 2 '16 at 19:19
  • $\begingroup$ ain't you supposed to have a definition of signal encoding out there? it is quite weird trying to decode this stream without actually knowing what the encoding was... $\endgroup$ – Fat32 Mar 2 '16 at 20:23

It is impossible to extract the correct data from this string with only one sample (as is mentioned by Laurent Duval in the comments). Here is something that caught my eye:


You have these four blocks at the beginning and the end of the signal that are some kind of start/end markers, I suppose. Are you sure that you caught the whole markers?

1000111110010010110001100011111111000 could be split up in the following way:




so the 1000 and 1111 might actually be part of the markers.

The temperature itself

You say the signal corresponds to 21.0°, i.e. a number with an accuracy of 0.1°. It could be that this is encoded as the integer 210. 210 in binary is 11010010 and you can find this string (reversed) in there:


The prefixing 10 is 2 in decimal and could be a 2 bit indicator of the number of 4 bit words that encode the temperature, however this would be strange since the temperature is reversed and the prefix is not...

Please try the following:

  1. Measure the same temperature multiple times in independent experiments. Is the resulting data string the same in each experiment? Are parts of the string the same in each experiment?

  2. Measure multiple temperatures that only differ by 0.1°. Is there a corresponding pattern in the data string?

  3. Do you have a datasheet of your sensor?

  • $\begingroup$ Good point. I am afraid that the 0.1 precision could be only a crude decimal conversion $\endgroup$ – Laurent Duval Mar 2 '16 at 20:19
  • $\begingroup$ I can't believe it, you're totally right! I also can't believe I didn't think of that! They were not bit shifting, they were adding 500 to the 10 times the temp and encoding that, just like you suggested. It totally works. All these values checked out: t2 = "1000111110010010110110110100010011000" # 23.1 t3 = "1000111110010010111000100101101111000" # 23.8 t4 = "1000111110010010101101000010110111010" # 19.2 t5 = "1000111110010010110000110011110011000" # 20.7 t6 = "1000111110010010110101000100110111000" # 22.4 t7 = "1000111110010010111000100101101111000" # 23.8 $\endgroup$ – Nick Lang Mar 2 '16 at 21:32
  • $\begingroup$ I didn't have a datasheet no, so this is kinda a reverse engineering job. Man, I was going crazy trying to figure that out. Time to brush up on my binary arithmetic! Thank you soooooooo much!!! $\endgroup$ – Nick Lang Mar 2 '16 at 21:33
  • $\begingroup$ You are very welcome! I'm glad my suggestion was helpful to you. :) $\endgroup$ – M529 Mar 2 '16 at 21:35
  • $\begingroup$ I guess another way to think about it is they were shifting in base 10 not base 2. $\endgroup$ – Nick Lang Mar 2 '16 at 21:39

Not the answer you're looking for? Browse other questions tagged or ask your own question.