xaelsouth / rtl-wmbus

Software defined receiver for wireless M-Bus with RTL-SDR

rtl-wmbus: software defined receiver for Wireless-M-Bus with RTL-SDR

rtl-wmbus is a software defined receiver for Wireless-M-Bus. It is written in plain C and uses RTL-SDR (https://github.com/osmocom/rtl-sdr) to interface with RTL2832-based hardware.

It can also use LimeSDR or other SDR receiver as backend through rx_sdr (see https://github.com/rxseger/rx_tools), which in turn is using SoapySDR to interface with underlying hardware in a vendor-neutral way.

Wireless-M-Bus is the wireless version of M-Bus ("Meter-Bus", http://www.m-bus.com), which is an European standard for remote reading of smart meters.

The primary purpose of rtl-wmbus is experimenting with digital signal processing and software radio. rtl-wmbus can be used on resource constrained devices such Raspberry Pi Zero or Raspberry PI B+ overclocked to 1GHz. Any Android based tablet will do the same too.

rtl-wmbus provides:

• filtering
• FSK demodulation
• dc offset removing
• clock recovering
• mode T1 and mode C1 packet decoding
• mode S1 packet decoding

rtl-wmbus requires:

• Linux or Android
• C99
• supported DVB-T receiver
• RTL-SDR library for Linux: http://sdr.osmocom.org/trac/wiki/rtl-sdr or
• (optional, only for android builds) RTL-SDR library port for Android: https://github.com/martinmarinov/rtl_tcp_andro-

For the latest version, see https://github.com/xaelsouth/rtl-wmbus

Installing

The Osmocom RTL-SDR library must be installed before you can build rtl-wmbus. See http://sdr.osmocom.org/trac/wiki/rtl-sdr for more information. RTL-SDR library for Android would be installed via Google Play.

To install rtl-wmbus, download, unpack the source code and go to the top level directory. Then use one of these three options:

• make debug # (no optimization, with all debug options on)

• make release # (-O3 optimized version, without any debugging options)

• make pi1 # (Raspberry Pi optimized version, without any debugging options, will build on RasPi1) only

Before building Android version the SDK and NDK have to be installed. See androidbuild.bat for how to build and install.

For Windows users:

• Download and install https://downloads.myriadrf.org/builds/PothosSDR/PothosSDR-2021.02.28-vc16-x64.exe

• Compile rtl-wmbus with MSYS2-MinGW just by executing make in MSYS2-MinGW-Console...

• Or use precompiled binary from the build directory

• Start in the console: "c:\Program Files\PothosSDR\bin\rtl_sdr" -f 868.95M -s 1600000 - 2>NUL | build\rtl_wmbus_x64.exe

• Optionally replace the path to rtl_sdr with that where you have PothosSDR installed

  Usage

To save an I/Q-stream on disk and decode that off-line:

• rtl_sdr samples.cu8 -f 868.95M -s 1600000
• cat samples.cu8 | build/rtl_wmbus

To save an I/Q-stream and decode this immediately to see what's going on right now:

• rtl_sdr -f 868.95M -s 1600000 - 2>/dev/null | tee samples.cu8 | build/rtl_wmbus

To run continuously without saving anything on disk:

• rtl_sdr -f 868.95M -s 1600000 - 2>/dev/null | build/rtl_wmbus

To run continuously with rx_sdr (or even with a higher sampling and decimation rate)

• rx_sdr -f 868.95M -s 1600000 - 2>/dev/null | build/rtl_wmbus
• rx_sdr -f 868.95M -s 4000000 - 2>/dev/null | build/rtl_wmbus -d 5

Notice "-d 5" in the last line: it's a multiple of 800kHz resulting from the sample rate of 4MHz.

To count "good" (no 3 out of 6 errors, no checksum errors) packets:

• cat samples.cu8 | build/rtl_wmbus 2>/dev/null | grep "[T,C,S]1;1;1" | wc -l

Carrier-frequency given at "-f" must be set properly. With my DVB-T-Receiver I had to choose carrier 50kHz under the standard of 868.95MHz. Sample rate at 1.6Ms/s should be used or use a multiple of 800kHz. RTL-SDR supports sampling rate up to 3.2 MSamples, so you can choose 1.6 MSamples, 2.4 MSamples or 3.2 MSamples.

See samples/rtlsdr_868.950M_1M6_samples2.cu8 for an example of two T1 mode devices.

On Android the driver must be started first with options given above. I/Q-data goes to a port which is to be set in the driver settings. Use get_net to get I/Q-data into rtl_wmbus.

The output data is semicolon separated and the meaning of the columns are:

MODE;CRC_OK;3OUTOF6OK;TIMESTAMP;PACKET_RSSI;CURRENT_RSSI;LINK_LAYER_IDENT_NO;DATAGRAM_WITHOUT_CRC_BYTES.

3OUTOF6OK is only relevant for T1 and can be ignored for C1 and S1 (always set to 1).

Bugfixing

Mode C1 datagram type B is supported now - thanks to Fredrik Öhrström for spotting this and for providing raw datagram samples. An another thanks goes to Kjell Braden (afflux) and to carlos62 for the idea how to implement this.

Redefining CFLAGS and OUTPUT directory is allowed now (patch sent by dwrobel).

L(ength) field from C1 mode B datagrams does not include CRC bytes anymore: L field will now be printed as if the datagram would be received from a T1 or C1 mode A meter.

Significantly improved C1 receiver quality. Sad, but in the low-pass-filter was a bug: the stopband edge frequency was specified as 10kHz instead of 110kHz. I have changed the latter to 160kHz and recalculated filter coefficients.

Packet rssi value fixed for S1 mode (was always 0): thanks to alalons.

Improvements

A new method for picking datagrams out of the bit stream that could probably better perform in C1 mode has been implemented. I called that "run length algorithm". I don't know if any similar term already exists in the literature. The new method is very sensitive to bit glitches, which have to be filtered out of the bit stream with an asymmetrical deglitch filter. The deglitch filter must be implemented asymmetrical in this case, because RTL-SDR produces more "0" bits than "1" bits on it's output. The latter seems more to be a hardware feature rather than a bug.

Run length algorithm is running in parallel (and is fully independant) to the time2 method. You will eventually get two identical datagrams, where each has been decoded by its own methods. If you really want avoiding duplicates, then start rtl_wmbus with "-r 0" or "-t 0" argument to prevent executing of run length or time2 method respectively. You can play with arguments and check which method performs better for you. Please note, that both methods are active by default.

The advantage of the run length algorithm is that it works without IIR filter (which are needed only for clock recovery by time2 method). Therefore the run length algorithm can be applied to all RF ICs providing raw demodulated signal without clock in the "transparent serial mode" like TI CC1125 (swru295e.pdf, 8.7.2) does.

An additional method introduces more calculation steps, so I'm not sure if Raspberry Pi 1 will still work with that.

Run length algorithm works well with a few mode C1 devices I had around me, but can still be improved with your help.

S1 mode datagrams can now be received! You have to start rtl_wmbus at 868.3MHz with

• rtl_sdr -f 868.3M -s 1600000 - 2>/dev/null | build/rtl_wmbus

Last but not least, you can try to receive all datagrams (S1, T1, C1) simultaneously:

• rtl_sdr -f 868.625M -s 1600000 - 2>/dev/null | build/rtl_wmbus -s

Notice in the last line:

• "-s": which is needed to inform rtl_wmbus about required frequency translation
• "868.625M": the new frequency to receive at

rtl_wmbus will then shift all frequencies

• by +325kHz to new center frequency at 868.95Mhz (T1 and C1)
• by -325kHz to new center frequency at 868.3Mhz (S1)

I have tested this so far and can confirm that it works for T1/C1 and S1. Thanks to alalons for providing me with bitstreams!

Optimization on frequencies translation by rearranging compute steps implemented as proposed by alalons.

Alalons (have I thanked you already?!) proposed a speed optimized arctan function. Performance gain is notable (factor ~2) but could reduce sensitivity slightly. I have seen that on receiving C1 mode datagrams - that's why the speed optimized version is not in use by default. A speed optimized arctan version can be activated by "-a" in the program options.

A new options "-o", which means "remove dc offset", was introduced. The overall sensitivity is better without removing dc offset, so the user may try to start rtl_wmbus with this option if no datagrams comes:

• cat samples/rtlsdr_868.950M_1M6_issue47.cu8 | build/rtl_wmbus -o
• cat samples/rtlsdr_868.950M_1M6_issue49.cu8 | build/rtl_wmbus -o
• cat samples/rtlsdr_868.625M_2M4_issue48.cu8 | build/rtl_wmbus -d 3 -s -o

License

Copyright (c) 2024 [email protected]

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

rtl-wmbus's Issues

Data is not being read

Issue not exists any more!
Sorry

cannot build on fresh debian (Linux Mint)

I try to build the package, but I get the following error:

cwempe@mint:~/rtl-wmbus$ make
gcc -DNDEBUG -O3                  -Iinclude -std=gnu99 -Wall -W -Waggregate-return -Wbad-function-cast -Wcast-align -Wcast-qual -Wchar-subscripts -Wcomment -Wfloat-equal -Winline -Wmain -Wmissing-noreturn -Wmissing-prototypes -Wparentheses -Wpointer-arith -Wredundant-decls -Wreturn-type -Wshadow -Wsign-compare -Wstrict-prototypes -Wswitch -Wunreachable-code -Wunused -Wuninitialized -o "build/rtl_wmbus" rtl_wmbus.c -lm 
In file included from rtl_wmbus.c:37:
atan2.h: In function ‘atan2_approximation2’:
atan2.h:48:11: warning: comparing floating point with == or != is unsafe [-Wfloat-equal]
   48 |     if (x == 0.0f)
      |           ^~
atan2.h:51:15: warning: comparing floating point with == or != is unsafe [-Wfloat-equal]
   51 |         if (y == 0.0f) return 0.0f;
      |               ^~
In file included from rtl_wmbus.c:39:
t1_c1_packet_decoder.h: At top level:
t1_c1_packet_decoder.h:252:5: warning: no previous prototype for ‘get_mode_a_tlg_length’ [-Wmissing-prototypes]
  252 | int get_mode_a_tlg_length(uint8_t lfield)
      |     ^~~~~~~~~~~~~~~~~~~~~
t1_c1_packet_decoder.h:257:5: warning: no previous prototype for ‘get_mode_b_tlg_length’ [-Wmissing-prototypes]
  257 | int get_mode_b_tlg_length(uint8_t lfield)
      |     ^~~~~~~~~~~~~~~~~~~~~
rtl_wmbus.c:47:14: warning: ‘lp_1600kHz_56kHz’ defined but not used [-Wunused-function]
   47 | static float lp_1600kHz_56kHz(int sample, size_t i_or_q)
      |              ^~~~~~~~~~~~~~~~

I have only little experience with compiling software.
So maybe I am doing something wrong.

My system is a freshly installed Linux Mint 20 x64.

S1 packages with rtl-wmbus

Hi there,
Can i get S1 packets with rtl-wmbus?
if yes, how?

I appreciate your help.
p.s.: i sent an email btw.

Test with IZAR RC 434 I R4

I would like to try with the module IZAR RC 434 I R4 model - 434MHz.

The following command didn´t work:
rtl_sdr -f 434M -s 1600000 - 2>/dev/null | build/rtl_wmbus

Can you help me?

rtl-sdr.com

amiplus frames not decoded

I have an Apator EMU3 meter that's not being picked up by rtl_wmbus. I have recorded some communication which gets picked up by rtl_433 but not rtl_wmbus:

kosma@banana:~$ rtl_sdr -p 69 -f 868.95M -s 1600000 - > rtlsdr_868.95M_1M6_amiplus_notdecoded.bin
kosma@banana:~$ rtl_wmbus -s 1600000 < rtlsdr_868.95M_1M6_amiplus_notdecoded.bin
kosma@banana:~$ rtl_433 -s 1600000 -r rtlsdr_868.95M_1M6_amiplus_notdecoded.bin
rtl_433 version 23.11-102-gf97830fa branch master at 202404071907 inputs file rtl_tcp RTL-SDR SoapySDR
[Input] Test mode active. Reading samples from file: rtlsdr_868.95M_1M6_amiplus_notdecoded.bin
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : @0.778431s
model     : Wireless-MBus Mode      : T            Manufacturer: APA         ID        : 86012081
Version   : 2            Device Type: 0x02         Device Type String: Electricity                     Control   : 0x44          Data Length: 95           Data      : 5c4401068120018602027a000050050c0b9cf0f94e1fe6999ff82b6a92b2c89a333185193d7f66b8d4af75b12f688acbbe8d3dc994ee43cd1eb2b7ae42326d188c2dbed49ca6b3c85b35f2d07ea99982bd697261de298d516c25c6e410f7731f7d
Integrity : CRC
Control Info: 0x7A       Access number: 0x00       Device Type: 0x00         Configuration Word: 0x0550 Payload Encrypted: 1

Offending file: rtlsdr_868.95M_1M6_amiplus_notdecoded.bin.zip

Additionally, the message parsed by rtl_433 won't decrypt with the Tauron-supplied key, but I guess that's a separate issue that we can tackle once the demodulation and decoding works?

Please tag releases

Tagging releases will make it easier for those packaging this in Linux distributions. An interesting view on release numbering can be found in http://joeyh.name/blog/entry/version_numbers/ .

cannot recover corrupted preamble

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?

Orange Pi zero

Hi!

Unfortunatly all options to make the rtl-wmbus failed on a Orange Pi zero.
Could you pls provide guidance on what I could use?

Will continue with the raspberry pi and the windows version.

thx.

-x-

me@orangepizero:~/ rtl-wmbus$ make debug # gcc -msse4.2 -DDEBUG -O0 -g3 -ggdb -p -pg -Iinclude -std=gnu99 -Wall -W -Waggregate-return -Wbad-function-cast -Wcast-align -Wcast-qual -Wchar-subscripts -Wcomment -Wfloat-equal -Winline -Wmain -Wmissing-noreturn -Wmissing-prototypes -Wparentheses -Wpointer-arith -Wredundant-decls -Wreturn-type -Wshadow -Wsign-compare -Wstrict-prototypes -Wswitch -Wunreachable-code -Wunused -Wuninitialized -o "build/rtl_wmbus" rtl_wmbus.c -lm gcc: error: unrecognized command line option ‘-msse4.2’ Makefile:22: recipe for target 'debug' failed make: *** [debug] Error 1 domo@orangepizero78:~/rtl-wmbus$

me@orangepizero:~/ rtl-wmbus$ make pi1 # gcc -DNDEBUG -O3 -march=armv6 -mtune=arm1176jzf-s -mfloat-abi=hard -mfpu=vfp -ff ast-math -Iinclude -std=gnu99 -Wall -W -Waggregate-return -Wbad-function-cast -W cast-align -Wcast-qual -Wchar-subscripts -Wcomment -Wfloat-equal -Winline -Wmain -Wmissing-noreturn -Wmissing-prototypes -Wparentheses -Wpointer-arith -Wredunda nt-decls -Wreturn-type -Wshadow -Wsign-compare -Wstrict-prototypes -Wswitch -Wun reachable-code -Wunused -Wuninitialized -o "build/rtl_wmbus" rtl_wmbus.c -lm In file included from /usr/include/endian.h:60:0, from /usr/include/arm-linux-gnueabihf/bits/waitstatus.h:64, from /usr/include/stdlib.h:42, from rtl_wmbus.c:28: /usr/include/arm-linux-gnueabihf/bits/byteswap.h: In function ‘__bswap_32’: /usr/include/arm-linux-gnueabihf/bits/byteswap.h:45:1: sorry, unimplemented: Thu mb-1 hard-float VFP ABI { ^ In file included from rtl_wmbus.c:37:0: atan2.h: In function ‘atan2_approximation2’: atan2.h:48:11: warning: comparing floating point with == or != is unsafe [-Wfloa t-equal] if (x == 0.0f) ^ atan2.h:51:15: warning: comparing floating point with == or != is unsafe [-Wfloa t-equal] if (y == 0.0f) return 0.0f; ^ In file included from rtl_wmbus.c:38:0: net_support.h: In function ‘get_net’: net_support.h:17:12: warning: missing initializer for field ‘sin_addr’ of ‘struc t sockaddr_in’ [-Wmissing-field-initializers] struct sockaddr_in address = {.sin_family = AF_INET, .sin_port = htons(port ^ In file included from /usr/include/arpa/inet.h:22:0, from net_support.h:7, from rtl_wmbus.c:38: /usr/include/netinet/in.h:243:20: note: ‘sin_addr’ declared here struct in_addr sin_addr; /* Internet address. */ ^ rtl_wmbus.c: At top level: rtl_wmbus.c:43:23: fatal error: immintrin.h: No such file or directory compilation terminated. Makefile:26: recipe for target 'pi1' failed make: *** [pi1] Error 1

no result with rx_sdr

I using sdrplay.
Command line is: rx_sdr -d "driver=sdrplay" -g IFGR=20,RFGR=0 -f 868.95M -s 1000k - | rtl_wmbus_x86
No output but there are many wmbus equipment in area. rtl_433 decode it well.
Samples attached.

Using rtlsdr all works
samples.zip
.

Resource requirements of rtl-wmbus

Hi! I am interested in how much CPU power and RAM rtl-wmbus requires for operation. Has anyone ever measured those?
If not, I guess I could get into it and post the results.

For months I've been using an older (yet quite powerful, i7 based) laptop to log my water / energy consumption but I know this is a waste of energy and resources. Since Raspberry-Pi's have recently become quite expensive I started looking for a cheaper solution (also, possibly without the unnecessary devices onboard - after all only CPU + RAM + net + a bit of mass storage are needed to do the job; audio/video sub-systems are unnecessary).

I envision the whole system to consist of several cheap boards processing RF and forwarding data (possibly from the output of wmbusmeters) over Wi-Fi and then a central processing unit to gather everything and store in some flavour of a HA solution with a DB for archiving purposes.
Hope this makes sense.

Kamstrup FlowIQ 2102 (Multical 21) in 923 MHZ - mode C1

Hello. Does rtl-wmbus can read and decode packets of a 923 Mhz Kamstrup FlowIQ 2102? I have tried to get any packets at all and don't get any telegrams. Could it be the sample rate? I have been able (testing with rtl_433 with its analysis option) to get packets on 923 Mhz FSK NRZ demodulation every 16 and 96 seconds, but can't get to decode them. Is there a way to try this in RTL-WMBUS?

Thanks in advance for reading and giving any input.

capturing s1 and c1,t1 simultaneously?

I wonder if it would be possible to capture and decode all those modes simultaneously.
You could rise sampling rate to acommodate both frequencies.
Then it would be neccesary to convert to baseband in software with each center frequency creating two signals to be processed.
Or something like that.

atan2 approximation issue

I commented on atan2 approximation. Wonder if this makes any difference.

PACKET_CAPTURE_THRESHOLD vs collision detection

When I use the original value of PACKET_CAPTURE_THRESHOLD (5) I tend to get no readings from my water meter.
It used to work in the winter - then I observed higher values in wmbusmeters' rssi_dbm field. They were oscillating around 10. Now (springtime) they are lower and seem to get lower than 5.
I can see this #define is used as follows:

// Stop receiving packet if current rssi below threshold.
// The current packet seems to be collided with an another one.
if (rssi < PACKET_CAPTURE_THRESHOLD)
{
   reset_t1_c1_packet_decoder(decoder);
}

However, when I lower the value of PACKET_CAPTURE_THRESHOLD to e.g. 2 - I can see almost every packet (I believe the meter TX period is 8 seconds). My case is probably somehow strange - the meter is located ~2.7m underground and 12-15m away from the antenna (which already is a 10-element Yagi - without it I could not pick up anything from my meter). Another two meters are just on the other side of the fence, also underground (same depth, I think) and the distance from my RX antenna is similar (perhaps 2-3m further away). The RSSI reported by wmbusmeters is much higher, though. I think it was in the 30-40 range last time I checked (a long time ago).

There are also plenty of more distant water meters I can pick up with this directional antenna I use (so those are strong enough!), so I would expect many collisions to take place often enough.

It might be my meter's RF transmitter is broken and thus TX is weak (the meter is quite new - only 1.5 years old and its battery status indicates no issues with the battery).

But I am not sure why lowering the value of the above #define makes rtl-wmbus work as expected. After all, collisions should be occurring equally often, should they not? Strangely, despite any possible collisions I see my own telegrams as expected and I get almost all of them. How come?

Add support for N1 and N2 169MHz wmbus telegrams. #10

do you plan to read the 169MHz narrow-band wm-bus?
marco

Higher CPU utilization from 27% to 65% between 6a04c45 and cce47b6 on RPi4B+

In response to #8 (comment) I updated the package in fedora from 6a04c45 to cce47b6. I'm running rtl-wmbus alongside with wmbusmeters on RPi4B+ and noticed a substantial increase in CPU utilization between those two revisions:

6a04c4548245c4f6adaad6348ee4d2deef825d63 27%
cce47b67b7d84ca7ef685c7e0fbd853114f3f605 65%

Here is the CPU utilization during git bisect:

d603a3b4ce34f68068a305a423384a23280a7411 68%
6d92d1b3f150e0b609f7505e9135495fabb274fc 29%
8ac790dc16eb20ed301873c018e54623a44b4a5e 75%
a517da71d12e2d548e93117f828356f4fe49bc5a 29%
8bec4a2b0860d0adad3183367fdf1be99e017c65 47%

Here is the culprit (8bec4a2):

$ git bisect bad
8bec4a2b0860d0adad3183367fdf1be99e017c65 is the first bad commit
commit 8bec4a2b0860d0adad3183367fdf1be99e017c65
Author: Xael South <[email protected]>
Date:   Tue Feb 2 17:29:08 2021 +0000

    C1 mode improvements; S1 mode implemented

 README.md                                          |   8 +
 ...bp_iir_cheb1_400kHz_90kHz_98kHz_102kHz_110kHz.m |  29 ----
 filter/lp_fir_butter_800kHz_100kHz_10kHz.m         |  15 --
 rtl_wmbus.c                                        | 169 ++++++++++++++++-----
 t1_c1_packet_decoder.h                             | 152 +++++++++---------
 5 files changed, 209 insertions(+), 164 deletions(-)
 delete mode 100644 filter/bp_iir_cheb1_400kHz_90kHz_98kHz_102kHz_110kHz.m
 delete mode 100644 filter/lp_fir_butter_800kHz_100kHz_10kHz.m

For the record the git bisect log:

$ git bisect log
git bisect start
# bad: [cce47b67b7d84ca7ef685c7e0fbd853114f3f605] Support MinGW and Win
git bisect bad cce47b67b7d84ca7ef685c7e0fbd853114f3f605
# good: [6a04c4548245c4f6adaad6348ee4d2deef825d63] Mode C1 datagram type B is supported now
git bisect good 6a04c4548245c4f6adaad6348ee4d2deef825d63
# bad: [d603a3b4ce34f68068a305a423384a23280a7411] Add information about column meanings.
git bisect bad d603a3b4ce34f68068a305a423384a23280a7411
# good: [6d92d1b3f150e0b609f7505e9135495fabb274fc] rx_sdr
git bisect good 6d92d1b3f150e0b609f7505e9135495fabb274fc
# bad: [8ac790dc16eb20ed301873c018e54623a44b4a5e] C1 receiver with better filtering
git bisect bad 8ac790dc16eb20ed301873c018e54623a44b4a5e
# good: [a517da71d12e2d548e93117f828356f4fe49bc5a] C1 mode improvements; S1 mode implemented
git bisect good a517da71d12e2d548e93117f828356f4fe49bc5a
# bad: [8bec4a2b0860d0adad3183367fdf1be99e017c65] C1 mode improvements; S1 mode implemented
git bisect bad 8bec4a2b0860d0adad3183367fdf1be99e017c65
# first bad commit: [8bec4a2b0860d0adad3183367fdf1be99e017c65] C1 mode improvements; S1 mode implemented

Is this increase in CPU utilization fully expected? If so, please close this issue, otherwise maybe it would be possible to reduce the CPU usage.

FYI, I've used the old version for quite a long time and it worked flawlessly for me, so maybe it's possible to add some command line option which will reduce the number of computations and still keep the filtering quality on the satisfactory level with the old CPU utilization?

Caloric 5.5 is not seen

Hi,
my new Q caloric 5.5 meters are not seen by rtl_wmbus.
They can be received by the SDR dongle with:
rtl_433 -f 868.625M -s 1024k

---

time : 2021-11-27 08:53:22
model : Wireless-MBus Mode : C Manufacturer: QDS ID : 96615935
Version : 53 Device Type: 0x08 Device Type String: Heat Cost Allocator Control : 0x44
Data Length: 74 Data : 47449344355961963508780dff5f3500824b0000100007b06effff00000000ffff00000000ffff000000000080008000800080008000800080008000800080008000802f046d3a08bb2b0a38
Integrity : CRC
Control Info: 0x78 Access number: 0x00 Device Type: 0x00 Configuration Word: 0x0000 Volume flow[1]: 0.093 m3/min
Power[1] : 89904776.900 MJ/h

---

time : 2021-11-27 08:53:47
model : Wireless-MBus Mode : T Manufacturer: TCH ID : 72500832
Version : 105 Device Type: 0x80 Device Type String: Control : 0x44 Data Length: 51 Data : 30446850320850726980a0919f290000b03708006e067c06080000000000000000000000000000000000000000000000000000ffff
Integrity : CRC
Control Info: 0xA0 Access number: 0x00 Device Type: 0x00 Configuration Word: 0x0000 Err Volume flow[0]: 20.584 m3/min
Err Energy[0]: 29264.000 J Min Energy[1]: 0.000 Wh Power[0] : 0.000 J/h Energy[0]: 0.000 Wh

---

time : 2021-11-27 08:54:11
model : Wireless-MBus Mode : C Manufacturer: QDS ID : 26867779
Version : 53 Device Type: 0x08 Device Type String: Heat Cost Allocator Control : 0x44
Data Length: 74 Data : 47449344797786263508780dff5f3500826300007f0007b06effff00000000ffff00000000ffff000000000080008000800080008000800080008000800080008000802f046d3608bb2b021d
Integrity : CRC
Control Info: 0x78 Access number: 0x00 Device Type: 0x00 Configuration Word: 0x0000 Volume flow[1]: 0.093 m3/min

The Techem with T1 Protocol shows up fine, but the 2 Caloric with C1 protocol are not reported by rtl_wmbus
running
rtl_sdr -f 868.625M -s 1600000 - 2>/dev/null | rtl_wmbus -s
shows only the Techem

I use the latest release from github and I am using wmbusmeters for further processing.

Any help would be great
Thanks
Ralf

What does the data from rtl_wmbus output mean?

Hi,

I would like to know what does the output data of rtl_wmbus mean. Specifically, there is T1;1;1.... and I would like to understand what 1;1 means and why it is the only valid telegram? In documentation there is "To count "good" (no 3 out of 6 errors, no checksum errors) packets:" and specifies to grep just for 1;1, but what is the problem with 0;1, 1;0 and 0;0?

Building on Raspberry Pi B rev 2 ARMv6

Hi
I'm having problems compiling this package:

pi@raspberrypi:~ $ git clone https://github.com/xaelsouth/rtl-wmbus.git
Cloning into 'rtl-wmbus'...
remote: Enumerating objects: 58, done.
remote: Total 58 (delta 0), reused 0 (delta 0), pack-reused 58
Unpacking objects: 100% (58/58), done.
pi@raspberrypi:~ $ cd rtl-wmbus/
pi@raspberrypi:~/rtl-wmbus $ make pi1
gcc -DNDEBUG -O3 -march=armv6 -mtune=arm1176jzf-s -mfloat-abi=hard -mfpu=vfp -ffast-math -Iinclude -std=gnu99 -Wall -W -Waggregate-return -Wbad-function-cast -Wcast-align -Wcast-qual -Wchar-subscripts -Wcomment -Wfloat-equal -Winline -Wmain -Wmissing-noreturn -Wmissing-prototypes -Wparentheses -Wpointer-arith -Wredundant-decls -Wreturn-type -Wshadow -Wsign-compare -Wstrict-prototypes -Wswitch -Wunreachable-code -Wunused -Wuninitialized -o "build/rtl_wmbus" rtl_wmbus.c -lm
In file included from rtl_wmbus.c:37:
atan2.h: In function ‘atan2_approximation2’:
atan2.h:48:11: warning: comparing floating point with == or != is unsafe [-Wfloat-equal]
     if (x == 0.0f)
           ^~
atan2.h:51:15: warning: comparing floating point with == or != is unsafe [-Wfloat-equal]
         if (y == 0.0f) return 0.0f;
               ^~
In file included from rtl_wmbus.c:39:
t1_c1_packet_decoder.h: At top level:
t1_c1_packet_decoder.h:252:5: warning: no previous prototype for ‘get_mode_a_tlg_length’ [-Wmissing-prototypes]
 int get_mode_a_tlg_length(uint8_t lfield)
     ^~~~~~~~~~~~~~~~~~~~~
t1_c1_packet_decoder.h:257:5: warning: no previous prototype for ‘get_mode_b_tlg_length’ [-Wmissing-prototypes]
 int get_mode_b_tlg_length(uint8_t lfield)
     ^~~~~~~~~~~~~~~~~~~~~
rtl_wmbus.c:47:14: warning: ‘lp_1600kHz_56kHz’ defined but not used [-Wunused-function]
 static float lp_1600kHz_56kHz(int sample, size_t i_or_q)
              ^~~~~~~~~~~~~~~~
/usr/bin/ld: cannot open output file build/rtl_wmbus: No such file or directory
collect2: error: ld returned 1 exit status
make: *** [Makefile:26: pi1] Error 1

This is a clean folder with proper rights:

pi@raspberrypi:~/rtl-wmbus $ ls -l
total 3340
-rwxr-xr-x 1 pi pi     476 Nov 27 19:35 androidbuild.bat
-rw-r--r-- 1 pi pi    1561 Nov 27 19:35 atan2.h
-rw-r--r-- 1 pi pi 1048576 Nov 27 19:35 demod.bin
drwxr-xr-x 2 pi pi    4096 Nov 27 19:35 filter
-rw-r--r-- 1 pi pi    2931 Nov 27 19:35 fir.h
-rw-r--r-- 1 pi pi    2377 Nov 27 19:35 iir.h
drwxr-xr-x 3 pi pi    4096 Nov 27 19:35 include
-rw-r--r-- 1 pi pi    1009 Nov 27 19:35 Makefile
-rw-r--r-- 1 pi pi    2260 Nov 27 19:35 moving_average_filter.h
-rw-r--r-- 1 pi pi     966 Nov 27 19:35 net_support.h
drwxr-xr-x 2 pi pi    4096 Nov 27 19:35 pics
-rw-r--r-- 1 pi pi    3295 Nov 27 19:35 ppf.h
-rw-r--r-- 1 pi pi    4218 Nov 27 19:35 README.md
-rw-r--r-- 1 pi pi  174065 Nov 27 19:35 readme.pdf
-rw-r--r-- 1 pi pi   18071 Nov 27 19:35 rtl_wmbus.c
-rw-r--r-- 1 pi pi 2097152 Nov 27 19:35 samples2.bin
-rw-r--r-- 1 pi pi   23336 Nov 27 19:35 t1_c1_packet_decoder.h

Any hint on that?
Thanks

Putting WMBus telegram into fhem

I'm playing now with your software and decoding WMBus telegrams with fhem software. It's possible but running it continuously require some dirty tricks:
'''
rtl_sdr -f 868.9M -s 1600000 - 2>/dev/null | build/rtl_wmbus | grep "[T,C]1;1;1" | awk -F ";" '{print $8'}| sed -e 's/0x/b/' > /opt/fhem/CUL_fifo
'''
Could you please consider adding feature to put RAW (with CRC) message with '0x' replaced with 'b' (marker that it's WMBus message for fhem virtual hardware) into pipe file?

Virtual hardware in fhem should be declared like these
'''
defmod cul_emu CUL /opt/fhem/CUL_fifo@directio 3539
attr cul_emu dummy 1
attr cul_emu rfmode WMBus_T
'''

Honeywell V210 Water Meter 868MHz T1

Would we expect this device to work?

The specsheet mentions a configurable 12 second transmit interval and in sdr++ I do see transmissions every 3-10 seconds (which I presume are from the same meters installed by my neighbours).

This command does not return any results:
rtl_sdr -f 868.625M -s 1600000 - 2>/dev/null | build/rtl_wmbus -s

In sdr++ transmissions appear to start at exactly 868M (which I suppose could be something else). Using -f 868M makes not difference.

Would love a pointer in the right direction and happy to help try and contribute adding support if it's not already

Wrong behaviour on stadout

Running this command was working great

rtl_sdr -f 434.475M -s 800000 - 2>/dev/null | /usr/bin/rtl_wmbus -p s

But suddenly starts showing this.

Running this command

wmbusmeters rtlwmbus:434.475M:t1 Sappel izar ANYID ANYKEY

Shows this.

Why this happens and how i restart the rtl_wmbus service?

Why don't fork on dual mode (S1 and T1/C1 datagrams simultaneously)

Hi,
using rtl-wmbus on a Raspberry Pi 2 I've seen that cpu (a single core) goes to 100% if decoding both S1 and T1/C1... Using "-a -p T" it stay around 65%.

Since the Raspberry is multicore, why the software does not "fork", with the two decoding enabled?
I've already found a workaround (I hope), using a tee and a fifo, I start two instances of rtl_wmbus one with "-s -a -p T" and one with "-s -a -P S". This seems to split the workload on two cpus :)

Is there any side effect in my way? Is there a good reason to keep it in a single thread?
Thanks in advance
\Jeky

Wmbus device , using different frequency and different transmission speed

I have a wireless mbus device that uses 915MHz and 250kbps transmission rate. It sends data in C1 format. Since it's non standard freq and speed, how would I read this? Any parameters I can change or code I can modify to accommodate this?

I tried using this command, but it never decodes any data.
rtl_sdr -f 918.5M -s 2048k - 2>/dev/null | rtl_wmbus

packet rssi always 0 in S1 mode

trying to understand difference betwen packet rssi and rssi
wmbusmeters is using packet rssi showing 0 in S1 mode.
Is it ok or needs a fix?

Filtering with hardware FIR

Hello Xael!
Reading about RTL chips there seems to be configurable FIR filters on hardware. Seems to me that would be useful to decrease CPU load.

"...Furthermore, the downsampling is configurable: how far the samplerate is lowered after the low-pass filter, which also determines the simultaneously receivable bandwidth. And part of the low-pass filter turns out to be a FIR filter with programmable coefficients, although this flexibility is not exploited by current driver software"

Just thinking loud

rtl-wmbus coredumps on a telegram

Every time rtl-wmbus is started it crashes after a number of days. This is the backtrace:

#0 0x00007ff3df10abf4 in __memmove_avx_unaligned_erms () from /usr/lib/libc.so.6
#1 0x0000556abe0fabd6 in cook_pkt (data=, datalen=1) at t1_c1_packet_decoder.h:522
#2 t1_c1_packet_decoder (bit=, rssi=) at t1_c1_packet_decoder.h:606
#3 t1_c1_packet_decoder (rssi=, bit=) at t1_c1_packet_decoder.h:577
#4 main (argc=, argv=) at rtl_wmbus.c:504
(gdb)

My guess is some "offending" datagram causes libc's memmove() function in cook_pkt() to fail.
Should it be re-created with debug version of the binary?
Datagrams are coming from the IZAR water meter.

RSSI value in dBm

Hi,

I have noticed that the RSSI values reported by rtl-wmbus are always positive. Packets received via weak signals have RSSI of around 20 or less. Packets received via strong signals have RSSI as high as 130 or more.

Is there a reasonable way to convert these values to decibel-milliwatts (dBm)?

CRC-issues

Seem to have some strange issue with CRC errors. The "10030325" is a Kamstrup flowIQ 2200 and I'm pretty sure the IDs are the same. Have tried with three different dongles including a rtlsdr-v3 and some combinations of antennas. Have received different levels of RSSI but seem unable to get a single packet with OK CRC. Any ideas?

C1;0;1;2019-12-12 17:40:03.000;8;7;10030332;0x3644372c320303103a163108f01920a85417a08312020a019d8f8af8cfad73221b05c33dfc6618a93c5a6277d1de1d5d071f8242f959c1
C1;0;1;2019-12-12 17:40:28.000;117;117;10030325;0x3644372c250303103a16ff00f01920c49674902ae43a6f88c416e528d90a0bb8bcea9de6b949f3a6b4d54183c8c99c136e707694a659c1
C1;0;1;2019-12-12 17:42:52.000;8;8;10030330;0x3644372c300303103a164320f01920afd1ead56723e577f2faf31e9fd6b860a3f5e6e78fe9847d997fd7defec2483df3e0c4e43dc159c1
C1;0;1;2019-12-12 17:43:46.000;113;116;10030325;0x3644372c250303103a160138f01920b27d02632ce5a00a92d9686d9c13ad578b579cc79c637a89724fe757bd59de898bfa469b4c0159c1
C1;0;1;2019-12-12 17:45:49.000;29;32;10030266;0x3644372c660203103a164c14f41920c4c93344c164e0f85a5fe9ba080e1f7e08c6ca62052e6437057af458c2f0ec2ab2756a20fe2b59c1

rtl_wmbus cannot read from rtl_sdr -- how to debug -- or can it use rtl_433 instead ?

Hello - I' m facing a strange problem with rtl_wmbus. The facts are ..

• rtl_433 correctly receives and decodes transmission from my Kamstrup Multical 21 water meter
  rtl_433 -f 868.625M -s 1600000 -R 104 -R 105
• rtl_sdr -f 868.625M -s 1600000 produces some output
• rtl_sdr -f 868.625M -s 1600000 | rtl_wmbus -s doesn't produce any output
• cat samples.bin | rtl_wmbus works fine (samples.bin from repo/source)

The question I now have

1. How can I further debug this ? How can I "validate" output from rtl_sdr ?
2. Could I somehow use "raw" data from rtl_433 to feed to rtl_wmbus ?

I know I can use rtl_433 as device/input for wmbusmeters (and got it working) but would prefer to use rtl_wmbus.
(Can't get correct RSSi from rtl_433)

thx a lot

-sb

Support Mode N WmBus to allow wmbusmeters project to support Honeywell TPR11 Merlin 169 WmBus

rtl-wmbus supports mode T1, mode C1 and mode S1 but not mode N as mentioned here wmbusmeters/wmbusmeters#321. With the Support of mode N wmbusmeters project could benefit from it.
All informations relative to Mode N (wmBus) are welcome to evaluate the complexity of packet decoding project of mode N.

Questions about the S1,C1,T1 combo mode.

I saw the new support for S1 mode and have a quick question.

Does rtl-wmbus receive C1/T1 telegrams better when rtlsdr is tuned to 868.95MH (with potential fine tuning)?
Or is it equally good at receiving C1/T1 telegrams if I use the new -s option and 868.7MH ?
Likewise compared to S1 telegrams and rtlsdr tuned to 868.3M.

My intent was to write logic so that: wmbusmeters rtlwmbus:c1,t1
will tune to 868.95M and wmbusmeters rtlwmbus:s1 will tune to 868.3M
and wmbusmeters rtlwmbus:c1,t1,s1 will tune to 868.7M and add -s.

But if the last c1,t1,s1 combo is just as good at receiving telegrams, then I could just
let wmbusmeters to always default to this setting and my code will be simpler.

What do you think?

wmbus Mode T: some bits look strange

I have a sample capture, that can be decoded by rtl-wmbus, but some bits look strange and 3of6ok is not ok.

$ cat 48_sample.cu8 |  rtl_wmbus -d 3 -s
T1;0;0;2024-03-26 21:22:31.000;63;69;FFFF8569;0x294468506985ffffffffffffff2f61ffffffffff0080ff000109ffffffffffffffffff009ed400ffffff

48_sample.cu8.zip

I then reported to rtl_433, that their decoder could not decode anything, now with improvements from the code from the merbanan/rtl_433/pull/2883 it decodes plausible values,

$ rtl_433/build/src/rtl_433 -s 2400k -R 104:vv -r 48_sample.cu8 
rtl_433 version 23.11-99-gf3f2e9f0 branch master at 202403262131 inputs file rtl_tcp RTL-SDR
[Input] Test mode active. Reading samples from file: 48_sample.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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
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

[pulse_slicer_pcm] Wireless M-Bus, Mode C&T, 100kbps (-f 868.95M -s 1200k)
codes     : {687}800a2aaaaaaaaaaaaaaa87a74ae38d58cacd4b6326b4d2c9b54ad8b94a732cb2d2d2752d1a5acb2c6d8d1a5acb2d62cd1ab2cb1ab4b496b4cb2cd4731ab2c9e919cb2d663a16b2d2e58b8b2cb53932b2d2b51cd00002

... which looks quite right.

But might the rtl-wmbus deocder also be imroved to decode the same?

Cannot see my kamstrup multical 21

I don't know why I cannot find my multical 21 when I try to scan for it.

What I do know:

• I do see alot of T and some few C "packages" - Dont know if packages is the right term.. perhaps frames? I dont know.

• My rtl-sdr usb is in the same room when I try to scan.

• The water company do drive by reading - they have not been in my house for yeeeears, so the meter MUST send something out.

• I've been corresponding with @weetmuts some months ago. He tried to help and I think the hardest part was that we could not tell if my meter was talking on the 868.95M frequency.. BUT! I found an old document, and I guess its some kind of proof, that says:

I'm opening this issue in hope that my meter somehow is getting 'filtered' somewhere in the code.. could that be?

A little help is much appreciated! 👍

SSE4 alternative?

The code as is does not compile on a PC without SSE4 support. My slightly older PC only supports SSE3 and I've got the code running but I was surprised that there is only #ifdef SSE4, #endif and not #else arms. Are you able to give a high level of what the SSE4 code is doing in case it's worth my writing some equivalent SSE3 code?

issue with missing telegrams form techem data4

i have a issue with missing telegrams form techem data4

captured with
rtl_sdr -d 10smartV5 -f 868.625M -s 1600000 - | tee techem_data4_868.625M_1600k.cu8 | rtl_wmbus -s

at the same time i captured with a second sdr:
rtl_433 -R 104 -R 105 -d :20Nano2Plus -f 868900000 -s 1600000 -M protocol -M level -g "" -F kv -F json:rtl_433-test-out.json
tail -f rtl_433-test-out.json | jq '. | select( .id | contains(3719685))'

wc -l rtl_433-test-out.json techem_data4_868.625M_1600k.cu8.decode
   276 rtl_433-test-out.json
   589 techem_data4_868.625M_1600k.cu8.decode

cat techem_data4_868.625M_1600k.cu8.decode | grep '3719685' | wc -l
1
cat rtl_433-test-out.json | jq -c '. | select( .id | contains(3719685))' | wc -l
3

cat techem_data4_868.625M_1600k.cu8.decode | grep '3719685' 
t2a;C1;1;1;2022-01-05 12:06:55.000;145;132;03719685;0x574468508596710394088c0085900f002c25a84a0900595833b45f776a5d7aa80030071026908a167e0db9fc2d258bab6f47e11f3131e60c151f24ad704661d8507d16e028eed2a245e18f244541bf4669a4d4b20fd96e95

cat rtl_433-test-out.json | jq -c '. | select( .id | contains(3719685))' 
{"time":"2022-01-05 13:01:10","protocol":104,"model":"Wireless-MBus","mode":"C","M":"TCH","id":3719685,"version":148,"type":8,"type_string":"Heat Cost Allocator","C":68,"data_length":88,"data":"554468508596710394088c0085900f002c25a64a0900252af850cc21981b7aa6003007104017b3f10bcb4be16c8e9f97a9e2a8e00a9f7eab5619638e69bdf5bc76d1108b469460c528fa997edfe6af3201bc42ba0fd96e958025","mic":"CRC","CI":140,"AC":0,"ST":0,"CW":0,"max_volume_flow_min_1":"618122835248107.625 m3/min","inst_energy_wh_0":"10625320.000 kWh","inst_energy_j_1":"25.000 kJ","mod":"FSK","freq1":868.916,"freq2":868.993,"rssi":-0.102,"snr":17.171,"noise":-17.273}
{"time":"2022-01-05 13:01:43","protocol":104,"model":"Wireless-MBus","mode":"C","M":"TCH","id":3719685,"version":148,"type":8,"type_string":"Heat Cost Allocator","C":68,"data_length":88,"data":"554468508596710394088c0085900f002c25a74a0900589baeb2d5365fdd7aa700300710fbf9b4432a1efd0712fe0f7fe1eea8b8b19bbe7aa6a216b50b6b7b915d2112b94a3a3bf12c61aa62bcf6f2f9871abc460fd96e95328c","mic":"CRC","CI":140,"AC":0,"ST":0,"CW":0,"max_volume_flow_min_1":"618122835248107.625 m3/min","inst_energy_wh_0":"10725320.000 kWh","inst_energy_j_1":"58.000 kJ","max_temperature_return_28":"1078143.000 C","inst_power_jh_0":"0.000 J/h","inst_volume_0":"575649494246685.250 mm3","unknown":"none","min_opertime_h_17":"639181711215.000 hours","min_volume_0":"-7.100 mm3","inst_volume_flow_h_1":"1514.100 mm3/h","min_temperature_diff_0":"1572263.100 K","err_volume_flow_h_19":"-99.690 m3/h","mod":"FSK","freq1":868.896,"freq2":868.985,"rssi":-0.111,"snr":17.133,"noise":-17.245}
{"time":"2022-01-05 13:02:16","protocol":104,"model":"Wireless-MBus","mode":"C","M":"TCH","id":3719685,"version":148,"type":8,"type_string":"Heat Cost Allocator","C":68,"data_length":88,"data":"554468508596710394088c0085900f002c25a84a0900595833b45f776a5d7aa80030071026908a167e0db9fc2d258bab6f47e11f3131e60c151f24ad704661d8507d16e028eed2a245e18f244541bf4669a4d4b20fd96e95604c","mic":"CRC","CI":140,"AC":0,"ST":0,"CW":0,"max_volume_flow_min_1":"618122835248107.625 m3/min","inst_energy_wh_0":"10825320.000 kWh","inst_energy_j_1":"59.000 kJ","max_power_jh_1":"0.000 kJ/h","mod":"FSK","freq1":868.888,"freq2":868.984,"rssi":-0.096,"snr":17.734,"noise":-17.831}```

Package in Debian?

Are you interested in having rtl-wmbus packaged in Debian? I've registered requests for packages for it and its reverse dependency in https://bugs.debian.org/998720 and https://bugs.debian.org/998721 and could help make it happen, if you are interested. See also wmbusmeters/wmbusmeters#460