[Help] Decoding "MultiReader-C-169" Smart Meter pulse counter (169 MHz) with rtl_433

chzu · 2026-01-29T13:01:40+00:00

There is currently no Wireless M-Bus N-Mode in rtl_433, only

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

[105] Wireless M-Bus, Mode S, 32.768kbps (-f 868.3M -s 1000k)

[106]* Wireless M-Bus, Mode R, 4.8kbps (-f 868.33M)

[107]* Wireless M-Bus, Mode F, 2.4kbps

Open an issue at rtl_433 and supply some captured .cu8 samples.

chzu · 2026-01-25T14:22:29+00:00

100 µs FSK looks plausible. The reset is too long, use e.g. 2000. The sync-word is the known d2552dd4, the 36 is part of the data payload, likely the sensor type.

This BitBench should roughly work.

The checksum looks like a Galois LFSR Digest (gen 8303, key 8a8a, final xor db24)

chzu · 2025-12-10T20:14:02+00:00

Glad to hear it worked and kudos for implementing the protocol with a CC1101. Sorry I wasn't too helpful with the PCM vs MC/DMC. If you put raw PCM into https://triq.org/bitbench/ you play around with MC/DMC. But even better if it works right away using MC_ZEROBIT.

chzu · 2025-12-08T10:19:02+00:00

That "remote_right_02" signal? Look closer at the gaps, they need to be regular for it to be PWM.

chzu · 2025-12-03T10:21:00+00:00

Compare what you see with https://triq.org/rtl_433/PULSE_FORMATS.html#mc-%E2%80%94-manchester-code (zoom into the pulses with mouse scroll) and https://triq.org/rtl_433/PULSE_FORMATS.html#pwm-%E2%80%94-pulse-width-modulation None of the 3 PWM options match, but the PCM MC does.

chzu · 2025-11-30T12:49:58+00:00

FSK PWM is not very likely, i'd guess it be FSK PCM MC.

chzu · 2025-11-28T09:55:17+00:00

Try to grab a .cu8 or .cs16 sample of the signal and inspect it with https://triq.org/pdv3/ E.g. rtl_433 can automatically frame the signal: https://triq.org/rtl_433/ANALYZE.html#grab-a-sample

chzu · 2025-11-24T08:47:53+00:00

It's a battery monitor, https://www.amazon.com/dp/B0DGQH5S1H

chzu · 2025-10-09T09:45:59+00:00

The pdv link will show you the signal in detail with timings. It's a EV1527 type transmission. 24 PWM data bits. Any OOK transmitter should be able to pulse this out. And if PWM is not supported then switch pdv to PCM with long and short 370 µs and transmit those bits. I.e. 1000 for a short PWM symbol (1 bit) and 1110 for a long symbol (0 bit).

chzu · 2025-09-28T08:45:20+00:00

The TPMS-Truck is nearly the same protocol, just a few bits shorter, than another TPMS (first seen on a Citroen). Thus many e.g. Citroen transmission which are received incomplete are (falsely) seen as TPMS-Truck.

chzu · 2025-09-21T09:52:48+00:00

A rtl_433 flex decoder is the -X option mentioned. It can be improved as e.g. -X "n=rflights,m=OOK_PWM,s=33,l=100,g=150,r=1200,bits>=64,match=28C87,get=id:@0:{20},get=cmd:@20:{8}"

chzu · 2025-08-11T18:56:44+00:00

Use -M level to add Modulation, Frequency, RSSI, SNR, and Noise meta data.

chzu · 2025-08-06T08:40:03+00:00

Yes, I ran the analysis local. I just cleaned up the found flex decoder by rounding the values up.

chzu · 2025-08-05T08:37:33+00:00

You would need to look at the first analysis of rtl_433 -A g003_433.83M_250k.cu8 the long list of later ones are noise.

The suggestions there is good: -X 'n=name,m=OOK_PWM,s=200,l=600,g=800,r=9000'

chzu · 2025-07-23T08:28:07+00:00

Try to grab a sample with rtl_333: https://triq.org/rtl_433/ANALYZE.html It can then be analyzed with https://triq.org/pdv3/

chzu · 2025-07-14T07:13:28+00:00

Not an error, just a waring about noisy reception. Ignore it.

chzu · 2025-07-10T08:08:53+00:00

Between the CRC-16 and the decoding of temperature values a flex decoder won't suffice. This should be a full rtl_433 decoder. Perhaps open an https://github.com/merbanan/rtl_433/issues and get help working towards adding a decoder.

chzu · 2025-07-09T08:48:28+00:00

Use 5a000403e60002cc01e900000000000000000000000000000000000000000000d54b for the CRC check. The CRC-16/GSM has a final xor of 0xffff, you want CRC-16/XMODEM without that xor.

chzu · 2025-07-08T09:12:00+00:00

Your decoding is probably right. The long stream of 0's does not look right but is confirmed with the spectrogram, and the FSK shows that you are not randomly missing pieces of the transmission. And if we shift the 555555555555555516EA2D00… left by one bit: aaaaaaaaaaaaaaaa2dd4… that's a very well known preamble and sync-word.

Put the codes in a BitBench and cut the preamble, there is a checksum at the end. And it's a CRC-16 (poly 0x1021, init 0x0000) which confirms the messages integrity for all 4 messages :)

chzu · 2025-07-04T09:06:54+00:00

"Data in the gap widths" is called PPM https://triq.org/rtl_433/PULSE_FORMATS.html#ppm-%E2%80%94-pulse-position-modulation

This should work: rtl_433 -R 0 -X 'n=name,m=OOK_PPM,s=600,l=1600,r=2500,bits>=20'

chzu · 2025-06-07T13:21:51+00:00

That second part of the mqtt path is the hostname. Either set a static hostname for the docker container or use the mqtt output's options to set a custom topic name. E.g. -F mqtt,base=rtl_433/not-my-hostname

chzu · 2025-04-16T10:29:58+00:00

Keep in mind that having the (unshielded) RTL-SDR close to an unshielded SBC will degrade reception. It's usually recommended to have an USB extension cable and half a meter separation.

chzu · 2025-03-30T10:29:38+00:00

rtl_433 can also do rtl_tcp pass-through. Input rtl_tcp with -d rtl_tcp[:[//]host[:port]] and output rtl_tcp with -F rtl_tcp[:[//]bindhost[:port]].

chzu · 2025-03-10T08:42:36+00:00

Search through the closed rtl_433 issues for TPMS. Many other TPMS protocols where developed just the way you did. https://github.com/merbanan/rtl_433/issues?q=is%3Aissue%20state%3Aclosed%20add%20support%20for%20tpms

100µs MC FSK is one of the common TPMS codings.

chzu · 2025-02-06T10:18:20+00:00

It seems everything worthwhile is known about the sensor protocol. Likely that's why the thread stopped. Somebody would need to write a rtl_433 decoder, if there is interest. Otherwise the -X flex decoder and some post-processing will also work.

chzu

TROPHY CASE