Is there a way to delay (or gate) the rx audio somehow, for 100ms or so, to simulate how an audio delay stage works in a traditional repeater control, in order to eliminate squelch tails?
Eric
K2CB
The answer, if you're using simpleusb, is no. However, usbradio has the rxsquelchdelay parameter in /etc/asterisk/usbradio.conf, which does exactly this.
Squelch tails really bug me, so I use usbradio on all my ASL3 nodes, after changing all the filters, because I think the defaults are too restrictive in both directions, except the radio-less ones, where simpleusb works better, especially since I use a footswitch, so you'll never hear any kind of mechanical noise when I unkey.
I think there is a github issue about adding rxsquelchdelay in simpleusb.
If you happen to be using an RTCM board with a good, commercial receiver set to flat audio, then squelch tails are pretty much a non-issue.
Unless I'm missing something...
Squelch delay is for preventing ping-pong with controller/interface/linking stuff
Audio delay is for squelch crash elimination
rxaudiodelay=0
; default value is 0
; rx audio delay for squelch tail elimination.
; Squelch tail delay in 20ms frames. Values range
; from 0 (no delay) to 24 (480ms delay)
; Typical values would range from 5-10 (100-200ms)
I believe in ASL3 it's:
rxsquelchdelay = 60 ; delayline in ms carrier squelch tail eliminator
1 Like
So rxsquelchdelay is actually a delay in audio, not squelch? If so, seems to be a poor naming choice... Need some clarification from people that know more than me.
Not sure - I'll have to dig a bit further. I don't see any references to rxaudiodelay anywhere in the current code.
I don't know about old ASL versions, but rxaudiodelay is a HamVoIP thing, available in both their version of simpleusb and usbradio, and it is a value in frames, not MS like rxsquelchdelay in usbradio, which is not part of simpleusb in ASL3. rxaudiodelay in HamVoIP serves the same purpose as rxsquelchdelay in ASL3/usbradio, which is to insert a delay line to truncate X MS of audio at the end of a transmission, which can effectively eliminate squelch tails from radios sent to the node.
Has there been any further consideration to implement the equivalent of rxsquelchdelay into chan_simpleusb?
I see a few past postings referring to GitHub PR #s 404, 429, etc... Has anything come of it?
Is there any plan to introduce this (or an equivalent feature) into simpleusb?
Currently playing around with a few SA818 based duplex repeater hotspots, as well as a few GM300 mobile radio nodes, and it is quite annoying to be passing the squelch tail noise burst upstream to the rest of the repeater network, which has gone through great measures to eliminate all squelch crash garbage on the various repeaters and links.
Similarly, I tried to use a node itself to act as the repeater controller, but without the equivalent of the rxsquelchdelay (or rxaudiodelay), it was an unacceptable solution. I wound up leaving the repeater controller in place and connecting the node to the link port, which results in a nice clean signal, with no dekeying artifacts being passed upstream.
I have tried a few times now to implement usbradio, and while the squelch tail elimination works great, the audio settings seem to be a little finicky, and overall simpleusb just seems to work better in that regard.
Eric
K2CB
Another upvote for this. I have usbradio working pretty well for my needs, with all the filters as open as I can make them, and lots of manual configuration editing.
Aside from the lack of rxsquelchdelay, usbradio has some quite audible aliasing on the high end of node TX audio. It is not as noticeable in the other direction because of the low sampling rate being used.I am not the only one who has mentioned this on the forum, and a couple of people have come to me personally asking if I noticed. Yes, I definitely have, and my ears are by far not what they used to be.
It is definitely much harder to configure usbradio, though, when properly configured, at least most of the time, can provide a better experience, radio-less nodes aside, and in some cases, literally all you need is the delay line that is not present in simpleusb.
The HamVoIP version of simpleusb is cleaner with its filtering, has an optional delay line, and I know of at least a few repeater owners who have gone back to using it as a controller instead of ASL3 specifically for those reasons.
I would contribute to this if I understood how, but coding is not where I live.