PL decode enhancements

[jmlzone]

PL decode needs several enhancements. (Can be broken into multiple issues) 1) pl tones and levels should be configurable via an init file or command line options. 2)tone unlock should only occur after multiple cycles of missed decode.

[scivision]

This is a subtle yet very important area where OEMs like Motorola distinguished themselves from HT to repeater. CTCSS IC details

Since this is software based, we can get a lot smarter about the environment each repeater is in. Does it suffer from co-channel users on different (or the same) tone? Are most of the signals strong or weak? For weak signals, fading signals, particular dynamic algorithms can be employed far more effective than the choices implemented in hardware squelch ICs.

There is a delay, distinct between different models of radios, for CTCSS code from the repeater. Thus a false negative causes annoying audio dropouts at the user receiver, which should be avoided. The repeater receiver has the ability to know it made the wrong decision post facto and this can be used as feedback to learn a better response for each signal. Yes, ML for squlech.

[jmlzone]

FYI it is currently configured to decode 8 tones. There is a reason behind this, actually several. 1) On some repeaters there may be control operator tones which allow the operator to enter commands without first entering a control op code.
2) We may (do) want to implement some automatic linking. IE you come in to the repeater with time 1 and its a local repeater. You use tone 2 and you are link to xxx and you use tome 3 and you are linked to yyy. 3) on our hub repeaters we may accept multiple tones, then the tone on each link can be different. If we are getting interference on a link, the tone will tell us which link the interference was coming into.

There is some outline of this in the code related to softCtcss in the radioPort RX class.