search

merbanan / rtl_433

Program to decode radio transmissions from devices on the ISM bands (and other frequencies)
GNU General Public License v2.0
6.05k stars 1.31k forks source link

Decoding GFSK telegrams #2898

Closed xjols closed 3 months ago

xjols commented 5 months ago

Hello! I'm trying to decode GFSK pulse code in 169.4375MHz wmbus narrow band. Have a several captures and the demodulated outputs in RTL_433 don't seems that have a valid bits.

C:\Programes\Radio\Soft SDR\RTL_433\rtl_433-win-x64-23.11>rtl_433 -vvv -r g036_169.44M_2048k.cu8 -Y autolevel -M level -M noise -M bits -Y minmax -Y magest -R 0 -X "n=WMbus,m=FSK_PCM,s=11,l=11,t=8,r=500"
rtl_433 version 23.11 branch  at 202311281352 inputs file rtl_tcp RTL-SDR SoapySDR
Disabling all device decoders.
Registering protocol [0] "General purpose decoder 'WMbus'"
[Protocols] Registered 1 out of 250 device decoding protocols
[Input] Test mode active. Reading samples from file: g036_169.44M_2048k.cu8
[Input] Input format "CU8 IQ (2ch uint8)"
[Baseband] low pass filter for 2048000 Hz at cutoff 409600 Hz, 2.4 us
[pulse_slicer_pcm] General purpose decoder 'WMbus': Exact bit width (in us) is 6.05 vs 10.74, 291 bit measured
[WMbus]
codes     : {296}019801018007fffffffffff3fffd0007ffffd00be3384fffffc3ffffc03ffffff80010f200

I tried with several options. With -A option:

Analyzing pulses...
Total count:  889,  width: 3.41 ms              ( 6989 S)
Pulse width distribution:
 [ 0] count:  214,  width:    0 us [0;0]        (   1 S)
 [ 1] count:  274,  width:    1 us [1;1]        (   2 S)
 [ 2] count:  104,  width:    1 us [1;1]        (   3 S)
 [ 3] count:   85,  width:    2 us [2;2]        (   4 S)
 [ 4] count:   95,  width:    2 us [2;3]        (   5 S)
 [ 5] count:   35,  width:    3 us [3;4]        (   7 S)
 [ 6] count:   36,  width:    5 us [4;8]        (  11 S)
 [ 7] count:   23,  width:    9 us [8;11]       (  19 S)
 [ 8] count:    1,  width:   38 us [38;38]      (  77 S)
 [ 9] count:   15,  width:   14 us [12;18]      (  28 S)
 [10] count:    2,  width:   27 us [26;28]      (  55 S)
 [11] count:    3,  width:    7 us [7;7]        (  14 S)
 [12] count:    1,  width:   74 us [74;74]      ( 152 S)
 [13] count:    1,  width:   53 us [53;53]      ( 109 S)
Gap width distribution:
 [ 0] count:   85,  width:    2 us [2;3]        (   5 S)
 [ 1] count:   71,  width:    2 us [2;2]        (   4 S)
 [ 2] count:  272,  width:    1 us [1;1]        (   2 S)
 [ 3] count:  269,  width:    0 us [0;0]        (   1 S)
 [ 4] count:  105,  width:    1 us [1;1]        (   3 S)
 [ 5] count:    6,  width:   14 us [12;16]      (  29 S)
 [ 6] count:   32,  width:    4 us [4;5]        (   9 S)
 [ 7] count:   24,  width:    3 us [3;4]        (   7 S)
 [ 8] count:   11,  width:    7 us [6;8]        (  14 S)
 [ 9] count:    9,  width:   10 us [9;11]       (  20 S)
 [10] count:    2,  width:   18 us [18;18]      (  37 S)
 [11] count:    1,  width:   23 us [23;23]      (  48 S)
 [12] count:    1,  width:   44 us [44;44]      (  90 S)
