Go Down

Topic: [Solved] Bresser 7002000 weather station sensor decoding riddle (Read 1 time) previous topic - next topic

Miq1

[Solution found with the major help of Riva  ;) See page 3]

If someone is willing to join the battle: I am trying to decode the signals from an old temp/humidity sensor that was bought with a Bresser 7002000 "4cast LX" weather station that ceased to work.

The sensor is sending on 433MHz, the encoding seems to be

Long-short: 0
Short-long: 1

With that, I get the following data:
Code: [Select]

16:15:41 PWM 0000000000000001100010000101101100111000101111001011010101011000 20,0 53
16:17:10 PWM 0000000000000001100010000100001000010100101111110011010110001000 20,3 52
16:18:39 PWM 0000000000000001100010000111001000010100101111010011010111001000 20,6 51
16:20:08 PWM 0000000000000001100010000101101000010100101111100011010110101000 20,8 50
16:21:37 PWM 0000000000000001100010000100011000010100101111000011010101011000 21,1 49
16:23:06 PWM 0000000000000001100010000110001100010100101111100110010101011000 21,3 48
16:24:35 PWM 0000000000000001100010000111001100010100101111000110010110011000 21,5 48
16:26:04 PWM 0000000000000001100010000110101100010100101111000110010111111000 21,7 47
16:27:33 PWM 0000000000000001100010000111101100010100101111111010010101001000 21,9 47
16:32:00 PWM 0000000000000001100010000110001010010100101111101010010110101000 22,2 44
16:33:29 PWM 0000000000000001100010000101001010010100101111001010010111101000 22,3 44
16:34:58 PWM 0000000000000001100010000111001010010100101111001010010101101000 22,4 43
16:36:27 PWM 0000000000000001100010000100101010010100101111110010010101101000 22,4 43
16:37:56 PWM 0000000000000001100010000100101010010100101111110010010101101000 22,5 42
16:39:25 PWM 0000000000000001100010000110101010010100101111010010010101101000 22,6 42
16:40:54 PWM 0000000000000001100010000101101010010100101111010010010110101000 22,6 41
16:42:23 PWM 0000000000000001100010000101101010010100101111100010010101101000 22,6 41
16:43:52 PWM 0000000000000001100010000101101010010100101111100010010101101000 22,7 41
16:45:21 PWM 0000000000000001100010000111101010010100101111100010010111101000 22,8 40


The digits at the end give the temperature in °C and relative humidity in % that the sensor displayed at the time the data was captured.

I would think the leading "00000..." sequence may be a lead-in, the data proper seems to start after the "11000100001" sequence.

Some parts seem to be constant throughout all messages:

0000000000000001100010000111101010010100101111100010010111101000

There are some more bits in between that do not change, but that may be caused by the sensor data being in a narrow temperature and humidity range at the time.

I dug the Internet for hours to find any clue, but none of my findings seem to match.

Neither BCD nor binary patterns are to be found that would even come close to the readable sensor data. I am at a loss currently, I am afraid.

Paul_KD7HB

And I am at a loss to see what you are using for a receiver to know what the sensor is sending.

Paul

Miq1

Uh, why would that matter? But anyhow: it is an ESP32, development is done in the Arduino environment. I am using its RMT component to collect the signals.

Paul_KD7HB

Uh, why would that matter? But anyhow: it is an ESP32, development is done in the Arduino environment. I am using its RMT component to collect the signals.
Because your mention of sending on 433 meant you were receiving on 433, but I guessed wrong. Sorry.
Paul

Miq1

Basically you are right, the 433MHz are picked up by an SRX882 module connected to a GPIO of the ESP32.

Paul_KD7HB

Basically you are right, the 433MHz are picked up by an SRX882 module connected to a GPIO of the ESP32.
Just to confirm. The sensor is sending Manchester encoded data. and the receiver is properly decoding it.

Paul

Miq1

Yes. I have several sensors the receiver is correctly decoding, so I reckon it is reading the data from the Bresser sensor as well. If it makes any difference I can give you the raw signal data.

Paul_KD7HB

I am making the really big assumption here: You don't really know if the temp/humidity sensor is sending MAnchester encoded data that your receiver can decode and give you Ascii data on it's data output and you can see on the Arduino serial pin.

Right?

Paul

Miq1

Well, so it is raw data time. Please find below the list of phase lengths for this very sort of messages.

The RMT peripheral gives a 1 for HIGH level and a 0 for LOW level signals (the number in front of the dots) and the respective phase lengths in "ticks" (after the dots). A tick in this case is 1.875µs long, so a number "446" will mean a phase length of 836µs. A complete phase change is at 1.25ms, so the transmission speed seems to be around 800bd.

