Using http output, is the stats page not working yet? Also, "i2c wr failed=-9" and more bugs with the webpage. - And the number of signals received and recorded by rtl_433 is incomparable: Are there KNOWN problems in highly populated areas?

[LtqxWYEG]

The stats page doesn't seem to work: It only says "Gathering stats... Please wait"

Amount of devices and time waited do not matter. Never shows anything.

---

Why are some of the dots in the level graph green and some red?

These are all red but one. (And about half are encrypted smoke detectors...)
On 433 Mhz much more are green.
I have like 200 devices here around me and using the webpage, it is impossible to find out what the green dot is actually referencing. There should be some work done on the monitor page. Maybe sorting methods for list?

It's a ~20min long graph.

---

Only about a tenths or so of all signals here seem to be detected/recorded by rtl_433.

• I use "-Y autolevel" which seemed to have increased the numbers - as you can see in the image above where I activated it after the first 5 minutes or so; The short pause, and then lower dB signals appeared. I've read that in a different issue.
• And I've tuned the gain to where the most seem to turn up.
• I played with "-Y" and the best is either "minmax" or "auto", identical to "-Y minsnr=1"
• And on top of that, 1.536MSps has the best SNR with my Rafael Micro R828D tuner, RTL-SDR Blog V4, but I assume 1.2MSps is no different and there is no indication that rtl_433 cares about sample rate when it is bigger than needed. Also using 1.200 over 1.536 does not increase detections.

Just look at this image of all the signals I receive within only a 8 second time interval: (Meaning this waterfall is 8s long)
rtl_433 shows maybe 5 of those, not more.

Even assuming that only the strongest signals are showing up, literally ALL signals that are received anyway are consistently garbage:

These are even done with 1.2MSps, if you think that was the problem.

08:32:24 | Wireless-MBus | C | TCH | 4929034 | 148 | 8 | Heat Cost Allocator | 68 | 88 | 574468503490920494088c00d6900f002c25ea8c11008de32d5f2aa844e07aea003007107c8d3b777f32734635b5d18a100c20d1b6215a899ae33ccef39fd5e225dfec4d70b35c02f92d018c1ed24a67878ca9110fe1a88b | CRC | 140 | 0 | 0 | 0 | 618124076387684.500 m3/min | 150253200.000 kkg/h | 65344.393 Wh | 8.140 W | 1007.000 J/h | 7332857.700 MJ | 3523618922949.300 MJ/h | -11.900 C | 15345.000 kl/s | FSK | 868.90381 | 869.00429 | -16.4271 | 15.30316 | -31.7303 | 382

And if you say an RSSI of -16.4271 and SNR of 15.30316 is too low for actual information, here is one device that arrives with -5. Both packets of the same device as well, but one is shorter:
08:32:13 | Wireless-MBus | C | TCH | 667806 | 82 | 55 | Radio converter (meter side) | 68 | 55 | 364468500678660052377247614432a85cfe07da002025154725c8acb26da96e2d8161d4ead6068cdcb3056f2eba9b6d30007ffc1dc525 | CRC | 114 | 0 | 0 | 0 |   | 182.900 GJ/h | 0.050 m3/min | none | FSK | 868.90522 | 868.98611 | -4.68253 | 30.47197 | -35.1545 | 356

08:32:18 | Wireless-MBus | C | TCH | 667806 | 82 | 55 | Radio converter (meter side) | 68 | 87 | 564468500678660052377247614432a85cfe07da0040054d1f68e5c4fb6d1acf775618eaa296a9f7ae1d82f0055779b10c87cd120acb6c8bc64131b2967e4b39b8cff74111cc1524d553dbb4d48a4aa93ceb1ccfd99e25 | CRC | 114 | 0 | 0 | 0 | 440100343.912 m3/min | 182.900 GJ/h | 0.050 m3/min | none | FSK | 868.91213 | 868.99494 | -6.55711 | 29.56649 | -36.1236 | 370