Pulse period distribution:
 [ 0] count:  219,  width:    2 us [2;3]        (   5 S)
 [ 1] count:  134,  width:    2 us [2;2]        (   4 S)
 [ 2] count:  142,  width:    1 us [1;1]        (   3 S)
 [ 3] count:   37,  width:    1 us [1;1]        (   2 S)
 [ 4] count:   23,  width:   15 us [12;18]      (  30 S)
 [ 5] count:  101,  width:    5 us [4;6]        (  10 S)
 [ 6] count:  153,  width:    3 us [3;4]        (   7 S)
 [ 7] count:   41,  width:    7 us [6;9]        (  14 S)
 [ 8] count:   29,  width:   10 us [9;12]       (  20 S)
 [ 9] count:    2,  width:   19 us [19;19]      (  38 S)
 [10] count:    3,  width:   26 us [24;28]      (  54 S)
 [11] count:    2,  width:   42 us [38;45]      (  85 S)
 [12] count:    1,  width:   75 us [75;75]      ( 154 S)
 [13] count:    1,  width:   54 us [54;54]      ( 111 S)
Pulse timing distribution:
 [ 0] count:  483,  width:    0 us [0;0]        (   1 S)
 [ 1] count:  546,  width:    1 us [1;1]        (   2 S)
 [ 2] count:  209,  width:    1 us [1;1]        (   3 S)
 [ 3] count:  156,  width:    2 us [2;2]        (   4 S)
 [ 4] count:  180,  width:    2 us [2;3]        (   5 S)
 [ 5] count:   72,  width:    3 us [3;4]        (   7 S)
 [ 6] count:   57,  width:    5 us [4;8]        (  10 S)
 [ 7] count:   33,  width:    9 us [8;11]       (  19 S)
 [ 8] count:    2,  width:   41 us [38;44]      (  83 S)
 [ 9] count:   21,  width:   14 us [12;18]      (  28 S)
 [10] count:    3,  width:   26 us [23;28]      (  53 S)
 [11] count:   12,  width:    7 us [6;7]        (  14 S)
 [12] count:    1,  width:   74 us [74;74]      ( 152 S)
 [13] count:    1,  width:   53 us [53;53]      ( 109 S)
Level estimates [high, low]:   4047,    691
RSSI: -12.1 dB SNR: 15.4 dB Noise: -27.5 dB
Frequency offsets [F1, F2]:     241,    454     (+7.5 kHz, +14.2 kHz)
Guessing modulation: Non Return to Zero coding (Pulse Code)
Attempting demodulation... short_width: 0, long_width: 0, reset_limit: 500, sync_width: 0
Use a flex decoder with -X 'n=name,m=FSK_PCM,s=0,l=0,r=500'
[pulse_slicer_pcm] Analyzer Device: Exact bit width (in us) is 0.49 vs 0.49, 1575 bit measured
[pulse_slicer_pcm] Analyzer Device
codes     : {7000}830ccd733646188c000000100202300040c3078ce4d990e719c81400049cfc3e782040b008337069f3dff0bffc1e6e18f01e7e7de20d98401f3ffffb640984100300000180010001c20808648040000318e02079388f811fd187870724c3b864eefa0df81cc13f7df930e470600600002000000000c059fe73786720f83387ffe278c700200000000000100000003610180180202000ccdff6fffffffffffffffffffbffffe7fffffff1bf4fcfffffebfcffff7ffdfe7ffffffc0fe7df0effffffffffffffbffffffb3f9ffb9ffffdffc7bfffffefffff7fffdffffbfffffff7fb31cd8fff7eff9f77ffc7eee7f07f81980080fffff3dfcf7fffe7ffffc79ffffcdf72d99fbfbfffffff9fc7dcfe6ef7ff7fe99f3d60da3186c661f8fb03b04e31c8c7c8e4ec053ff7df0413239ece60c030c1068031201801000009c0c061040c0000000010000010000fefbffffff858fdfbfff7fcffeffff3ccf6ddb93c841b366df7febdff7fefefffdfee19fbfffffffefbfff866ff3ff8df3ce7fe7bb779f36ffcf2b24fc13031830604822600c83f8e39f3c0000002c0c833332102020860100382080030003ccc38700cd33d9bc7fdb6430161b36c78e05a78ff87ffdffb7f8707f4720fc06b008033dffe7f76c1bccf877380431c30010ffef7f99f7bff870f7e6fcf8063278060000030d19c331d977c7c6ddfdbe78319cfc47e3d94fafcd9e63d7d6000030c7fcffffcec3c1b610c6f18c3e5de6ff7f9961e7c7e7e7ffffffffbffff9f8ffffeffffdfffffff7bdffffffdffffc673ff9ffcffffcf0f93df9383c43660f8e0fe6c6030679e460f99d8fbced36780f804d1f1f3c26e701e1dd3fffe6e7ca76f69c78f92183c7f3efffff9fffffffffffff93c4dbc7591d820ffdf99e678ebe2996ce61e04fcce33bc6e4304f0fbde34cc23fbfdffffff7fffffbfdbff73ffee9f67effffcffcc000000090404060426090010080000c141c4cf7ffbe3f70fac7d1ffffffbf3fe7974befde39fffffffffffffffffffffffffffffffffffffe7ffffff9fffffffffffffffffffffffffff2f3399062408000083000000000000000000000022cc0200000100018180c18e36df3f3fff106c478612020f824c028200c610c203bfbcfffffbf3ffff7cf7de0f3ef1bc7c9f30db0bc7df0e3247849c6020e6040079e3fbf4fb99c76726c8184cf001010018002000800000003800

