433 Weather sensor from Oregon Scientific problems decoding

Maybe something like attached though the 0/1 times may be inverted.
I would think section A is to allow the receiver AGC to settle before sending the sync (message start).

The waveforms attached. Riva how do you call this scheme - so that I can read up.
Many thanks!

Update:
I've extrapolated from your screen grab that the data can be represented just using the timings:
Two "pulses per bit".

  1. Short pulse followed by a short pulse = 1,
  2. Short pulse followed by a long pulse = 0.

Out comes (4 different captures):

1,1,1,0,0,0,1,1,1,1,0,1,1,1,1,0,1,1,0,1,1,0,1,1,1,1,0,1,0,1,0,0,0,0,0,1,1,1,0,0,0,0,1,0,0,0,0,1,0,0,1,0,0,1,0,0,0,0,1,0,1,0,1,0,0,0,0,1,1,0
1,1,1,0,0,0,1,1,1,1,0,1,1,1,1,0,1,1,0,1,1,0,1,1,1,1,0,1,0,1,0,0,0,0,0,1,1,1,0,0,0,0,1,0,0,0,0,1,0,0,1,0,0,1,0,0,0,0,1,0,1,0,1,0,0,0,0,1,1,0
1,1,1,0,0,0,1,1,1,0,1,1,1,0,1,1,1,0,0,1,1,0,1,1,1,0,1,1,1,1,0,0,0,0,0,1,1,1,0,0,0,1,0,0,0,1,0,0,0,1,1,0,0,1,0,0,0,1,0,0,0,0,1,1,0,1,0,0,1,1
1,1,1,0,0,0,1,1,1,0,1,1,1,0,1,1,1,0,0,1,1,0,1,1,1,0,1,1,1,1,0,0,0,0,0,1,1,1,0,0,0,1,0,0,0,1,0,0,0,1,1,0,0,1,0,0,0,1,0,0,0,0,1,1,0,1,0,0,1,1

Samples1-3.zip (129 KB)

Attached is some untested code that may decode your signal.
I would like to test it with the samples you supplied before posting but time is against me and it may be the weekend before I could do that so maybe you can try it and see.

PulseReader.ino (5.97 KB)

@Riva: quick feedback. That is more substantial than I would have expected! Thank you very much.

With line 104:

      }
      rise_Time = uTime;                                  // Store rise time
    }

changed such that:

      }
      rise_Time = uTime + rise_Time;                      // Store rise time
    }

It does indeed detect and confirms the previous analysis.
The change may not follow logically in what we are doing but it follows your use of uTime. After getting a bit further I will rewrite this bit. For now I'll let the data flow.

We have at least 2 consecutive matching reads
11100011110100101001101110011010000111000010110101100100011001001111011
We have at least 2 consecutive matching reads
11100011110100101001101110011010000111000010110101100100011001001111011
We have at least 2 consecutive matching reads
11100011110100101001101110011110000111000010110101100100011000001011011

Just for interest sake I have written (ahem, adapted an older program) Python program to draw the timing data in a previous post (04-01-2016, 16:16:12). The high/Low representation is just a guess at the moment. But the overall patterns may be clearer with this than from the Audacity recording.

If you would like the Python program I will clean it up and post it here as well.

You appear to have nailed it already though I see :slight_smile:

Cheers, Rob

Thanks for pointing out my programming error pawpro, I have altered my local copy to match.
I'm amazed it (almost) worked out of the box. Maybe I should pick some lottery numbers today :slight_smile:

I will be back on this within 24h. But today I need to integrate Audeme's Movi board that just arrived.

