Go Down

Topic: 433 Weather sensor from Oregon Scientific problems decoding (Read 7583 times) previous topic - next topic

AlexeyRU

Hi PawPro,

If this subject is still interesting to you.

I have an ew99 sensor and a base station of ew91 which shows temperature. I obtain data from the sensor on the SDR receiver and I use rtl_433 for decoding of a signal (https://github.com/merbanan/rtl_433).

Analyzing pulses...
Total count:   75,  width: 91787                (367.1 ms)
Pulse width distribution:
 [ 0] count:   74,  width:   474 [466;482]      (1896 us)
 [ 1] count:    1,  width:   968 [968;968]      (3872 us)
Gap width distribution:
 [ 0] count:   36,  width:   501 [497;508]      (2004 us)
 [ 1] count:   38,  width:   990 [984;998]      (3960 us)

Sensors have the similar protocol
In nexus.c
 * the packets are ppm modulated (distance coding) with a pulse of ~500 us
 * followed by a short gap of ~1000 us for a 0 bit or a long ~2000 us gap for a
 * 1 bit, the sync gap is ~4000 us.
In prologue.c
 * the packets are ppm modulated (distance coding) with a pulse of ~500 us
 * followed by a short gap of ~2000 us for a 0 bit or a long ~4000 us gap for a
 * 1 bit, the sync gap is ~9000 us.
Probably?

short gap for a 0 bit
long  gap for a 1 bit

You decoded a signal on the contrary - a short gap 1, a long gap - 0.

If to make on the contrary (see attach file), then we will receive:
Code: [Select]

10001110_10010100_11001010_00101000_1111000.....
8___e____9___4____c___a____2___8____f

10001110_00010100_11000010_00100111_1111000.....
8___e____1___4____c___2____2___7____f

10001110_00010100_11000010_00100111_1111000.....
8___e____1___4____c___2____2___7____f

10001110_10010011_01111010_00100100_1111000.....
8___e____9___3____7___a____2___4____f


For my device I have:
Code: [Select]

EW99 bitbuffer event 2016-02-29 23:19:51 - 23,8 C
10001110 10010000 11000010 00111000 11110001 01101111 00111101 11000111 11110101
8___e____9___0____c___2____3___8
EW99 bitbuffer event 2016-03-01 02:11:49 - 0,0 C
10001110 10010000 11000000 00000000 11110001 01101111 00111111 11111111 11000110
8___e____9___0____c___0____0___0
EW99 bitbuffer event 2016-03-01 02:52:49 - -0,6 C
10001110 10011000 11000000 00000110 11110001 01100111 00111111 11111001 11100010
8___e____9___8____c___0____0___6


EW99 bitbuffer event 2016-02-29 16:46:03 - 19,4 C canal 1
10001110 00010011 10010001 10010100 11110001 11101100 01101110 01101011 01100010
8___e____1___3____9___1____9___4
EW99 bitbuffer event 2016-02-29 16:44:22 - 19,3 C canal 2
10001110 00100010 10010001 10010011 11110001 11011101 01101110 01101100 01110111
8___e____2___2____9___1____9___3
EW99 bitbuffer event 2016-02-29 16:38:48 - 19,4 C canal 3
10001110 00110110 01110001 10010100 11110001 11001001 10001110 01101011 00111011
8___e____3___6____7___1____9___4

EW99 bitbuffer event 2016-02-29 15:45:01 - reverse the bits
10001110 10010000 00000001 10010011 11110001 01101111 11111110 01101100 10110111
_1110001 01101111 11111110 01101100__==================================


So, that as a result:
Code: [Select]

8___e____3___6____7___1____9___4
10001110 00110110 01110001 10010100 11110001 11001001 10001110 01101011 00111011
___________^^   canal___^^_^^^^^^^^ temp                                           CRS?
_____________^  sign


It is all so far.

Cheers, Alex

jremington

That appears to agree with my previous analysis, with the bits inverted. The temp is BCD encoded, and sent along with its complement later in the message.

Quote
If you invert all the bits in the message, the presumed temperature field just comes earlier in the message. Converting the central 48 bits (which appear to carry the data and the data complement) to hex, you get

10011100 01101011 00001110 10100111 01100011 10010100 =
9C6B0EA76394, which complemented, is
6394F1589C6B  (temp = 39.4 C)

AlexeyRU

Hi, jremington!

I agree with "bits inverted" excepting the first bit first four bytes.
Code: [Select]

EW99 bitbuffer event 2016-02-29 15:45:01 - reverse the bits (excepting the first bit of first byte)
10001110 10010000 00000001 10010011 11110001 01101111 11111110 01101100 10110111
_1110001 01101111 11111110 01101100__==================================


I agree with "the temp is BCD encoded" - but "packed BCD" (https://en.wikipedia.org/wiki/Binary-coded_decimal.

I have been surprised - "(temp = 39.4 C)" in your message. It in Africa :) ? Or in the room :o?

Ok.

The sensor transfers temperature from-40 to +60 (according to the description).
I have put the sensor on the battery and have heated to 45,5 C
Code: [Select]
EW99 bitbuffer event 2016-03-05 03:27:52 - 45,5 C
10001110 10010000 11000100 01010101 11110001 01101111 00111011 10101010 11101000
8___e___ 9___0___ c___4___ 5___5___ f1 6f 3b aa e8


So, three bits on tens of temperature at the end of the third byte, the fourth byte of unit + 1/10.

As a result what we have:
Code: [Select]
EW99 bitbuffer event 2016-03-05 03:27:52 - 45,5 C
10001110 10010000 11000100 01010101 11110001 01101111 00111011 10101010 11101000
kkkkkkkk ??ccs??? ?????ttt tttttttt _rrrrrrr rrrrrrrr rrrrrrrr rrrrrrrr CRS__CRS

k - device code
c - canal
s - sign
t - temperature
r - reverse (excepting the first bit)
? - ???????


How to define what is meant by the remained unknown bits? There are ideas?

Yours faithfully, Alex





jremington

Quote
I have been surprised - "(temp = 39.4 C)" in your message. It in Africa :) ? Or in the room :o?
Read post #14.

Quote
How to define what is meant by the remained unknown bits?
"CRS" could be a CRC checksum, but there are other possibilities, like a simple sum. Other bits could be battery status, temperature increasing or decreasing, etc.

You have to look at a lot of entries to make sure, and if "CRS" is a CRC checksum, many bits will change, even if only one bit in the message changes.

If it is a CRC you need to determine the polynomial and input/output constants. I have used the program reveng to reverse engineer CRC calculations. http://reveng.sourceforge.net/

Go Up