[Auto Level] Estimated noise level is -23.2 dB, adjusting minimum detection level to -20.2 dB
[Input] Test mode file issued 2 packets

The attempting decoder doen't seems that have any efect. The real symbol bit is 416us in this signal (2400bps) and Freq offsets is +-2.4KHz. Not the estimated with RTL 0.49us and (+7.5 kHz, +14.2 kHz) offsets

The same signal in URH: 004cccccc053aaaa75b48f33daa6abd4aaa8d5572aa8d567abf5249345981018 imatge imatge

I analized 22 packets in URH and all seems to have the same preamble and sync :

imatge

How I can decode this in RTL_433 ?

Thanks you! rtl_433_169.44375_2.zip rtl_433_169.44_1.zip

zuckschwerdt commented 5 months ago

The classic discriminator used by default below 800M is not very good for GFSK, try using -Y minmax

xjols commented 5 months ago

The classic discriminator used by default below 800M is not very good for GFSK, try using -Y minmax

Yes, I assumed -Y minmax and the results are the above. With -Y classicno output anything

rtl_433 -vvv -r g036_169.44M_2048k.cu8 -Y autolevel -M level -M noise -M bits -Y minmax -Y magest -R 0 -X "n=WMbus,m=FSK_PCM,s=11,l=11,t=8,r=500"

Is anyway to set bandwidth or decimation of the receiver other than default in live reception ? I tried the -t "bw=20" option to filter the reception in 20Khz but not works [sdr_apply_settings] Unknown RTLSDR setting: bw=20 

