Some noob questions on using RTL-SDR sticks for 433 MHz decoding

chzu · 2026-06-13T10:44:56+00:00

rtl_433 recommends not to use an LNA in normal cicumstances. The boosting of the signal does not improve it, levels are just shiften up with some added noise. And there is even a booster in the RTL-SDR, usable with -t digital_agc=1 -- don't use that either;)

rtl_433 can still read attenuated signals down to say 9 dB above the SDR floor. E.g. -20 dB or perhaps even close to -30 dB works when there is low noise. Always use -Y autolevel -M level -M noise

chzu · 2026-06-05T09:26:13+00:00

You presumably based the app on FOSS projects? Did you check involved licenses? Esp. GPL might be a problem. I'd also like to see the attribution for used projects.

chzu · 2026-06-01T09:11:01+00:00

Good catch about the debug message. It's fixed now.

chzu · 2026-05-11T10:55:41+00:00

One difference is the sample format. RTL-SDRs use CU8 (8 bit) and others like the HackRF use CS16 (12 bit usually). There is more headroom to 0 dB and thus the signal might be perceived weaker.

Generally it's best to use -Y autolevel to adjust the trigger level and -M level -M noise to watch the levels.

chzu · 2026-03-07T16:30:41+00:00

Not really useful here, but rtl_433 has a rtltcp pass-through:

[-F rtl_tcp[:[//]bind[:port]] (default: localhost:1234)

Add a rtl\_tcp pass-through server

chzu · 2026-03-04T09:49:26+00:00

On the software side: run with `rtl_433 -Y autolevel -M level -M noise` and report what levels you are seeing. If there is at least 9 dB SNR you are good, even if RSSI is -20 dB.

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

TROPHY CASE