2

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:

1000111110010010110001100011111111000

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?

jojeck
  • 11,107
  • 6
  • 38
  • 74
Nick Lang
  • 251
  • 2
  • 8
  • 1
    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? – Laurent Duval Mar 02 '16 at 19:19
  • 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... – Fat32 Mar 02 '16 at 20:23

1 Answers1

3

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:

Markers

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:

1000
1111

100100101100011000111

1111
1000

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:

100100101100011000111
  01001011

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?

M529
  • 1,736
  • 10
  • 15
  • Good point. I am afraid that the 0.1 precision could be only a crude decimal conversion – Laurent Duval Mar 02 '16 at 20:19
  • 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 – Nick Lang Mar 02 '16 at 21:32
  • 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!!! – Nick Lang Mar 02 '16 at 21:33
  • You are very welcome! I'm glad my suggestion was helpful to you. :) – M529 Mar 02 '16 at 21:35
  • I guess another way to think about it is they were shifting in base 10 not base 2. – Nick Lang Mar 02 '16 at 21:39