I am using a cloud RPi install of ASL3 on Akamai Linode. I have 7-10 other repeaters/node connecting to this hub. Whenever a user unkeys from one of these other repeaters/nodes I am getting a digital sound squelch crash as the user unkeys. The Hub hangtimer is set to zero. I have been running ASL2 on a Vultr cloud install and never had this before. All of the connected repeaters/nodes are running HamvoiP. I have read about a problem mixing ASL2 and ALS3 software but don’t know if that would be a problem in my setup. Anyone else seeing something similar or have a suggestion as to maybe a setting in ASL3 that I’m not familiar with? Any help or suggestions are appreciated.
The only thing I might be able to fruit on this is that when a connected node has a slow squelch gate and a crash it we are to call it that,
You will have one on that transmission as well.
If it was a local radio node, there are some timers you may be able to adjust to minimize or even eliminate it.
But a slow squelch gate is a slow squelch gate.
But when it is other nodes, you have no control. You are at that nodes mercy to correct or make changes. You only have control of your node.
Can you be more specific about this, perhaps recording and posting the audio? This is not something I would expect. There are many radioless hub nodes out there (including 2 of mine) and this is not something I’ve heard of before.
Is the sound similar to the sound of the flip of a rubber band? Is the closest analogy I can come up with.
I’ve heard the “thump/twang” noise that you described as a rubber band flinging on some hotspot-type nodes.
Yes rubber bands is the perfect fit for it, that’s exactly what it sounds like
I’ve heard that on repeaters, too, with all ASL versions going way back.
Adding a short delay (rxsquelchdelay) in usbradio, or rxaudiodelay on HamVoIP’s version of simpleusb), will typically get rid of squelch crashes, which also usually stops that odd effect from happening, but I have also occasionally heard it mess up speech if a user unkeys too soon, and still doesn’t have a squelch crash. Insert something about frame boundaries or something…
In either case, though, the hub receiving the packets shouldn’t affect this, and has no way to compensate for it. It just passes them on. All that would be done on the transmitting node side.
The problem is that if the connected nodes do it, he is stuck with that on his hub
unless you use a time delay and slice off the last xx milliseconds of the transmission.
Which is how we got rid of normal slow squelch gate like used on some Micor’s variable gate that slow on weak signal.
But I have seen perhaps something similar where the network bandwidth was an issue.
Asterisk pretty touchy on late packets. And sounds likely.
In any case, you have to nail down the source before you can attempt action.
What we need is rxsquelchdelay for SimpleUSB
1 Like
This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.