HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
merbanan
rtl_433
C2014–2026
merbanan / rtl_433

rtl_433

Program to decode radio transmissions from devices on the ISM bands (and other frequencies)

30Distinct people
39Mentions
0Explicit recommenders
7.9KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Program to decode radio transmissions from devices on the ISM bands (and other frequencies)

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year39 dated mentions

Observed mentions: 2014-07-25 12:19:32 UTC to 2026-08-31 18:34:08 UTC.

024682014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20142015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments20202021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 8 mentions; 1 submissions, 7 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 8 mentions; 0 submissions, 8 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 6 mentions; 0 submissions, 6 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC101
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC000
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC202
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC202
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC101
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC202
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC303
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC817
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC808
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC303
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC202
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC606
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC110

From the project README

An excerpt from the repository, fetched Nov 12, 2026.

Read the project’s introduction
rtl_433 rtl_433 (despite the name) is a generic data receiver, mainly for the 433.92 MHz, 868 MHz (SRD), 315 MHz, 345 MHz, and 915 MHz ISM bands. The official source code is in the https://github.com/merbanan/rtl_433/ repository. See also a list of software that works with rtl_433 in the wiki. For more documentation and related projects, particularly those that help with rtl_433 development, see the https://triq.org/ site. It works with RTL-SDR and/or SoapySDR. Actively tested and supported are Realtek RTL2832 based DVB dongles (using RTL-SDR) and LimeSDR (LimeSDR USB and LimeSDR mini engineering samples kindly provided by MyriadRf), PlutoSDR, HackRF One (using SoapySDR drivers), as well as SoapyRemote. Building rtl_433 is written in portable C (C99 standard) and known to compile on Linux (also embedded), FreeBSD, MacOS, and Windows systems. Older compilers and toolchains are supported as a key-goal. Low resource consumption and very few dependencies allow rtl_433 to run on embedded hardware. Most common 32-bit and 64-bit CPU architectures like amd64, arm64, armhf, i386, ppc64el, riscv64, s390x and others are well supported. See BUILDING.md Installation Linux (Debian, Ubuntu): sudo apt install rtl-433. For other distributions see repology or pkgs.org. FreeBSD: pkg install rtl-433. MacOS: brew install rtl_433. Docker images with rtl_433 are available on the github page of hertzg. How to add support for unsupported sensors See CONTRIBUTING.md. Running rtl_433 -h A "rtl_433.conf" file is searched in "./", XDG_CONFIG_HOME e.g. "$HOME/.config/rtl_433/", SYSCONFDIR e.g. "/usr/local/etc/rtl_433/", then command line args will be parsed in order. = General options = [-V] Output the version string and exit [-v] Increase verbosity (can be used multiple times). -v : verbose notice, -vv : verbose info, -vvv : debug, -vvvv : trace. [-c <path>] Read config options from a file = Tuner options = [-d <RTL-SDR USB device index> | :<RTL-SDR USB device serial> | <SoapySDR device query> | rtl_tcp | help] [-g <gain> | help] (default: auto) [-t <settings>] apply a list of keyword=value settings to the SDR device e.g. for SoapySDR -t "antenna=A,bandwidth=4.5M,rfnotch_ctrl=false" for RTL-SDR use "direct_samp[=1]", "offset_tune[=1]", "digital_agc[=1]", "biastee[=1]" [-f <frequency>] Receive frequency(s) (default: 433920000 Hz) [-H <seconds>] Hop interval for polling of multiple frequencies (default: 600 seconds) [-p <ppm_error>] Correct rtl-sdr tuner frequency offset error (default: 0) [-s <sample rate>] Set sample rate (default: 250000 Hz) [-D quit | restart | pause | manual] Input device run mode options (default: quit). = Demodulator options = [-R <device> | help] Enable only the specified device decoding protocol (can be used multiple times) Specify a negative number to disable a device decoding protocol (can be used multiple times) [-X <spec> | help] Add a general purpose decoder (prepend -R 0 to disable all decoders) [-Y auto | classic | minmax] FSK pulse detector mode. [-Y level=<dB level>] Manual detection level used to determine pulses (-1.0 to -30.0) (0=auto). [-Y minlevel=<dB level>] Manual minimum detection level used to determine pulses (-1.0 to -99.0). [-Y minsnr=<dB level>] Minimum SNR to determine pulses (1.0 to 99.0). [-Y autolevel] Set minlevel automatically based on average estimated noise. [-Y squelch] Skip frames below estimated noise level to reduce cpu load. [-Y ampest | magest] Choose amplitude or magnitude level estimator. [-Y filter=<value>] Manual FM low-pass filter cutoff to separate simultaneous transmissions: us (1-9999, e.g. 20), Hz (10000+), or ratio of sample rate (0.0-1.0). = Analyze/Debug options = [-A] Pulse Analyzer. Enable pulse analysis and decode attempt. Disable all decoders with -R 0 if you want analyzer output only. [-y <code>] Verify decoding of demodulated test data (e.g. "{25}fb2dd58") with enabled devices = File I/O options = [-S none | all | unknown | known] Signal auto save. Creates one file per signal. Note: Saves raw I/Q samples (uint8 pcm, 2 channel). Preferred mode for generating test files. [-r <filename> | help] Read data from input file instead of a receiver [-w <filename> | help] Save data stream to output file (a '-' dumps samples to stdout) [-W <filename> | help] Save data stream to output file, overwrite existing file = Data output options = [-F log | kv | json | csv | mqtt | influx | syslog | trigger | rtl_tcp | http | null | help] Produce decoded output in given format. Append output to file with :<filename> (e.g. -F csv:log.csv), defaults to stdout. Specify host/port for syslog with e.g. -F syslog:127.0.0.1:1514 [-M time[:<options>] | protocol | level | noise[:<secs>] | stats | bits | help] Add various meta data to each output. [-K FILE | PATH | <tag> | <key>=<tag>] Add an expanded token or fixed tag to every output line. [-C native | si | customary] Convert units in decoded output. [-n <value>] Specify number of samples to take (each sample is an I/Q pair) [-T <seconds>] Specify number of seconds to run, also 12:34 or 1h23m45s [-E hop | quit] Hop/Quit after outputting successful event(s) [-h] Output this usage help and exit Use -d, -g, -R, -X, -F, -M, -r, -w, or -W without argument for more help = Supported device protocols = [01] Silvercrest Remote Control [02] Rubicson, TFA 30.3197 or InFactory PT-310 Temperature Sensor [03] Prologue, FreeTec NC-7104, NC-7159-675 temperature sensor [04] Waveman Switch Transmitter [06]* ELV EM 1000 [07]* ELV WS 2000 [08] LaCrosse TX Temperature / Humidity Sensor, TX5U rain gauge [10] Acurite 896 Rain Gauge [11] Acurite 609TXC Temperature and Humidity Sensor [12] Oregon Scientific Weather Sensor [13]* Mebus 433 [14]* Intertechno 433 [15] KlikAanKlikUit Wireless Switch [16] AlectoV1 Weather Sensor (A
Read the full README on GitHub