C:\Programes\Radio\Soft SDR\RTL_433\rtl_433-win-x64-23.11>rtl_433 -vvv -f 169.44M -s 2048k -g 26 -t "bw=20" -R 104 -R 105 -R106 -R107 -R228 -R237 -R238 -Y autolevel -M level -M noise -M bits -Y minmax -Y magest -A -X "n=WMbus,m=FSK_PCM,s=11,l=11,t=8,r=500"
rtl_433 version 23.11 branch  at 202311281352 inputs file rtl_tcp RTL-SDR SoapySDR
Registering protocol [104] "Wireless M-Bus, Mode C&T, 100kbps (-f 868.95M -s 1200k)"
Registering protocol [105] "Wireless M-Bus, Mode S, 32.768kbps (-f 868.3M -s 1000k)"
Registering protocol [106] "Wireless M-Bus, Mode R, 4.8kbps (-f 868.33M)"
Registering protocol [107] "Wireless M-Bus, Mode F, 2.4kbps"
Registering protocol [228] "Neptune R900 flow meters"
Registering protocol [237] "Flowis flow meters"
Registering protocol [238] "Wireless M-Bus, Mode T, 32.768kbps (-f 868.3M -s 1000k)"
Registering protocol [0] "General purpose decoder 'WMbus'"
[Protocols] Registered 8 out of 250 device decoding protocols
rtl_433: warning: 106 "Wireless M-Bus, Mode R, 4.8kbps (-f 868.33M)" does not support CSV output
rtl_433: warning: 107 "Wireless M-Bus, Mode F, 2.4kbps" does not support CSV output
[Input] The internals of input handling changed, read about and report problems on PR #1978
[SDR] Found 1 device(s)
[SDR] trying device 0: Realtek, RTL2838UHIDIR, SN: 00000001
Found Rafael Micro R820T tuner
[SDR] Using device 0: Realtek, RTL2838UHIDIR, SN: 00000001, "Generic RTL2832U OEM"
[R82XX] PLL not locked!
[SDR] Sample rate set to 2048000 S/s.
[Input] Bit detection level set to 0.0 (Auto).
[sdr_apply_settings] Unknown RTLSDR setting: bw=20
[SDR] Tuner gain set to 28.000000 dB.
[Input] Reading samples in async mode...
[SDR] rtlsdr_set_center_freq 169440000 = 0
[SDR] Tuned to 169.440MHz.
zuckschwerdt commented 5 months ago

There is -Y filter=num to set the low-pass filtering. With -v you'll see low pass filter for 250000 Hz at cutoff 25000 Hz, 40.0 us which indicates the Butterworth order 1 filter cutoff and the minimum sample width you still get. You can spec a relative or absolute number. E.g. at 250k sample rate 0.1 and 25000 are equivalent (and the default).

ProfBoc75 commented 5 months ago

Hi @xjols

Unfortunately, at 169.44 MHz, this is the Mode N not implemented in rtl_433.

extract of m_bus.c

// Mode N
// Frequency 169.400 MHz to 169.475 MHz in 12.5/25/50 kHz bands
// Bitrate 2.4/4.8 kbps, Modulation GFSK,
//      Preamble {0x55, 0xF6, 0x8D} (Format A)
//      Preamble {0x55, 0xF6, 0x72} (Format B)
//      Note: FDMA currently not supported, but Mode F2 may be usable for 2.4
// Bitrate 19.2 kbps, Modulation 4 GFSK (9600 BAUD)
//      Note: Not currently possible with rtl_433

