No bits decoded from wmbus T1 Message

[kralo]

The following capture is decoded quite nicely with
cat <file> | rtl_wmbus -d 3 -s and yields one T1 Message starting with 0x294468506.... However that message looks strange to me (some repeating fffffff inside...) so I wanted to decode it with rtl_433.

I tried rtl_433 -r <file> -R 105 -vvv or -R 0 -A but got no demodulation (nor with R 104).

I know this packet is potentially encrypted. But I had no luck specifying the decoder with -X "n=a,m=FSK_PCM,short=10,long=10,reset=500"

rtl_sdr_f868.625M_s2400000_onesampleMbusT1.cu8.zip

[kralo]

The triq.org viewer seems to be sensible to the filename and gets slow, so this is another try capt_rtlsdr_f868.625M_s2400000_onesample_larger_wMbusT1.cu8
2861_sample2.cu8.zip

[merbanan]

You need to set the correct frequency and sample rate also. (-f and -s)

[klohner]

I took a look at this but I don't understand why -R 104 isn't picking this up either. Am I doing something wrong?

Renaming either sample to something more normalized, I can do:

rtl_433 -r MbusT1_g001_868.695M_2400k.cu8 -X n=MBUS,m=FSK_PCM,s=10,l=10,r=500,preamble={16}543d

and get data like:

{588}3a571c6ac6566a5b1935a6964daa56c5ca539965969693a968d2d659636c68d2d6596b1668d59658d5a5a4b5a65966a398d5964f48ce596b31d0b596972c5c5965a9c9959695a8e6800

But this doesn't seem to return anything:

rtl_433 -R 0 -R 104 -r MbusT1_g001_868.695M_2400k.cu8

Even though, -R 104 is:

[104] Wireless M-Bus, Mode C&T, 100kbps (-f 868.95M -s 1200k)

and its code seems to look for that same modulation and symbol width:

rtl_433/src/devices/m_bus.c

Lines 1201 to 1209 in afb5b34

	r_device const m_bus_mode_c_t = {
	.name = "Wireless M-Bus, Mode C&T, 100kbps (-f 868.95M -s 1200k)", // Minimum samplerate = 1.2 MHz (12 samples of 100kb/s)
	.modulation = FSK_PULSE_PCM,
	.short_width = 10, // Bit rate: 100 kb/s
	.long_width = 10, // NRZ encoding (bit width = pulse width)
	.reset_limit = 500, //
	.decode_fn = &m_bus_mode_c_t_callback,
	.fields = output_fields,
	};

Is something forcing that this decoder will only work for "(-f 868.95M -s 1200k)"?

[zuckschwerdt]

The data bits seem broken, try rtl_433 -R 104:vv to see a M-Bus: Decoding error

[klohner]

Ah, thanks, I figured vv would show something, but I wasn't using its correct syntax.

I now see the second 12-bit grouping in the data after the preamble is 011100 011100 which seems to be invalid to m_bus_decode_3of6 so it aborts the decoding.

rtl_433/src/devices/m_bus.c

Lines 32 to 56 in afb5b34

	static uint8_t m_bus_decode_3of6(uint8_t byte)
	{
	uint8_t out = 0xFF; // Error
	//fprintf(stderr,"Decode %0d\n", byte);
	switch(byte) {
	case 22: out = 0x0; break; // 0x16
	case 13: out = 0x1; break; // 0x0D
	case 14: out = 0x2; break; // 0x0E
	case 11: out = 0x3; break; // 0x0B
	case 28: out = 0x4; break; // 0x17
	case 25: out = 0x5; break; // 0x19
	case 26: out = 0x6; break; // 0x1A
	case 19: out = 0x7; break; // 0x13
	case 44: out = 0x8; break; // 0x2C
	case 37: out = 0x9; break; // 0x25
	case 38: out = 0xA; break; // 0x26
	case 35: out = 0xB; break; // 0x23
	case 52: out = 0xC; break; // 0x34
	case 49: out = 0xD; break; // 0x31
	case 50: out = 0xE; break; // 0x32
	case 41: out = 0xF; break; // 0x29
	default: break; // Error
	}
	return out;
	}

[klohner]

Or maybe that's a typo? Would case 28 be // 0x1c instead of // 0x17? All the 6-bit groupings seem to contain 3 1's until the end of the data.

BitBench

I'll see if I can poke around a bit more later.

[zuckschwerdt]

Surprising find. I guess that is really a typo. Hard to find second-hand sources for EN-13757-4 Three-out-of-Six encoding as the original is proprietary and paid-only.
But it's only a typo in the comment, right?

[merbanan]

Case 28 has a typo in the comment. The actual table matches the specs.

[merbanan]

I now see the second 12-bit grouping in the data after the preamble is 011100 011100 which seems to be invalid to m_bus_decode_3of6 so it aborts the decoding.

I do not agree:
011100=28
which should decode to 4.

[klohner]

Right. I had initially just compared my bitbench decode as 6-bit hex values to the comments in m_bus.c. I noticed that the second group of 12-bits in my bitbench decode was 1c 1c and I didn't see // 0x1c listed in m_bus.c, so just figured that was where the issue was. I hadn't yet realized that the // 0x17 comment was a typo (instead of // 0x1c) and the code itself, case 28, was fine.

I assume that m_bus.c is decoding further before it fails, but I haven't worked out where that is yet.

[merbanan]

I get a fail with the value 0x24.

rtl_433 -r 2861_sample2.cu8 -s 2400k -f 868.95M -R 104:vv

