cannot recover corrupted preamble

[Freax13]

I'm trying to receive the messages from HCA E2 sensors. I can receive messages sent by other sensors, but for some reason, rtl-wmbus doesn't receive the messages sent by my HCA E2 sensors. I saved some IQ data using rtl_sdr -f 868.95M -s 1.6e6 data.dat, truncated it, and attached it to this issue here. rtl_433 seems to be able to receive messages from the sensors (including from the attached file), so I don't think it's an issue in my radio receiver setup.

I tried debugging this issue, and it seems that the preambles for the T1 messages sent by the sensors are severely corrupted. When I increase ACCESS_CODE_T1_C1_ERRORS to 6, I can receive the messages sent by the HCA E2 sensors:

diff --git a/rtl_wmbus.c b/rtl_wmbus.c
index f026700..a34fb7d 100644
--- a/rtl_wmbus.c
+++ b/rtl_wmbus.c
@@ -73,7 +73,7 @@

 static const uint32_t ACCESS_CODE_T1_C1 = 0b0101010101010000111101u;
 static const uint32_t ACCESS_CODE_T1_C1_BITMASK = 0x3FFFFFu;
-static const unsigned ACCESS_CODE_T1_C1_ERRORS = 1u; // 0 if no errors allowed
+static const unsigned ACCESS_CODE_T1_C1_ERRORS = 6u; // 0 if no errors allowed

 static const uint32_t ACCESS_CODE_S1 = 0b000111011010010110u;
 static const uint32_t ACCESS_CODE_S1_BITMASK = 0x3FFFFu;

I used the following patch to print out the preambles (executed with ./build/rtl_wmbus -t 0):