Mode N is less than 50khz bandwidth, so sample rate at 1Mhz is enough with a central frequency at 169.6M (wire m-bus mode N , from 169.4 to 169.8125 Mhz , https://en.wikipedia.org/wiki/Wize_technology)

Because of 4 GFSK, you may have issue with rtl_433 not handle it.

xjols commented 5 months ago

Unfortunately, at 169.44 MHz, this is the Mode N not implemented in rtl_433.

extract of m_bus.c Mode N is less than 50khz bandwidth, so sample rate at 1Mhz is enough with a central frequency at 169.6M (wire m-bus mode N , from 169.4 to 169.8125 Mhz , https://en.wikipedia.org/wiki/Wize_technology)

Hello. Finally I got this unknows GFSK 2.4kbps narrow band (Mode N) in 169.44MHz decoded as telegram with the default -R 107 (Wireless M-Bus, Mode F, 2.4kbps). I set the BW filter for 18-20KHz ( -Y filter=0.08) and in default sample rate 250kbps is decoded without problems! 

[2024-04-15 10:58:54] ffccccccc053aaaa72cd06a61578cea9d556d553555baaa6260d33aab71ec0
[2024-04-15 11:00:50] 99999980a75554e59acf5bca8e7c51aaaaaaa9555caaa648000000000
[2024-04-15 11:03:53] ccccccc053aaaa72cd75d21aa48755aaaad556d556d553238d31556327c0
[2024-04-15 11:05:50] ccccccc050aaaa0d3298521aa8aaaaaaaaaaaaa0d55555555550aaaaaa238d312972ac40
[2024-04-15 11:08:53] ccccccc050aaaa0d328a2de55655555555555556aaaaaaaaaaa9555555c972ced68d13c0
[2024-04-15 11:09:28] fccccccc053aaaa75b48fb3dab93b552aab5554aaab55782a75b526a40a1fc
[2024-04-15 11:53:34] ccccccc053aaaa75b48f33dabb2dab5556d556d55a557d5675b5a559a3c06
[2024-04-15 11:53:38] f333333014eaaa9cbb6669faafacd56aaaaaaaaaaaaaa85531a27556ca17e
[2024-04-15 11:53:46] e66666602d55452de8dcf038356b5faaaaaaaaab69cfaaa51515333843e523b2e3d54ebeba902663faa
[2024-04-15 11:53:50] f333333016aaa296f46e781c0aad2bf4cd579b753aaab52562aaaaaaaaaaaaaa1555a555511593d5fd4
[2024-04-15 11:53:55] f333333016aaa296f46e781c0d5ad40832a8126d62aaaaa98eaaaaaaaab0aaaab5555555555572af015
[2024-04-15 11:53:59] ccccccc05aaa8a5bd1b9e07aaad6a04e6a9413962aaa8dee95555555555555555555caaa9aa9c0a7f54
[2024-04-15 11:54:03] f99999980b55514b7a373c0f52a52bf632a831e53aaaa3835aaaaaaaaaaaaaaaaaaaaaaaaaaa258a02a8
[2024-04-15 11:54:07] 0ccccccc05aaa8a5bd1b9e07ad5295fb19541dca9d55564644aaaaf5555955574aaaa2aaaaaa0b950150
[2024-04-15 11:54:12] f99999980b55514b7a373c0f5d5d2bf7cd57c24d3aaaaa6b215556aaaa955554555556aaaaabf43afea
[2024-04-15 11:54:16] ccccccc05aaa8a5bd1b9e07a5516a0419541ed162aaaabc6eaaaaaaaaaaaaaaaaaaaaaaaaaa5f9a7f50
[2024-04-15 11:54:20] f333333016aaa296f46e781e9ba57ef9aaf84b58aaaab207eaaaaaaaa9b5556d55541555575db8f014
[2024-04-15 11:54:24] 1f99999980b55514b7a373c0f455d2bf7cd57ed9a9d555544975555555555555555555555556ac81180a8
[2024-04-15 11:54:29] ccccccc05aaa8a5bd1b9e07a15a95fbe6abe12c9d55555f7caaaab5554b5555555555555555da5d0154
[2024-04-15 11:54:33] ccccccc05aaa8a5bd1b9e07b55a95fbe6abf2f9b155557e39d5555555555555555555aaaa4d612cc054
[2024-04-15 11:54:37] ccccccc05aaa8a5bd1b9e07b6a56a04195409324eaaaaea37aaabeaaab5aaab15554e5555551081c050
[2024-04-15 11:55:33] b33333014eaaa9cb355e9d95a86f535555aaaeaaa55785a7299aa9c8380
[2024-04-15 11:57:04] ccccccc050aaaa0d2d51299aaa5555555555555c2aaaaaaaaaa7555577218d2e5563e440
[2024-04-15 12:00:30] 999b330185555069940b13552d5555555555552aaaaaaaaaaad55540c8c34ceaa86f6fc
[2024-04-15 12:04:11] 999cccc0a75549cb2bd65f2be1a2a6eaa55556a951690259da2f8780
[2024-04-15 12:08:08] 99999980a75554e5db643f57c14eaaaaaaaaaaaaaaaa150c689d5519d5f8
[2024-04-15 12:09:19] 99999980a75554cb354cd06aa4d4a6aaaaaa85551155d16234c4aa860d00
[2024-04-15 12:11:42] fe666666029d5553976ccec0aaea7355555555555555550a99cbb1557b5efc
[2024-04-15 12:13:06] f333333014eaaa9cb34c967aa5968aaaaaaaaaaaaaaaa9d77cb335510f100
[2024-04-15 12:15:17] 99999980a75559cb3544d06a88eb5f5544aaecaa5155d165cb3b55ebae00
[2024-04-15 12:15:20] fccccccc053aaaa72ed8a27eabf348aaaaaaaaaaaaaaaaf56e344eaad53100
[2024-04-15 12:18:54] fffccccccc053aaaa72cd53b41a8b1b2d2aa95552d547aa8baf72ced5484540
[2024-04-15 12:31:05] fffd999980a75554eb691e984addd054aaaaaaa8aaac550552eb6a4ac83380c
[2024-04-15 12:34:34] fff3333330142aaa8292dc2cf6aaaaaaaaaaaaaaad555555555556eaaaac8b3d6d6958cb5018
[2024-04-15 12:36:27] ffecccccc053aaaa75b4b9315a8d4d55aaaaaaaaaaaaaa82aa0a4a254ee8c00
[2024-04-15 12:43:10] e666666029d5553966de155d4ae795eaaa6aaf95596abe13b966d54a1e200
[2024-04-15 12:44:11] 999999814eaaa9cb36fd55cb1592a5555555555532af85c730d5c18300
[2024-04-15 12:51:19] ccccccc053aaaa77ffffffffffffffffffffffffffffffffffffffffffff
[2024-04-15 12:53:13] 99999b014f555396dbed5457ebe762aaaa4aaaa5757c2172db45f87600
[2024-04-15 12:56:05] fe666666029d5553966cad55d573eeaeaa81556eaa8555f0ae34c955ef50fc
[2024-04-15 13:00:16] ccccccc053aaaa72cd9555454607949554aaa92aaed541e9c6992ab86f1f8
[2024-04-15 13:07:53] ffe666666029d5553966af89b2bb966aeaaa2aab1553d5588bcb3caa646100
[2024-04-15 13:09:58] fccccccc053aaaa72cdbf155d4f1eeb9555555555555541eeb96000000
[2024-04-15 13:10:32] ccccccc053aaaa75b48fb3daa1c4d52aa82ab12a932a82ab8a4a5a9bbc400
[2024-04-15 13:11:43] fff666666029d5553966c9aaa2a82baaaaaaaaaaaaaaaabe17b966d55dfa4fc
[2024-04-15 13:22:43] 6666666029d55539696a17755e04959555555555556aa81a1e74555993100

I don't know exacty which protocol use this signals. It not seems to have the default preamble and sync used by wmbus n-band 0x55, 0xF6, and neither Wize protocol: 0x5555 preamble and 0xF672 sync. I only see in bitbench that can be aligned by 0x998

This frequency is used by telemetry water meters in my zone. Any help with decode this will be appreciated.

Thank you!

zuckschwerdt commented 5 months ago

Great find! Lots of 55 or aa in the data point to whitening: try aa or 55 in BitBench's "Xor" field, it might reveal usable data.

xjols commented 5 months ago

There is -Y filter=num to set the low-pass filtering.

The filter helps to receiver the packets and decoded now!

Where I can find all the options of RTL_433? The option -Y filter=num is not in help Thank you very much!

zuckschwerdt commented 5 months ago

There are some experimental options which are not mentioned in the help. The features are either not user-friendly enough or we might not support the option in some next version. The source is in parse_conf_option() at https://github.com/merbanan/rtl_433/blob/master/src/rtl_433.c#L878

gdt commented 3 months ago

Answered question.