Code: [Select]

block of 264

1.446/0.208 1.441/0.211 1.438/0.213 1.437/0.216 1.434/0.218 1.432/0.219 1.432/0.219 1.431/0.221 1.430/0.222 1.428/0.224 1.427/0.224 1.427/0.225 1.425/0.226 1.425/0.226 1.425/0.227 1
.424/0.227 1.164/0.487 1.165/0.486 1.426/0.224 1.426/0.226 1.425/0.226 1.165/0.485 1.427/0.224 1.427/0.226 1.424/0.225 1.426/0.227 1.165/0.484 1.427/0.225 1.166/0.484 1.167/0.483 1.
429/0.224 1.166/0.483 1.169/0.483 1.169/0.481 1.170/0.481 1.431/0.222 1.168/0.481 1.430/0.223 1.428/0.223 1.427/0.223 1.428/0.224 1.167/0.482 1.430/0.224 1.166/0.483 1.170/0.481 1.1
70/0.481 1.170/0.481 1.430/0.221 1.169/0.481 1.171/0.480 1.432/0.221 1.169/0.481 1.431/0.222 1.168/0.482 1.170/0.480 1.430/0.222 1.171/0.480 1.429/0.222 1.429/0.223 1.168/0.482 1.42
9/0.223 1.169/0.482 1.428/0.222 1.430/0.223 1.427/0.225 1.426/0.  0 -

trying PWM...
10:03:44 PWM 0000 0000 0000 0001 1000 1000 0101 1011 1101 0000 1011 1101 1010 1101 0010 1000


You can see that we only have two combinations: A long HIGH, followed by a short LOW or a short HIGH, followed by a long LOW. Looks pretty much like Manchester to me. The resulting bit sequence is what I wrote before (the "PWM 0000 0..." lines).

Riva

The data in your initial post does not tie up correctly. It seems the temperature/humidity value you added on the end are out of step. The two example that have the same consecutive temperature/humidity readings don't line up with the data being identical.
Are we to assume all the readings are out?

Green highlight is matching data but text on end (22.4 43) does not line up



EDIT:
Does this work with your data?
Don't PM me for help as I will ignore it.

Miq1

@Riva: yes, I noticed that, too and thought it might be one off. All I can say is that I noted down the displayed values as soon as I received the telegram. It may be the sensor will show new readings already that are later sent to the base station at the end of a cycle only. Would not make too much sense to me to keep the base one behind, though.

Regarding the Github link: no, does not fit seemingly.

Riva

I can see no sensible pattern in the data you supplied so do you have an example image of the transmission data? Like Paul I think it's less likely that the signal is using Manchester encoding and a picture paints a thousand words data points.
Don't PM me for help as I will ignore it.

Miq1

@Riva: all I can provide right now are the tick data in the above post. I will try to rig up my SDR and Audacity. If I get some waves I will post it.

In the meantime I added inverted, reverse and inverted+reverse outputs to my receiver program, but still no match.

Miq1

rtl_433 with my SDR picked the following from the device:

Code: [Select]

Detected OOK package
Analyzing pulses...
Total count:   66,  width: 20058                (80.2 ms)
Pulse width distribution:
 [ 0] count:   42,  width:   215 [214;219]      ( 860 us)
 [ 1] count:   24,  width:    94 [92;96]        ( 376 us)
Gap width distribution:
 [ 0] count:   41,  width:    89 [88;91]        ( 356 us)
 [ 1] count:   24,  width:   211 [210;213]      ( 844 us)
Pulse period distribution:
 [ 0] count:   65,  width:   305 [303;309]      (1220 us)
Level estimates [high, low]:  15872,    241
Frequency offsets [F1, F2]:  -12406,      0     (-47.3 kHz, +0.0 kHz)
Guessing modulation: Pulse Width Modulation with fixed period
Attempting demodulation... short_limit: 154, long_limit: 214, reset_limit: 214, demod_arg: 0
pulse_demod_pwm(): Analyzer Device
bitbuffer:: Number of rows: 1
[00] {66} 00 00 c4 3d 8a 5e 3c ac 00


This would be these bits:

0000 0000 0000 0000 1100 0100 0011 1101 1000 1010 0101 1110 0011 1100 1010 1100 0000 0000

The displayed data was 21.8°C and 38% at that time. Again I can not detect the data in these bits.

Next will be Audacity ;)

Miq1

I tried with SDRsharp and Audacity, but got a very coarse signal only. Then I used Universal Radio Hacker and it got better:



You can see the long and short phases/pauses here already. If you are interested in zoomed data, just tell me :)

Go Up