What Hacker News says

39 sources
Receiving 433Mhz sensor data using rtl_433[0] with an RTL SDR was a lot of fun when I started doing it last year. There's MQTT output if you want to send it to Home Assistant, et. al., as well as simple text output to stdout. It was great fun seeing my neighbors' sensors, tire pressure sensors in passing vehicles, etc. There a ton of devices that use 433Mhz. You can also extend rtl_433 pretty easily. [0] https://github.com/merbanan/rtl_433
In Things you can do with a Software Defined Radio (2024)
Or buy a complete weather station which includes an anemometer. I have this one and it works well (although not for measuring light rainfall): https://shop.ecowitt.com/en-gb/products/wittboy Less fun because nothing can be build, although the transmitted data conforms to standards and can be processed with for example https://github.com/merbanan/rtl_433. So one can gather all data with a simple dongle and process that with a RPi.
In Measure wind speed and direction with ultrasonic anemometer and Arduino
Why wait? Those fancy weather stations often transmit to the indoor LCD display using fairly simply messages sent in the 433 MHz band or the 915 MHz band. For many those message formats have been reverse engineered and decoders for them added to open source SDR software such as rtl_433 [1]. With a $30 USB RTL-SDR and rtl_433 you can then use the sensor units from many of those fancy units as inputs to your own display and analysis software. And you can often use your neighbors' sensors too. One of my neighbors--I still haven't figured out which--has an AcuRite 5-in-1 system and I can see its readings using my RTL-SDR and rtl_433. If you build your own sensors it is cheap and easy to add a 433 MHz transmitter and define your own message format. Rtl_433 can be extended to cover new message formats by giving it a config file that describes t
Read the rest
he formats. There's a driver for Weewx to let it use rtl_433 [3]. You can get an RTL-SDR and rtl_433 now, and start playing around with whatever sensors others in your neighborhood happen to have. [1] https://github.com/merbanan/rtl_433 [2] https://www.acurite.com/shop-all/weather-instruments/weather... [3] https://github.com/matthewwall/weewx-sdr
In Building a weather station
> I recall reading about retailers using license plate scanning in their parking lots in the early aughts. Yep, that technology is called ANPR - automatic number plate recognition. Outputs a license plate, state, date/time, and gps coord of scanner. > They also pick up the unique IDs from the wireless air pressure monitor chips in your tires. That's called TPMS, tire pressure monitoring system. There is 1 device per tire, which emits temp, pressure, serial#, and other data. You can decode this for yourself with https://github.com/merbanan/rtl_433 and a RTL-SDR.
In Forget Milk and Eggs: Supermarkets Are Having a Fire Sale on Data About You
I have an RTL-SDR that collects sensor data via rtl_433 [0] and publishes it to MQTT, which I use for temperature and contact sensors. I found it interesting that I pick up a fair amount of TPMS data from (what I presume are) people driving by. {"time":"2022-08-03 08:25:13","model":"Schrader","type":"TPMS","flags":"ab","id":"555551E","pressure_kPa":267.5,"temperature_C":57.0,"mic":"CRC"} {"time":"2022-08-06 04:53:23","model":"Schrader","type":"TPMS","flags":"d5","id":"2F656AA","pressure_kPa":585.0,"temperature_C":120.0,"mic":"CRC"} {"time":"2022-08-06 06:15:29","model":"Schrader","type":"TPMS","flags":"af","id":"4BAAC5B","pressure_kPa":227.5,"temperature_C":35.0,"mic":"CRC"} {"time":"2022-08-08 10:24:43","model":"Schrader","type":"TPMS","flags":"af","id":"553AAD5","pressure_kPa":232.5,"temperature_C":120.0,"mic":"CRC"}
Read the rest
{"time":"2022-08-08 10:35:39","model":"Schrader","type":"TPMS","flags":"5a","id":"AAB8576","pressure_kPa":452.5,"temperature_C":43.0,"mic":"CRC"} {"time":"2022-08-08 10:58:22","model":"Schrader","type":"TPMS","flags":"ad","id":"6FF5667","pressure_kPa":427.5,"temperature_C":56.0,"mic":"CRC"} {"time":"2022-08-09 21:34:49","model":"Schrader","type":"TPMS","flags":"6a","id":"BAD22B2","pressure_kPa":212.5,"temperature_C":132.0,"mic":"CRC"} {"time":"2022-08-09 23:31:35","model":"Schrader","type":"TPMS","flags":"6a","id":"AB5E5B6","pressure_kPa":545.0,"temperature_C":163.0,"mic":"CRC"} {"time":"2022-08-10 16:49:55","model":"Schrader","type":"TPMS","flags":"57","id":"B56AED6","pressure_kPa":427.5,"temperature_C":36.0,"mic":"CRC"} {"time":"2022-08-11 00:58:24","model":"Schrader","type":"TPMS","flags":"ab","id":"DF44AAB","pressure_kPa":452.5,"temperature_C":187.0,"mic":"CRC"} {"time":"2022-08-11 01:36:15","model":"Schrader","type":"TPMS","flags":"aa","id":"AB55552","pressure_kPa":432.5,"temperature_C":35.0,"mic":"CRC"} {"time":"2022-08-13 08:27:24","model":"Schrader","type":"TPMS","flags":"54","id":"5555553","pressure_kPa":425.0,"temperature_C":120.0,"mic":"CRC"} {"time":"2022-08-16 10:48:29","model":"Schrader","type":"TPMS","flags":"aa","id":"B552AAA","pressure_kPa":425.0,"temperature_C":123.0,"mic":"CRC"} (Note: IDs munged just in case they're sensitive). I can't speak to the quality of data -- for what it's worth I do live on a regional road with a high speed limit, so it's understandable there would be some hot tires. However theses could also just be poor quality sensors, bad signals, or bugs in rtl_433. Even aside from the obvious things like carrying around and using apps on a cell phone, it's amazing to realize how much information everyone leaks just going about their day. I've not investigated anything about how frequently or reliably these signals are sent, but it does seem feasible this could get used for vehicle presence detection or even short-range tracking. [0] https://github.com/merbanan/rtl_433
In Solving my truck’s TPMS sensor problem with the help of an RTL-SDR dongle

Showing the 15 most recent of 39 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.