Replies: 3 comments 8 replies
-
|
The stats page needs the The color of the dots indicates OOK vs FSK. The 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. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
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 |
Beta Was this translation helpful? Give feedback.


Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
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?
Only about a tenths or so of all signals here seem to be detected/recorded by rtl_433.
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 | 382And 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 | 35608: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 | 370One 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 | 335And 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".)Here is me testing different settings to see what results in the most detections:

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??
Beta Was this translation helpful? Give feedback.
All reactions