chan_simpleusb: Add ability to eliminate squelch tails

[KB4MDD]

A user on community pointed out that chan_simpleusb does not have the ability to eliminate squelch tails. chan_usbradio has rxsquelchdelay which is measure in milliseconds.

Other implementations have rxaudiodelay, which is measured in frames of 20 milliseconds.

[davidgsd]

Squelch tail elimination (STE) is a great feature and also one that has very little documentation, and some subtle details in how it works. I think the first step is to define what the code can now do, ie. in each driver.
USBRadio works well in DSP mode, eg. I have a mobile radio node with flat audio out, and by setting rxsquelchdelay=10 (mS) tails are eliminated on Rx audio, and then by setting txtoctype=notone they are eliminated on Tx audio if the other radios used have tone squelch enabled. (There is also the txtoctype=phase option but that should not be needed, because any radio that can do proper tone squelch will mute audio as soon as there is no tone. From what I can see online the phase option is only needed for ancient Motorola systems that used "mechanical reeds for encode and decode. ...the decode reeds would continue to vibrate after the transmission ended... to stop this the xmtr would send an...out-of-phase ctcss tone." I highly doubt anyone is still using a Motorola radio with a mechanical reed decoder to access their node.)

SimpleUSB does not do any DSP or CTCSS tone encoding or decoding however, and to give it such capabilities would likely result in a lot of duplication of code, and be somewhat contradictory to its name. Thus it would seem that if someone would like a STE feature in SimpleUSB, what they are actually asking for is just the rxsquelchdelay delay line feature. ie. Susb would not actually do anything at all with actual squelch detection - it would merely add a delay so that when the COS/CTCSS digital inputs go inactive, RXCD and rxsquelchdelay mS of audio is dropped.

It might be good to note somewhere though that SimpleUSB depends on the connected radio(s) to do the actual CTCSS (or DCS) encode and decode, and, if those radios properly support those functions and are properly set up, there should be no need for SimpleUSB to have a delay line. To clarify this, a few examples of radios that can be used with ASL:

1. Higher-end mobile radio with flat audio I/O. Kenwood TM-V71A is a good example. I do not see any option in the manual for this radio for dropping Tx CTCSS prior to Tx unkey or reversing phase. So if this radio were used with Susb, you would probably have to use it with DCS in order for STE to properly work in both Rx & Tx directions. DCS is not supported by older radios however so that would limit the node to use from newer radios for proper STE. Thus the better option would be to use USBRadio.

2. Inexpensive ~$20 HTs. Many of these work great for node radios and are much more cost-effective than a higher-end mobile radio or ~$100 PiHat. These do not have the ability to do flat audio I/O, due to using SoC RF ICs. Thus for proper STE in both directions DCS is probably required, which won't be compatible with older radios that might be used to talk to the node. In this case, DCS then already takes care of STE (at least on a few HT models I've tested), thus a delay line in Susb may provide no benefit.

3. SA818 modules. Despite their low audio quality (40dB stated audio SNR) and usually poor RFI/EMC performance, these are probably what most AllStar nodes are using. I have not tested them but from what I can tell they have the same options as (2.) above. (No flat audio I/O, no internal delay line / DSP STE / notone/phase CTCSS options). In these cases CTCSS/DCS encode and decode can only be done the in radio and not in ASL.

Considering these common use cases, from what I understand, for true STE in both directions either USBRadio is needed with a radio supporting flat (unfiltered) audio I/Os, or DCS would need to be used in the external radios in which case a Susb delay line would not be useful. For partial STE in the Rx direction only, supporting that in Susb could be useful, but that seems like a half-step and not a particularly useful feature, and if someone wants such a feature they can already do that in USBRadio. Therefore I don't see the point of making any changes to SimpleUSB, but there may be some other use cases where it would make more sense. If so, it would be nice to know what those are.