[Solved] Bresser 7002000 weather station sensor decoding riddle

[Solution found with the major help of Riva :wink: 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:

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.

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

Paul

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.

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.

Because your mention of sending on 433 meant you were receiving on 433, but I guessed wrong. Sorry.
Paul

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

Miq1:
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

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.

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

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.

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).

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

Clipboard-1.jpg

EDIT:
Does this work with your data?

@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.

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.

@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.

rtl_433 with my SDR picked the following from the device:

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 :wink:

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 :slight_smile:

It does not look like Manchester but I still cannot get the data to look right.

It must be something simple - I would not expect the tiny brain of the sensor doing something elaborate.
The initial long-short pulses most probably will be some calibration or locking pattern for the receiver. Then the first short-long must be the start marker; perhaps even more. So the data will be in the last ~40-48 pulses.
Humidity has values between 0 and 100, so we would need 7 bits at least for it. The temperature is displayed with one fractional digit only, but there may be a few more internally. Celsius temperature will be between -30 and +50, so we can assume no more than 16 bits for it. Add some for channel, battery status and sensor id. And may be a checksum. All that will fit nicely in the 40-48 bits.
Data is sent bitwise, the method to do it may be LSB first, as it requires the least operations. So the data may be in reverse order.
The known Bresser protocols that I found documented do not match unfortunately, but the payload data has the sizes as envisioned above.
But still...

A bit of Google searching shows me the device transmits on 534 mHz, not 433mHz. And there can be up to 5 of the temp/hum sensors sending data to the central unit.

What is the id # of the one you are using. A simple deductive test would be to record the transmission, as you have done, then change to another id number and record that and continue through all 5 possibilities and then see what changes in your recording and can the change be related to an id number.

Another thing, I see the transmission period for the sensor is listed as about 47 seconds. Are you seeing that in your testing?

Paul

@Paul_KD7HB: you must be on the wrong track. I can assure you the sensor is transmitting on 433MHz. The one I have is a legacy one that is out of sales for some years already. It was never sold alone but always in combination with the weather station I mentioned in the opening post.

Miq1:
@Paul_KD7HB: you must be on the wrong track. I can assure you the sensor is transmitting on 433MHz. The one I have is a legacy one that is out of sales for some years already. It was never sold alone but always in combination with the weather station I mentioned in the opening post.

Ok, but what about the multiple units? My station is similar to yours and has dip switches to set the address of the temp/hum remote.

Paul