[m_bus_mode_c_t_callback] M-Bus: Mode T
[m_bus_mode_c_t_callback] Experimental - Not tested
[m_bus_mode_c_t_callback] MBus telegram length: 46
M-Bus: 6to4 error: 0x24[m_bus_mode_c_t_callback] M-Bus: Decoding error
[pulse_slicer_pcm] Wireless M-Bus, Mode C&T, 100kbps (-f 868.95M -s 1200k)
codes : {643}fffd55756aaaaa2aaaa1e9d2638d58ca9aad88124a5936a95b1752b9acb2d2d26a5000002946d8d1cb5096a00000cb2c6ad2fd6b4cbf6a3b1a8003a8ce52d663a16b2d2e58b9ff6ac8121695a80400000

[klohner]

I think the -f 868.95M is interfering somehow? I get the same result if I use that, but without it I get:

rtl_433 -r 2861_sample2.cu8 -s 2400k -R 104:vv

[Input] Test mode active. Reading samples from file: 2861_sample2.cu8
[m_bus_mode_c_t_callback] PREAMBLE_T: found at: 75
codes     : {687}800a2aaaaaaaaaaaaaaa87a74ae38d58cacd4b6326b4d2c9b54ad8b94a732cb2d2d2752d1a5acb2c6d8d1a5acb2d62cd1ab2cb1ab4b496b4cb2cd4731ab2c9e919cb2d663a16b2d2e58b8b2cb53932b2d2b51cd00002
[m_bus_mode_c_t_callback] M-Bus: Mode T
[m_bus_mode_c_t_callback] Experimental - Not tested
[m_bus_mode_c_t_callback] MBus telegram length: 49
[m_bus_mode_c_t_callback] M-Bus: Decoding error
[pulse_slicer_pcm] Wireless M-Bus, Mode C&T, 100kbps (-f 868.95M -s 1200k)
codes     : {687}800a2aaaaaaaaaaaaaaa87a74ae38d58cacd4b6326b4d2c9b54ad8b94a732cb2d2d2752d1a5acb2c6d8d1a5acb2d62cd1ab2cb1ab4b496b4cb2cd4731ab2c9e919cb2d663a16b2d2e58b8b2cb53932b2d2b51cd00002

[klohner]

My guess is that it's trying to look at the 'garbage' at the end and fails trying to decode that.

BitBench

[merbanan]

I am quite sure the demodulation code messed up the bitstream.

-s 2400 also imply that we increase the band-width to 2.4MHz. So now we have like a 100 times larger window then we actually need. And most likely other signals are visible in this band.

We should enable the 300MHz bandwidth filter parameter for the R820t when possible.

[klohner]

I think the demodulation only messed up the bitstream by decoding a sample recorded at frequency 868.625M with forcing it read it back as frequency 868.95M.

rtl_433 -r 2861_sample2.cu8 -s 2400k -R 104:vv gives me:

{687}800a2aaaaaaaaaaaaaaa87a74ae38d58cacd4b6326b4d2c9b54ad8b94a732cb2d2d2752d1a5acb2c6d8d1a5acb2d62cd1ab2cb1ab4b496b4cb2cd4731ab2c9e919cb2d663a16b2d2e58b8b2cb53932b2d2b51cd00002

And I see what looks like valid data where the first 48 12-bit-groups are valid decodable data. I can manually decode this to:

{384}294468506985166076F0D4F7A0009F2F613000186130008061000109F30A006BA1007CB2008DC3009ED4000FE50096BA

It's just that the next and last 12 bits of the demodulation is 100000000000. This is just garbage and shouldn't be decoded. But the decoder is trying to decode this anyway, failing, and throwing away all 96 bytes of the good data it had already decoded.

[merbanan]

Omitting -f > 800M will run the classic fsk demodulator code. It seems to work better with this sample.

[merbanan]

time : @0.030594s
model : Wireless-MBus Mode : T Manufacturer: TCH ID : 60168569
Version : 118 Device Type: 0xF0 Device Type String: Control : 0x44 Data Length: 42
Data : 274468506985166076f0a0009f2f613000186130008061000109006ba1007cb2008dc3009ed4000fe50096ba Integrity : CRC
Control Info: 0xA0 Access number: 0x00 Device Type: 0x00 Configuration Word: 0x0000 Min Volume flow[0]: 0.068 m3/min
Max Pressure[1]: 0.000 bar Temperature diff[12]: 0.000 K
[pulse_slicer_pcm] Wireless M-Bus, Mode C&T, 100kbps (-f 868.95M -s 1200k)
codes : {687}800a2aaaaaaaaaaaaaaa87a74ae38d58cacd4b6326b4d2c9b54ad8b94a732cb2d2d2752d1a5acb2c6d8d1a5acb2d62cd1ab2cb1ab4b496b4cb2cd4731ab2c9e919cb2d663a16b2d2e58b8b2cb53932b2d2b51cd00002

[klohner]

Ah, that makes sense. Anyway, can you confirm my suspicions as to why the -R 104 decode failed? The data I manually decoded seems to match up with the "0x294468506..." that @kralo originally mentioned that rtl_wmbus was able to decode.

[merbanan]

@@ -64,7 +66,7 @@ static int m_bus_decode_3of6_buffer(uint8_t const *bits, unsigned bit_offset, ui
         uint8_t nibble_h = m_bus_decode_3of6(bitrow_get_byte(bits, n*12+bit_offset) >> 2);
         uint8_t nibble_l = m_bus_decode_3of6(bitrow_get_byte(bits, n*12+bit_offset+6) >> 2);
         if (nibble_h > 0xf || nibble_l > 0xf) {
-            return -1;
+//            return -1;
         }
         output[n] = (nibble_h << 4) | nibble_l;

[merbanan]

If we dont check the 3of6 output the decoder will pass it to the bytestream decoder and crc code for validation.

[merbanan]

The extra data at the end will then not matter. @klohner can you also test and send a PR as you found the solution to the issue?

[klohner]

Is there something else I need to do to help with this PR?