One above 0 RSSI:
08:31:59 | Wireless-MBus | T | TCH | 23226141 | 105 | 128 |   | 68 | 51 | 32446850416122236980a0119f311700703924001107e606000000000400000000000000000000000000000003000015080000 | CRC | 160 | 0 | 0 | 0 | 20.584 m3/min | 0.340 K | 11552.000 bar | FSK | 868.90125 | 868.99891 | 0.90673 | 36.12334 | -36.1236 | 335

And what's the point of the CRC flag if CRC doesn't work? Seemingly...

---

Best results I got are with these settings, but those are also what I am complaining about:

.\rtl_433.exe -v -t biastee -f 868.95M -s 1200k -g auto -Y auto -Y autolevel -p -2 -C native -F http -F log (Yes, it makes a difference that I added "-Y auto" to "-Y autolevel".)

rtl_433 version 25.12 branch  at 202512121350 inputs file rtl_tcp RTL-SDR SoapySDR
...
SDR: Found 1 device(s)
SDR: trying device 0: RTLSDRBlog, Blog V4, SN: 00000001
Found Rafael Micro R828D tuner
RTL-SDR Blog V4 Detected
SDR: Using device 0: RTLSDRBlog, Blog V4, SN: 00000001, "Generic RTL2832U OEM"
SDR: Sample rate set to 1200000 S/s.
Input: Bit detection level set to 0.0 (Auto).
SDR: Tuner gain set to Auto.
SDR: Frequency correction set to -2 ppm.
Input: Reading samples in async mode...
SDR: Tuned to 868.950MHz.
Baseband: low pass filter for 1200000 Hz at cutoff 240000 Hz, 4.2 us
Auto Level: Estimated noise level is -18.1 dB, adjusting minimum detection level to -15.1 dB
Auto Level: Estimated noise level is -20.1 dB, adjusting minimum detection level to -17.1 dB
Auto Level: Estimated noise level is -21.4 dB, adjusting minimum detection level to -18.4 dB
Auto Level: Estimated noise level is -22.8 dB, adjusting minimum detection level to -19.8 dB
Auto Level: Estimated noise level is -24.5 dB, adjusting minimum detection level to -21.5 dB
...

Here is me testing different settings to see what results in the most detections:

• So, "-g" should either be tuned ("28" looks good) or set to "auto". I don't really think it makes a difference: Looks like both result in the same amount, just that "auto" is compressing everything to the top.
• "-Y autolevel" always has to be added to whatever else you choose for "-Y" even if it sounds stupid or redundant. Only when "minlevel" is set will "autolevel" not work.
• Using rtl_433_64bit_static.exe instead of rtl_433.exe does not change things.

---

The units are broken:

What even is "kkg/h" and "kl/s"? Are you randomly adding the k-prefix to data, even those that already has one? "kkg" is nonsense; Either make it "Mg" or use metric tons "t".
Is "kl/s" 1000 liter per second? Why would there be both Liter and m³ in the same packet? 1 Liter is 0.001 Cubic meter so "kl/s" would ACTUALLY be equal to "m³/s"!! Aaaaah!

It does not matter if I define "-C si" or "-C native", both make no sense.

---

Just a question:

BTW, what is that on lower right? Here is a closer and much faster view of a similar signal: (1 second or faster)

This just seems unreasonably hard to decode. Why diagonals??

[zuckschwerdt]

The stats page needs the -M stats option active and takes at one interval to gather the first stats.

The color of the dots indicates OOK vs FSK.

The -Y auto option (as opposed to -Y classic / -Y minmax) is default. If you needed it then likely a config file already applied a different setting.

The scaling of values with units is indeed broken. The unit is not taken into account when scaling the value. Something to be fixed.

The last signal you show looks like LoRA-type. Those lines are calls chirps and are the data symbols.

[LtqxWYEG]

Ok. Thank you for the answer :)

