Bresser 5-in-1 with CC1101

[alcarazzam]

Hello,

I'm trying to decode the data from a Bresser 5-in-1 weather station with a CC1101 using ESP32. The station transmits on the 868.3 MHz frequency and uses the protocol of the 6-in-1 station (rtl_433 code). I've tried to decode the data using different parameters without success. I just get random data not timed with the weather station. This is my current code based on issue #168 (that issue is for the old 5-in-1):

// setup()
CC1101 radio = new Module(5, 2, RADIOLIB_NC, 4);

// freq (MHz), bit rate (kbps), freqDev (kHz), receiverBandWidth (kHz), power (dBm), preambleLength (bits)
int state = radio.begin(868.3, 8.22, 60, 270.0, 10, 32);
  
radio.setCrcFiltering(false);
radio.fixedPacketLengthMode(19);
radio.setSyncWord(0xaa, 0x2d, 0, false);

// loop()
byte byteArr[19];
int state = radio.receive(byteArr, 19);

Using URH I get the following spectrum, with a a peak at 868.224 MHz and other at 868.341 MHz.

Attached is a recording of the signal (around 2.8 seconds from the start of the file), but not sure about if the signal is recognizable.

However, I'm not sure about how to determine the bit rate, frequency deviation and receiver bandwidth.

Regards

[jgromes]

Attached is a recording of the signal

The attachment seems to be missing, could you try sending it again?

However, I'm not sure about how to determine the bit rate, frequency deviation and receiver bandwidth

Frequency deviation is easy to see from a spectrum - there's two peaks roughly 120 kHz apart, that would put frequency deviation at 60 kHz. The signal is slightly offset to the left, so the station is actually transmitting below 868.3 MHz. Receiver bandwidth is just a filter applied on the input, so it should be larger than frequency deviation (at least 2 - 3 times).

Bit rate is trickier, that has to be determined from a recording. URH is usually pretty good at setting it automatically, at least for simple 2-FSK signals like this one.

However, even with the three "physical" parameters matching, why would you assume the packet structure matches as well? For example, you assume it's always going to be 19 bytes long.

FYI there's also a known bug in the CC1101 driver (#345), which could be the reason why you're receiving random junk data.

[alcarazzam]

The attachment seems to be missing, could you try sending it again?

Upss! I forgot to attach the file. I've recorder another one, but both have too much noise:
gqrx_20211207_133458_868300000.zip

Somehow I was able to record a good signal with URH: RTL-SDR-20211204_195717-868_3MHz-1MSps-1MHz.complex16s.zip. I've tried to measure the bit rate but some of the bytes last more than others. More or less each bit is around 120 µs, which gives a 8.33 kbps bitrate, I guess.

why would you assume the packet structure matches as well?

I've seen that rtl_433 uses 18 bytes for the data, so I added one more for the extra sync byte. I think that the two weather stations use the same protocol, but I'm not sure.

[jgromes]

Opening the samples in URH, I decoded the following:

aaaaaaaaaa85bd40f72419300280f0c3ffffffe678405544f3fffe00700000000000000000000000000000000000000000000000000

More or less each bit is around 120 µs

Better approach might be to measure the entire message and then count the number of bits. Divide the two and you will get rid of small timing errors for each byte.

The first part is obviously the preamble (4 bytes long), but the rest seems longer than 18 bytes.

What I meant by the packet structure matching is that CC1101 expects a preamble-sync-payload structure (if we don't use length, address and CRC). Do you know if the station transmits that?

It's also not possible to deduce the packet structure from a single packet. Try to capture several, then compare them to see which parts change and which parts don't. Is the length always the same? Does the preamble or sync word change? Etc.