Add KNX RF support?

[holmie]

Not sure if it's appropriate to create an issue here for this, close if unwanted.

Any chance of taking a stab at decoding KNX RF? I have added some test samples with a PR to rtl_433_tests

https://github.com/merbanan/rtl_433_tests/pull/266

I've tried to describe in detail what I know in the readme over at tests.

Sending device is a Hager TD210. (GC066 also printed on it.)

[merbanan]

src/rtl_433 -v -v -X "n=KNX-RF,m=FSK_PWM,s=130,l=260,r=2000" -r ../rtl_433_tests/tests/knx_rf/g001_868.32M_1024k.cu8

[merbanan]

That command will be able to detect signals of the air.

[merbanan]

But as the signal is manchester coded it is not correct. I fail to get correct parameters for the manchester decoder. And there is a manchester violation (?) that might trip the current code,

[merbanan]

src/rtl_433 -A -s 1024k -r ../rtl_433_tests/tests/knx_rf/g009_868.32M_1024k.cu8

Analyzing pulses... Total count: 175, width: 12.62 ms (12923 S) Pulse width distribution: [ 0] count: 1, width: 0 us [0;0] ( 0 S) [ 1] count: 2, width: 7 us [7;8] ( 7 S) [ 2] count: 1, width: 5 us [5;5] ( 5 S) [ 3] count: 140, width: 25 us [18;31] ( 26 S) [ 4] count: 1, width: 86 us [86;86] ( 88 S) [ 5] count: 30, width: 56 us [54;62] ( 57 S) Gap width distribution: [ 0] count: 2, width: 9 us [9;10] ( 9 S) [ 1] count: 2, width: 180 us [179;181] ( 184 S) [ 2] count: 139, width: 33 us [28;41] ( 34 S) [ 3] count: 1, width: 96 us [96;96] ( 98 S) [ 4] count: 30, width: 63 us [61;68] ( 65 S) Pulse period distribution: [ 0] count: 1, width: 10 us [10;10] ( 10 S) [ 1] count: 1, width: 16 us [16;16] ( 16 S) [ 2] count: 2, width: 195 us [184;207] ( 200 S) [ 3] count: 116, width: 60 us [56;64] ( 61 S) [ 4] count: 10, width: 120 us [118;123] ( 123 S) [ 5] count: 44, width: 90 us [87;95] ( 92 S) Level estimates [high, low]: 6287, 9 RSSI: -4.2 dB SNR: 28.0 dB Noise: -32.1 dB Frequency offsets [F1, F2]: 4340, -3004 (+67.8 kHz, -46.9 kHz) Guessing modulation: No clue...

[ 3] count: 116, width: 60 us [56;64] ( 61 S) 1000÷60 ~=16.6 kbaud with 2 bits per symbol you get the 32.768kbps from the spec

I found the relevant mbus spec: https://www.doc88.com/p-9949654967226.html And it matches the other specification.

So what is missing is getting the manchester decoder to understand the input pulse data.

[merbanan]

rtl_433 -f 868.8M -s 1024k -r rtl_433_tests/tests/knx_rf/g001_868.32M_1024k.cu8 -A -X 'n=name,m=FSK_PCM,s=28,l=28,r=300,g=0,t=0,y=94'

{411}02aaaaaaa3b4b54d4cd4d2aaad552d5555534d54b4d555554b4cd2b4cd32b5555554caaaad55555532cd555553554ccb4ccd2aa

This will produce a bitstream that contains the preamble + manchester violation + sync word and the first nibble manually manchester decode to a 1.

[merbanan]

@holmie

src/rtl_433 -f 868.8M -Y minmax -s 1024k -r ../rtl_433_tests/tests/knx_rf/g00*

time : @0.051238s model : Wireless M-Bus Mode : S Manufacturer: KNX ID : 40060900 Version : 1 Device Type: 0x94 Device Type String: Hager TR210 KNX RF Control : 0x44 Data Length: 18 Data : 1144ff030009064001940005ff0002d00081 Integrity : CRC

Data      : 1144ff030009064001940005ff0002d20081
               [1144ff03000906400194] Block 1
               [[0005ff][0002][d2][00][81]] Block 2
                                      [dX]

Only nibble X (L/NPCI ) changes in the samples. If you vary the commands you will most likely figure out the payload format.