I'm a bit lost. I don't know if I'm doing this right.
Assuming the data capturing and decoding is right (I'm starting to think it may not be).

I'm trying to convert the binary data to dec and spot the patterns. Sadly the sensor doesn't have a screen and I don't have the weather station. So I'm using other sensors to get the readouts.
This is what I have. I am breaking the stream in to 4 bit chunks (4, 8 and 12) put together and converting it to decimal looking for my temp and humidity:

21.2C, 80%
11100010101110101111101111011000000111010100010100000100001001110000110:
 0. 1110   14; 
 1. 0010    2; 11100010  226; 
 2. 1011   11; 00101011   43; 111000101011 3627; 
 3. 1010   10; 10111010  186; 001010111010  698; 
 4. 1111   15; 10101111  175; 101110101111 2991; 
 5. 1011   11; 11111011  251; 101011111011 2811; 
 6. 1101   13; 10111101  189; 111110111101 4029; 
 7. 1000    8; 11011000  216; 101111011000 3032; 
 8. 0001    1; 10000001  129; 110110000001 3457; 
 9. 1101   13; 00011101   29; 100000011101 2077; 
10. 0100    4; 11010100  212; 000111010100  468; 
11. 0101    5; 01000101   69; 110101000101 3397; 
12. 0000    0; 01010000   80; 010001010000 1104; 
13. 0100    4; 00000100    4; 010100000100 1284; 
14. 0010    2; 01000010   66; 000001000010   66; 
15. 0111    7; 00100111   39; 010000100111 1063; 
16. 0000    0; 01110000  112; 001001110000  624; 

11100010101110101111101111010100000111010100010100000100001010110101010:
 0. 1110   14; 
 1. 0010    2; 11100010  226; 
 2. 1011   11; 00101011   43; 111000101011 3627; 
 3. 1010   10; 10111010  186; 001010111010  698; 
 4. 1111   15; 10101111  175; 101110101111 2991; 
 5. 1011   11; 11111011  251; 101011111011 2811; 
 6. 1101   13; 10111101  189; 111110111101 4029; 
 7. 0100    4; 11010100  212; 101111010100 3028; 
 8. 0001    1; 01000001   65; 110101000001 3393; 
 9. 1101   13; 00011101   29; 010000011101 1053; 
10. 0100    4; 11010100  212; 000111010100  468; 
11. 0101    5; 01000101   69; 110101000101 3397; 
12. 0000    0; 01010000   80; 010001010000 1104; 
13. 0100    4; 00000100    4; 010100000100 1284; 
14. 0010    2; 01000010   66; 000001000010   66; 
15. 1011   11; 00101011   43; 010000101011 1067; 
16. 0101    5; 10110101  181; 001010110101  693; 

38.5C, 20%
11100011101100010011100101011110000111000100111011000110101000001010011:
 0. 1110   14; 
 1. 0011    3; 11100011  227; 
 2. 1011   11; 00111011   59; 111000111011 3643; 
 3. 0001    1; 10110001  177; 001110110001  945; 
 4. 0011    3; 00010011   19; 101100010011 2835; 
 5. 1001    9; 00111001   57; 000100111001  313; 
 6. 0101    5; 10010101  149; 001110010101  917; 
 7. 1110   14; 01011110   94; 100101011110 2398; 
 8. 0001    1; 11100001  225; 010111100001 1505; 
 9. 1100   12; 00011100   28; 111000011100 3612; 
10. 0100    4; 11000100  196; 000111000100  452; 
11. 1110   14; 01001110   78; 110001001110 3150; 
12. 1100   12; 11101100  236; 010011101100 1260; 
13. 0110    6; 11000110  198; 111011000110 3782; 
14. 1010   10; 01101010  106; 110001101010 3178; 
15. 0000    0; 10100000  160; 011010100000 1696; 
16. 1010   10; 00001010   10; 101000001010 2570; 

11100010101100010011100011111000000111010100111011000111000001100111111:
 0. 1110   14; 
 1. 0010    2; 11100010  226; 
 2. 1011   11; 00101011   43; 111000101011 3627; 
 3. 0001    1; 10110001  177; 001010110001  689; 
 4. 0011    3; 00010011   19; 101100010011 2835; 
 5. 1000    8; 00111000   56; 000100111000  312; 
 6. 1111   15; 10001111  143; 001110001111  911; 
 7. 1000    8; 11111000  248; 100011111000 2296; 
 8. 0001    1; 10000001  129; 111110000001 3969; 
 9. 1101   13; 00011101   29; 100000011101 2077; 
10. 0100    4; 11010100  212; 000111010100  468; 
11. 1110   14; 01001110   78; 110101001110 3406; 
12. 1100   12; 11101100  236; 010011101100 1260; 
13. 0111    7; 11000111  199; 111011000111 3783; 
14. 0000    0; 01110000  112; 110001110000 3184; 
15. 0110    6; 00000110    6; 011100000110 1798; 
16. 0111    7; 01100111  103; 000001100111  103; 

-6.4C, 80%
11100010101010111111111101001100000111010101010000000000101100100001010:
 0. 1110   14; 
 1. 0010    2; 11100010  226; 
 2. 1010   10; 00101010   42; 111000101010 3626; 
 3. 1011   11; 10101011  171; 001010101011  683; 
 4. 1111   15; 10111111  191; 101010111111 2751; 
 5. 1111   15; 11111111  255; 101111111111 3071; 
 6. 0100    4; 11110100  244; 111111110100 4084; 
 7. 1100   12; 01001100   76; 111101001100 3916; 
 8. 0001    1; 11000001  193; 010011000001 1217; 
 9. 1101   13; 00011101   29; 110000011101 3101; 
10. 0101    5; 11010101  213; 000111010101  469; 
11. 0100    4; 01010100   84; 110101010100 3412; 
12. 0000    0; 01000000   64; 010101000000 1344; 
13. 0000    0; 00000000    0; 010000000000 1024; 
14. 1011   11; 00001011   11; 000000001011   11; 
15. 0010    2; 10110010  178; 000010110010  178; 
16. 0001    1; 00100001   33; 101100100001 2849;

Any ideas?

@Riva: I'm attaching further "improved" version of your sketch. If you can look pass the styling changes I "needed" there were couple of "serious" issues one with delay(100) being executed every loop() invocation, sync pulse detection was triggered when the pulse was longer than but not "smaller than" so was triggered very often (clearing the previous data - also changed). I've broken the debug LED a bit.

PulseReader.ino (6.13 KB)

I suggest to solve the temperature encoding first. Collect data at a bunch of different temperatures, trying to measure those as accurately as possible, and look for a pattern. It is very helpful to have data for temperatures above and below freezing, and to have temperatures separated by one or more single digit changes, like 20.0, 20.1 and 20.2 C.

I've decoded a number of sensors and there are two common approaches for storing temperature: always Celcius, often in tenths of a degree C, and represented by either BCD digits or binary (10-12 bits). Sometimes there is an offset so that the number is positive (e.g. 50, or 500).

So, I would look for a bit field that shows changes consistent with increasing temperature, with one of those two possibilities in mind.

This encoding is a real departure from Oregon Scientific's previous data encoding schemes (which used BCD digits), so it may or may not be very helpful to consider them.

Also, keep in mind that most of these sensors are accurate to around +/- 1 degree C, so give some leeway when comparing your own measurements.

If you like, post a table of complete messages, along with the estimated temperature, and others will be happy to help solve it. What you posted above, with the guessed breakdowns, is confusing and has too few data points for me to make sense of.

@jremington thanks for your comments! I will have to set up a more controlled test. I thought they were a fairly recent model but it seems they not. So perhaps this is the old way for OS or maybe as someone suggested it's been done by another manufacturer.

Do you think the binary data we capture is correct?
Does anyone have any doubts?

Here is what you asked for. I will try to gather better data soon.
Only unique entries for past couple of hours. On a heater next to another sensor which reports 39.9C/20%

11100011101100010011100101110000000111000100111011000110100011110110111
11100011101100010011100101011110000111000100111011000110101000001010011
11100010101100010011100011111000000111010100111011000111000001100111111
11100010101100010011100011110110000111010100111011000111000010001000010
11100010101100010011100011110100000111010100111011000111000010101010011
11100010101100010011100011110010000111010100111011000111000011001100010
11100010101100010011100011110000000111010100111011000111000011101110011
11100010101100010011100011101110000111010100111011000111000100010001110
11100010101100010011100011101100000111010100111011000111000100110011111
11100010101100010011100011011110000111010100111011000111001000000011111
11100010101100010011100011011100000111010100111011000111001000100100000
11100010101100010011100011011000000111010100111011000111001001101000000
11100010101100010011100011010100000111010100111011000111001010101100100
11100010101100010011100011010010000111010100111011000111001011001110011
11100010101100010011100011010000000111010100111011000111001011110000100
11100010101100010011100011001110000111010100111011000111001100010011111
11100010101100010011100011010110000111010100111011000111001010001010011

Sometimes it helps with reverse decoding of unknown sensors, to find out all the types of sensors that the receiving console supports, including ones that you dont have, as the data fields being transmitted will be common to all the sensors.
You can usually look up the accuracy specs for the temps and the RH and find out if its 1 Deg C or 0.1 D C
and similar with the RH.
Are these sensors actually made by OS or are they 3rd party sensors which have been re badged as OS ones?
The latter would explain the non standard protocol.

I'll bet you are right that the EW99 is a 3rd party sensor.
It doesn't seem to be available in the U.S., which is rather strange for a U.S. company!

well protocols - Checksum/CRC calculation - Stack Overflow
This guy shared his findings (while looking for CRC calc help) and...
It seems I am one bit off. When I skip one bit things look a bit more sensible. Still confirming.

To determine the most likely range of bits used for temperature & humidity place the sensor in the fridge/freezer (depending on it's specs) for about 30 minutes then bring it out and start logging the data. The temperature, humidity & checksum bits should be changing quite rapidly while fixed values like sensor ID, channel number will remain constant.
Once you have an idea what bits to look at you might have a better chance of decoding them.

I don't think that the sensor described in the stackoverflow post is of the same type.

I've rearranged the data table from post#14 into 8-bit columns as follows and see that primarily, fields D, H and I change. B and F take on just two values and the same row in each changes. Presumably column I (or perhaps H and I) is a checksum.

If D and H are temperature and humidity, they change a lot. This is inconsistent with your claim that the temperature and humidity are relatively constant.

I second Riva's suggestion of the freezer.

A       B        C        D        E        F        G        H        I
1110001 11011000 10011100 10111000 00001110 00100111 01100011 01000111 10110111
1110001 11011000 10011100 10101111 00001110 00100111 01100011 01010000 01010011
1110001 01011000 10011100 01111100 00001110 10100111 01100011 10000011 00111111
1110001 01011000 10011100 01111011 00001110 10100111 01100011 10000100 01000010
1110001 01011000 10011100 01111010 00001110 10100111 01100011 10000101 01010011
1110001 01011000 10011100 01111001 00001110 10100111 01100011 10000110 01100010
1110001 01011000 10011100 01111000 00001110 10100111 01100011 10000111 01110011
1110001 01011000 10011100 01110111 00001110 10100111 01100011 10001000 10001110
1110001 01011000 10011100 01110110 00001110 10100111 01100011 10001001 10011111
1110001 01011000 10011100 01101111 00001110 10100111 01100011 10010000 00011111
1110001 01011000 10011100 01101110 00001110 10100111 01100011 10010001 00100000
1110001 01011000 10011100 01101100 00001110 10100111 01100011 10010011 01000000
1110001 01011000 10011100 01101010 00001110 10100111 01100011 10010101 01100100
1110001 01011000 10011100 01101001 00001110 10100111 01100011 10010110 01110011
1110001 01011000 10011100 01101000 00001110 10100111 01100011 10010111 10000100
1110001 01011000 10011100 01100111 00001110 10100111 01100011 10011000 10011111
1110001 01011000 10011100 01101011 00001110 10100111 01100011 10010100 01010011

It's been outside for past 8 hours. Temperature reported by another sensor is 1.2C.
Readings for the past 5 min.

11100010101111100111111111111100000111010100000110000000000000101011001
11100010101111100111111111111100000111010100000110000000000000101011001
11100010101111100111111111111100000111010100000110000000000000101011001
11100010101111100111111111111100000111010100000110000000000000101011001
11100010101111100111111111111100000111010100000110000000000000101011001

I've opened one of these out. Photo attached in case you recognise something (not much to see).

UPDATE:
Well the temperature just rose by about 0.1 degree outside and something interesting (perhaps happened).

This is the transition afait

11100010101111100111111111111100000111010100000110000000000000101011001
11100010101111100111111111111000000111010100000110000000000001101111001

What are they doing?

By just adding some spaces I get the following:

11   1000 1010 1111 1001 1111 1111 1111   0000 
     0111 0101 0000 0110 0000 0000 0000   101011001

11   1000 1010 1111 1001 1111 1111 1110   0000 
     0111 0101 0000 0110 0000 0000 0001   101111001

Looks like somewhere mid way they reverse the bits and transmit again?

UPDATE 2:
Some old captures broken down in exactly the same way

11 1000111101001010011011100110 1000 
   0111000010110101100100011001 001111011

11 1000111101001010011011100110 1000 
   0111000010110101100100011001 001111011

11 1000111101001010011011100110 1000 
   0111000010110101100100011001 001111011

11 1000111101001010011011100111 1000 
   0111000010110101100100011000 001011011

Your results suggest that the following 12 bits are the temperature, a signed 12 bit integer in tenths of a degree C. The second line is the complement of the data (a common error-checking approach).

In this interpretation, the top temperature is negative (-1 or -0.1 degree) and then changes to -0.2. Or, the bottom code is the temperature 0.0, which then changes to 0.1.

1111 1111 1111
0000 0000 0000

1111 1111 1110
0000 0000 0001

If this is correct, the 16 bits preceding the temperature could be the humidity, and perhaps some other measure.

I retract post #21 (although the observation is valid), because I think I found the temperature, encoded as BCD digits.

I converted the last 6 columns of the data in post #14 and earlier ones (with data for 21.2, around 0.0 and -6.5) to hex. You mentioned in post #14 that the temperature was near 39 C. The last 3 hex digits before the presumed 8-bit checksum appear to be BCD digits for temperatures in the range of 38.3 and 39.8

If you add in the data for 21.2, about 0.0 and -6.5 degrees, it becomes rather convincing, but considering that -6.5 is represented as 059, there must be a negative sign somewhere else.

The complement of the data comes earlier in the message. I don't know what that means.

Below, the presumed temperature digits are separated by spaces for clarity.

about 38 C
1110001 11011000 10011100 10111000 00001110 00100111 01100011 01000111 10110111 B80E276 347 B7
1110001 11011000 10011100 10101111 00001110 00100111 01100011 01010000 01010011 AF0E276 350 53
1110001 01011000 10011100 01111100 00001110 10100111 01100011 10000011 00111111 7C0EA76 383 3F
1110001 01011000 10011100 01111011 00001110 10100111 01100011 10000100 01000010 7B0EA76 384 42
1110001 01011000 10011100 01111010 00001110 10100111 01100011 10000101 01010011 7A0EA76 385 53
1110001 01011000 10011100 01111001 00001110 10100111 01100011 10000110 01100010 790EA76 386 62
1110001 01011000 10011100 01111000 00001110 10100111 01100011 10000111 01110011 780EA76 387 73
1110001 01011000 10011100 01110111 00001110 10100111 01100011 10001000 10001110 770EA76 388 8E
1110001 01011000 10011100 01110110 00001110 10100111 01100011 10001001 10011111 760EA76 389 9F
1110001 01011000 10011100 01101111 00001110 10100111 01100011 10010000 00011111 6F0EA76 390 1F
1110001 01011000 10011100 01101110 00001110 10100111 01100011 10010001 00100000 6E0EA76 391 20
1110001 01011000 10011100 01101100 00001110 10100111 01100011 10010011 01000000 6C0EA76 393 40
1110001 01011000 10011100 01101010 00001110 10100111 01100011 10010101 01100100 6A0EA76 395 64
1110001 01011000 10011100 01101001 00001110 10100111 01100011 10010110 01110011 690EA76 396 73
1110001 01011000 10011100 01101000 00001110 10100111 01100011 10010111 10000100 680EA76 397 84
1110001 01011000 10011100 01100111 00001110 10100111 01100011 10011000 10011111 670EA76 398 9F
1110001 01011000 10011100 01101011 00001110 10100111 01100011 10010100 01010011 6B0EA76 394 53

about 21.2 C
1110001 01011101 01111101 11101100 00001110 10100010 10000010 00010011 10000110 EC0EA28 213 86
1110001 01011101 01111101 11101010 00001110 10100010 10000010 00010101 10101010 EA0EA28 215 AA

about -6.5 C
1110001 01010101 11111111 10100110 00001110 10101010 00000000 01011001 00001010 A60EAA0 059 0A

about 1.2
1110001 01011111 00111111 11111110 00001110 10100000 11000000 00000001 01011001 7E0EA0C 001 59

about 0.0
1110001 01011111 00111111 11111110 00001110 10100000 11000000 00000001 01011001 FE0EA0C 001 59
1110001 01011111 00111111 11111100 00001110 10100000 11000000 00000011 01111001 FC0EA0C 003 79

There is always the possibility the reading program I knocked up is interpreting the bits the wrong way round (I was guessing) so 6000us is a zero and 4000us is a 1

//    ______        ______     ___     ___
//   |      |      |      |   |   |   |
//___|      |______|      |___|   |___|
//
//   |    Sync     |     1    |   0   |
//   |    8000us   |  6000us  | 4000us

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

Either way, the proposed temperature digits would be 394.

Assuming 1=4000 us and 0 = 6000 us is more likely to be correct, as people often send the data and then the data complement as a check.