• The thing with the "-M stats" should be mentioned on the stats page so that this is no question. Maybe even add a toggle on the page if you want.
• A legend on the level graph would be cool too, so that, again, this is no question.
• Clicking on "250,000kS" switches it to 1MS, but clicking on the frequency does not switch back and forth anything

---

Other bugs I can maybe report:

• The webpage somewhat crashes when I choose any kind of "show RAW" setting. Actually, the browser console shows that the script is running in an infinite loop, it seems, and thus the page is never updated until you cancel script execution by pressing the homepage button and going back in history. I say that because at the end of this procedure you only see one RAW entry in the list and all the data in the browser console is identical. (I am using newest Firefox version on Windows.)
  This just repeats infinitely.

• The syslog shows nothing. What is it supposed to show? The browser console output?

• Stats still won't work with "-M stats"

• There are problems with updating the settings or communicating with the RTL_SDR when changing frequency or sampling rate. It does not seem to update and devices from 433 will shows up with a frequency of 868 in the data.

• Not using the RTLSDR Blog V4 version of "librtlsdr.dll" will not allow the website to change anything ever, however, even though the same error i2c wr failed=-9 reg=0b len=1 occurs, it will eventually switch when using the V4 version of the dll. I thought maybe also changing the "libusb-1.0.dll" would fix it, but no.

---

Using .\rtl_433.exe -v -t biastee -f 433.92M -s 250k -g auto -Y auto -Y autolevel -p -2 -C native -M stats -F http -F log on an RTLSDR Blog V4 dongle with the correct "librtlsdr.dll" (for V4), here you can see that stats still won't work and that syslog does not show either browser console or command interface output, and all the "i2c wr failed=-9" errors despite it changing the settings in the dongle - as can be seen in the level graph.

---

Other issues:

• I have problems reaching triq.org using my VPN. Is there maybe a way to not use third-party websites for loading scripts? Maybe include them in the exe folder?
• Any ideas why rtl_433 detects so few signals even though there are ten times more?

[ivanbistrovic]

Other issues:

• I have problems reaching triq.org using my VPN. Is there maybe a way to not use third-party websites for loading scripts? Maybe include them in the exe folder?
• Any ideas why rtl_433 detects so few signals even though there are ten times more?

I am not using VPN but I cannot reach the "-F http" output since it depends on opening the script on that web page.
My ISP is behind the Carrier Grade NAT so it might be that the problem is on my side, otherwise I don't know what else can prevent me from opening this page.

[LtqxWYEG]

Converted from issue
This discussion was converted from issue #3432 on December 28, 2025 15:26.

Ok, but aren't these issues with the program? I am not discussing, rather reporting.

If you already know all that, then keep the issues that have been reported about this until fixed or add an self-made issue with a list of what shouldn't be reported again.

You know, I'm sorry that I wrote it so vitriolic. It is christmas and I hate the world and every stupid one in it. (It's a kind of self-hate, but also all encompassing) However if you don't want people to report actual bugs, then just keep turning bug reports into discussions... It has a distinct "fuck you" feeling. xD

[gdt]

You should include a message next time when converting an issue.

Why? This is obviously a help request, not a bug report, and should have been a discussion all along. It seems obvious that an issue->discussion conversion is for that reason. As I understand it, the old URL redirects, and subscriptions to the issue carry over, so it doesn't cause anyone participating in the discussion any problems. It does remove a non-issue from the list of issues. Without constant attention, that list grows and it's already borderline incomprehensible on a good day.

[LtqxWYEG]

*blink

[zuckschwerdt]

The "syslog" tab (rtl_433 log messages) is fixed now.

[LtqxWYEG]

Oh, so it was broken? It had a bug? Weeeiiird... guy said to me: "This is obviously a help request, not a bug report"

[zuckschwerdt]

The web ui is a small demo of rtl_433's http api, there are lot's of bugs.
To your help request of missed signals, unsuccessful wmbus decodes and i2c errors with the hardware I hope someone actively using wmbus can chime in.