diff --git a/rtl_wmbus.c b/rtl_wmbus.c
index f026700..00d5866 100644
--- a/rtl_wmbus.c
+++ b/rtl_wmbus.c
@@ -721,6 +721,7 @@ static void runlength_algorithm_t1_c1(unsigned raw_bit, unsigned rssi, struct ru

             if (count_set_bits((algo->bitstream & ACCESS_CODE_T1_C1_BITMASK) ^ ACCESS_CODE_T1_C1) <= ACCESS_CODE_T1_C1_ERRORS)
             {
+                printf("Preamble detected. bits=%08x error=%08x\n", algo->bitstream, (algo->bitstream & ACCESS_CODE_T1_C1_BITMASK) ^ ACCESS_CODE_T1_C1);
                 bit |= (1u<<PACKET_PREAMBLE_DETECTED_SHIFT); // packet detected; mark the bit similar to "Access Code"-Block in GNU Radio
             }

One of the preambles preceding a message by sensor 02717473 looks like this:

Preamble detected. bits=99353625 error=00206218

As you can see, a large number of bits are incorrect.

Oddly enough, it seems to me that only the preambles are corrupted, the following messages themselves seem completely fine (the CRC check passes and I can decrypt the payload). What's going wrong here? Why is the preamble so corrupted and is there a way to recover from that?

[xaelsouth]

Hello Freax13,

thanks for input. Check out the new version of rtl_wmbus. Got this output with your file attached. From those two lines (each line for each decoder), pick the one which starts with C1;1;1. That means: Mode C1, CRC check ok, T1 ok (is always the case for C1 mode, obviously).

cat trunc.dat | build/rtl_wmbus C1;1;1;2024-05-09 16:02:29.000;13;8;20338739;0x574468503987332094088c0066900f002c256d4c09001379a347c9de055e7a6d00300710f1b5a1a06f8306237d16af2fc907479e250b872378287765676ec98652cc97572702b0ed8cefbe575e68194d59dad9b40fdd9269 C1;0;1;2024-05-09 16:02:30.000;8;6;20210116;0x574468501601212094088c0013900f002c2579610901e04839848dad6f3c7a7900300710719e84d90bd144364d15579431a00ee6e761e308e774232e8e6b2501c9753ec028b273bddee520d299996eb76edd6b9f0f486669

[Freax13]

Thank you for your answer. Unfortunately, these aren't the messages I'm looking for. It seems that I didn't truncate the file correctly and accidentally left some other messages in there. I apologize for the confusion. I'm looking for this message:

T1;1;1;2024-05-09 17:00:05.000;136;128;02717473;0xce44c5147374710231087a2800c0251377b1a3250b426eb794f4b558620682803946f8c2aaa22e39cf081fc44f4d9c649c005580814ee8b195beda83537cd983f5ae1e770b59c81d8fb75883c84d9c72183cf9ad6cb4620bafba5e669aa14d59b259fc5eca5843ff1c1238f5256bd5b19668107dee242c8923eb89238173e8af0c34057f715ba88b9d0873dce0c44076f1025bcfdce42a9fb3f30c8178c14dd2779bb188cbcbf12853ad2e9fe82146d640963a5620cad0d66cf58342dd3cf366fd5e6eefb2ab861d1cce533c5215fc

(I got this line by setting ACCESS_CODE_T1_C1_ERRORS to 6 instead of 1 as described above.)

I tried running the code from the latest master branch but didn't notice any changes.

[xaelsouth]

You are right. In the output I posted, there was an another manufacturer 0x5068. Interesting. This issue https://github.com/xaelsouth/rtl-wmbus/issues/49 seems to be like yours. Should investigate this further, not as simple as I thought.

[xaelsouth]

One more try?.. I think the very first datagram is what you are looking for: HCA 0x08 with manufacturer ID = 0x14c5 (Engelmann).

cat trunc.dat | build/rtl_wmbus T1;1;1;2024-05-09 21:48:56.000;46;49;03110176;0xce44c5147601110331087ae600c0255354edb37b903eb74222fdb68606c2421f0576e25a196298a763ebd36a12100748a0b82fe509363bffba18f0955b5ee340c31f77343d7253cfb3a62f5f28aa260db7cc430910d99371f569387b9a60aad2af482a3efff6c0f9567d5755d479717481e053cf60af910009e74118fb66212ff4c975e49cb34febdfc1bbf528049192d2bf37bced9eb4896a949599542f43b2a90eef941ab96334e479e357418cc2c50bee5cd2cadddd559139b467c593fa36c7280dcc012a46336124248c7dcb6f T1;1;1;2024-05-09 21:48:56.000;50;51;03110176;0xce44c5147601110331087ae600c0255354edb37b903eb74222fdb68606c2421f0576e25a196298a763ebd36a12100748a0b82fe509363bffba18f0955b5ee340c31f77343d7253cfb3a62f5f28aa260db7cc430910d99371f569387b9a60aad2af482a3efff6c0f9567d5755d479717481e053cf60af910009e74118fb66212ff4c975e49cb34febdfc1bbf528049192d2bf37bced9eb4896a949599542f43b2a90eef941ab96334e479e357418cc2c50bee5cd2cadddd559139b467c593fa36c7280dcc012a46336124248c7dcb6f C1;1;1;2024-05-09 21:48:56.000;13;8;20338739;0x574468503987332094088c0066900f002c256d4c09001379a347c9de055e7a6d00300710f1b5a1a06f8306237d16af2fc907479e250b872378287765676ec98652cc97572702b0ed8cefbe575e68194d59dad9b40fdd9269 T1;1;1;2024-05-09 21:48:56.000;132;126;02717473;0xce44c5147374710231087a2800c0251377b1a3250b426eb794f4b558620682803946f8c2aaa22e39cf081fc44f4d9c649c005580814ee8b195beda83537cd983f5ae1e770b59c81d8fb75883c84d9c72183cf9ad6cb4620bafba5e669aa14d59b259fc5eca5843ff1c1238f5256bd5b19668107dee242c8923eb89238173e8af0c34057f715ba88b9d0873dce0c44076f1025bcfdce42a9fb3f30c8178c14dd2779bb188cbcbf12853ad2e9fe82146d640963a5620cad0d66cf58342dd3cf366fd5e6eefb2ab861d1cce533c5215fc T1;1;1;2024-05-09 21:48:56.000;136;128;02717473;0xce44c5147374710231087a2800c0251377b1a3250b426eb794f4b558620682803946f8c2aaa22e39cf081fc44f4d9c649c005580814ee8b195beda83537cd983f5ae1e770b59c81d8fb75883c84d9c72183cf9ad6cb4620bafba5e669aa14d59b259fc5eca5843ff1c1238f5256bd5b19668107dee242c8923eb89238173e8af0c34057f715ba88b9d0873dce0c44076f1025bcfdce42a9fb3f30c8178c14dd2779bb188cbcbf12853ad2e9fe82146d640963a5620cad0d66cf58342dd3cf366fd5e6eefb2ab861d1cce533c5215fc C1;0;1;2024-05-09 21:48:56.000;8;6;20210116;0x574468501601212094088c0013900f002c2579610901e04839848dad6f3c7a7900300710719e84d90bd144364d15579431a00ee6e761e308e774232e8e6b2501c9753ec028b273bddee520d299996eb76edd6b9f0f486669

[Freax13]

Yup, your changes resolved this issue. Thank you so much!