add some sort of list of which decoders are known to use which frequencies

[gdt]

Many decoders are for devices on 433.92 MHz. But a number seem to be for 315 MHz, and others perhaps other frequencies. Perhaps this is more about national regulations, but it would be nice to have a clue in the decoder list, perhaps codes in parentheses, of which channels they use. Something as simple as (348) meaning 315, 433, 868 could help, but perhaps reality is too complicated for this to be sensible.

[zuckschwerdt]

I'd like to get more info in the first few comment line in each decoder. Like frequency seen on. Then I can transfer that to the output. PR to those comments/docs very welcome.

[zuckschwerdt]

I would like to make quiet mode the default (verbose=0), make -q print a warning and do nothing. Introduce -v, common in many programs (no -v =quiet, -v some normal notices, -vv =verbose, -vvv =debug, -vvvv =trace). And make -D print a warning and set one level higher than -v.

Objections?

[merbanan]

I'm not sure that is optimal (quiet by default). IMO the default out of the box output should contain data that makes it easy to debug user issues for me as a developer. I don't want to risk getting user questions that states that they start rtl_433 and don't get any output. What we have now is not optimal so a rework is welcome but I'd like to make it user friendly and developer friendly out of the box when you run the software without any arguments.

For example right now we should replace the list of protocols with a single line that that says the total amount of available decoder, the amount of activated decoder and the amount of inactive decoders.

When users file a bug report they should be able to add the command line and ca 20 lines of output. That makes it easy to quickly understand the situation and give advice based on that.

[zuckschwerdt]

Oops. My comment was meant for #915

But yes, the first output should be: version, active decoders of known decoders, perhaps a list. Maybe like

rtl_433 version 18.05-352-gc8d1383 branch feat-kvnew at 201812151310
Active decoders 88 of 119 (3 flex):
[02 03 04 08 11 12 15 16 17 18 19 20 21 23 25 26 29 30 31 32 33 34 35 36 38
 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 62 63 64
 66 67 68 69 70 71 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 92
 93 94 95 96 97 98 99 100 102 103 108 109] 

We could shorten the list by smartly joining ranges, like

rtl_433 version 18.05-352-gc8d1383 branch feat-kvnew at 201812151310
Active decoders 88 of 119 (3 flex):
[02-04 08 11-12 15-21 23 25-36 38-60 62-71 73-90 92-100 102-103 108-110]

[zuckschwerdt]

918 will adresses the above comments (not the original issue).

[gdt]

I commented on the PR before seeing this, but I see that what I said pretty much matches what @merbanan said.

[gvanem]

Can we also please have the decoder number printed in the KV-output. In shining colours.

It's now not clear which number a Toyota TPMS have. If I want to know if my neighbour's Toyota is parked outside, I must do:

rtl_433.exe -R? |& grep Toyota
[88]  Toyota TPMS
[110]  PMV-107J (Toyota) TPMS
rtl_433.exe -f433.90M -R88 -R110 -c NUL

Too complicated. Instead if a previous KV-output had those numbers 88, 110 listed, I'd use those numbers directly the next time.

[zuckschwerdt]

-M protocol should work. No shining colors though :/ (But last in top line, should be ok to spot).

[zuckschwerdt]

or do you mean in source code? We probably should fix the protocol numbers in the r_device someday, yes.

[gvanem]

-M protocol should work. No shining colors though

I see. Trying that, I do get Protocol : 88 with 88 in green. Fine for me.

But the cmd-line options are very confusing. Printing those in colours too would help.

[zuckschwerdt]

Keeping this open as reminder to add structured comments with device info into the decoders.

[matthiasseemoo]

I would have a related but slightly different request. Could you please extend the r_device struct with a pointer to an array of frequencies on which a decoder generally works. Then, you could only apply those decoders to an input signal that falls in the applicable frequency range, which should reduce computational overhead and false positions when trying to decode signals with all decoders. Another switch could be added to simply use all decoders. Even if the frequency information would not be used like this, it is still meaningful to have it in a machine readable way, instead of putting it into comments.

[merbanan]

@matthiasseemoo @evilpete looked into this but came to the conclusion that there was no significant cpu time spent on trying to decode. The demodulators consumed most of the cpu time. Reducing false positives might make it worth it though. I am not against this type of feature but I will probably not have time to implement it. I find it more easy to fix the checksum or identify the false positive in a better way.

[zuckschwerdt]

Somebody could create .conf files with protocols enabled per frequency range. Note that e.g. TPMS will be on different frequencies in different countries.

I'd say there's generally two opposite ends on usage:

• Exploring: grab everything possible off the air
• Automation: track fixed set of know devices

I don't think there are many users in the "middle".

[evilpete]

@matthiasseemoo @evilpete looked into this but came to the conclusion that there was no significant cpu time spent on trying to decode. The demodulators consumed most of the cpu time. Reducing false positives might make it worth it though. I am not against this type of feature but I will probably not have time to implement it. I find it more easy to fix the checksum or identify the false positive in a better way.

in my (non conclusive) cpu usage tests decoders were so insignificant they most didn't even show up (less then 4 significant digits) unless they got a hit, and even then they were orders of magnitude lower in cpu usage then the demodulation

[gdt]

As issue creator, I'm declaring that this issue is about adding structured documentation to the decoders so that people can get an answer to "on what frequencies is this device believed to appear". I'm leaving out "don't enable decoder if not on that frequency" as separate scope, and note that there has been a general opinion that it's not a good idea, or not useful.

[zuckschwerdt]

There might be overlap with #2611 (have a device database)

[gdt]

I'm calling this a dup of #2611 after having edited its title.