[Solved] Bresser 7002000 weather station sensor decoding riddle

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

There are no DIP switches, on the inside there is only a reset button next to the batteries - nothing more.

Miq1:
It must be something simple - I would not expect the tiny brain of the sensor doing something elaborate.

Yes the initial flurry of bits is to settle the AGC of a receiver, you normally then have a random number of undetermined bit length that is generated when the sensor is powered.
You will obviously have temperature and humidity values, possible channel number (if your device supports this) and maybe battery condition. This may be topped of with a CRC or checksum.
I have seen different ways of doing the temperature. Some just use signed values of the temperature, multiplied to remove decimal point. Some add an offset to the temperature so (for example) -10.0C would transmit as zero, 20.0C transmits as 300.

Yes, the offset is done with other Bresser sensors as well. They even are using Fahrenheit values instead of Celsius, plus an offset of 90 degrees. I would concentrate first on the humidity, as that will be encoded as a single byte most probably.

In my Manchester lib (I know this here is PWM, not Manchester ;)) there is another technique applied: a "decoupling mask". Any data byte is first XORed with a 8-bit mask of 11001010b before being sent. May be something similar is used here, but I was not able to find one yet. I tried to XOR the bit pattern of a humidity value against the received data, apply the resulting mask (if there was one) with XOR to another message at the same spot to see if the resulting bit sequence would result into the humidity value for that second message.

But unfortunately I did not find a match in the last 16 bits - I stopped there since I did it manually and got tired noting down bits :smiley:

One more consideration: I think we can omit looking for float values, as the simplest binary form (IEEE754) will have 32 bits for a single value - too many to fit in the short message. So it will be a shorter, binary format.

I opened the sensor to look for the PCB; the sensor is a Sensirion SHTC1

It delivers temperature and humidity via I²C in 24 bit packets (MSB, LSB and Checksum). The real value is calculated as (MSB,LSB)/65536, so "10100001,00110011,00011100" gets 62.9% and "01100100,10001011,11000111" 23.7°C.

But even these bit sequences are not identifyable in the messages. 63% (displayed) would be something around "10100001,01xxxxxx" - this sequence is in fact in the sampled data ("10100001,11101001") and will result in 63.24%. But the next line had "10100000,01101001" at the same spot, that is a lower value (62,66%), while a higher (65%) was displayed.

In general the numbers at that spot are close to 62%-63%, whereas the displayed values range from 57% to 65%.