I can’t seem to be able to move the remove the chicken burst after each transmission it’s the white noise that the ctcss in both the simpleusb the one i use, nor the usbradio, i tried all of the settings that i could research and it still will not torn off or quiet
any ideas??
Thanks
Ve2gfv
Could you be a little more specific about your setup? When you say chicken burst, it sounds to me like you are actually talking about squelch tail. What radio(s) are being used for the node, and what radio(s) are you using to communicate with your node? Is the node radio or radios providing CTCSS encoding/decoding, or are you using usbradio’s DSP to do that? Are we talking about the burst at the end of transmissions you send, or transmissions from your node to your radio?
Or are you talking about the old "Chicken-Burst" reverse "tone" squelch where the CTCSS is turned off before the squelch so that TSQL radios closed before the tail crash?
ok the setup is the node ic connected to a controller acting as a gm300 radio , then there is a Icom repeater that does the ctcss also a rf link that also does the ctcss i don’t need the node to do ctcss , what happens is at the end of the transmission from the radio to the node and the node to another node as a permanent link the other radio receives a white noise tail at the end of the transmission i tried to disable the ctcss but still no luck
I guess you can’t (easily) interface a URI directly with an Icom repeater? Never used one, don’t know.
A couple of suggestions:
If you don’t already have it set up like this, program your GM300 to RX/TX flat audio with no CTCSS encoding, then use usbradio to encode, using the txtoctype=notone or txtoctype=phase options, which ever one happens to work better with your repeater. For this setup, you’ll also need rxdemod=flat and txprelim = yes in usbradio.conf, either globally or for the node’s stanza. Then, carefully set the voice and CTCSS levels in usb-tune. Probably best done with a service monitor if you have one, but I’ve done it by ear.
You may also wish to investigate the rxsquelchdelay parameter for avoiding squelch crashes when your node radio stops receiving and before squelch closes. GM300’s react pretty fast, but even so, I’d still probably put a small delay on it.
Note: this won’t stop other nodes from squelch crashing, you can’t control that, really.
I would personally also open up the RX and TX LPF as far as they go. I don’t like how restricted the defaults for usbradio are.
Thanks Patrick i will try that I believe that i am using the simplusb.conf shoul i be using the usbradio.cong instead ?
Yes. Simpleusb doesn't have this capability.
This is a particular pet peeve of mine (and a rabbit hole…). If you use all Motorola equipment (node radio + portable to access it), properly configured, you should have dead-silent unkeys. The experience should be similar for other manufacturers as well, at least in the commercial space. It's when you mix them that the problems emerge because of different phase angles on the PL reverse burst.
ps. If you bring a Yaesu radio into the Motorola combination, your friends will hate you…
Yeah, that. Most amateur gear doesn’t do reverse burst at all. Lots of Chinese radios do STE, which is usually but not always a 59Hz tone. It can also be 55Hz, and I’ve seen a couple way up around 254Hz somewhere. There is no way to make a Baofeng HT not crash with other non-Chinese radios, especially in the RX direction, other than if the sending radio ends transmission with a 59Hz tone.
And don’t get me started on Yaesu.
To make matters worse, the sa818, popular with nodes because they’re cheap, puts out a 55Hz tone, which many Chinese radios don’t like, and their implementation of DCS is broken, so it’s basically impossible to not have squelch crash other than just by using a better radio, and even then, only in one direction. Otherwise, you have to compensate with a delay line or something on the node end.
Since ASL3’s simpleusb doesn’t have rxsquelchdelay, every modern clear node user comes with a built-in squelch tail when they unkey, so I hear a lot more of that on nodes than I once did.
This is why I use DCS on my own stuff whenever possible 
Alright i am now using the usradio i need to reduce the tail to the very minimum as much as i can , i can’t seem to get it down, even with lowering all these: rxsquelchdelay = 5 , Hangtime = 10, rxondelay = 0, and it is still have a tail of 2 seconds what am i missing ? i just need the tail to be very short the squelch crash i don’t care
GV
You're not going to completely eliminate squelch tails entirely if the rest of your RF/audio chain doesn't cooperate.
ok what dose this mean ? how to i get down form 3 seconds to less than 1 second all other radios has no issues
But what's generating the tail? You haven't really explained where it's coming from. What is the function of the GM300 radio vs. ASL vs. what you listed as a "controller" and where does the Icom repeater come into play? A 3s tail seems to imply that somewhere a squelch isn't closing properly but from where? Does the crash come before or after the COS/CTCSS releases when you're debugging in the tune menu? ASL isn't going to be able to magically erase a noisy tail close if it's coming from somewhere else.
Ah yes, DCS, fixes problems while creating new ones.
But, to be fair, even most of the Chinese radios get DCS right. I say most, because the sa818 definitely does not. It transmits that weird 55Hz tone at the end of transmissions, not the standardized 134.4Hz expected by literally every DCS radio ever made, so you still get squelch crashes, but that’s on Nice RF for implementing it wrong.
I haven't noticed that much with my SA818s... I'll have to do some more testing.
Just picked up a few SA818s based HotSpotRadio duplex repeater units to play with.
I do not believe it is a "traditional" reverse burst issue, as it exists when using Motorola or Chinese radios. Even if I run the receiver module in carrier squelch mode, there is still an annoying noise burst at the end of every transmission.
This is also an issue when using a mobile radio such as a Maxtrac or GM300 as a node radio.
I hate to pass this garbage upstream into a repeater system that was designed to not have this kind of garbage on it.
I can eliminate the noise using usbradio with rxsquelchdelay set to 60-100ms, but the overall audio quality sounds better using simpleusb. I spent some time experimenting with usbradio and all its settings, but the limiting effects were noticeable. Maybe with some more experimentation I can get it to sound as good as simpleusb, after playing with the limiting and voiceadjust settings.
It would be great if we could get the equivalent of usbradio's rxsquelchdelay or hamvoip's rxaudiodelay implemented into simpleusb, to truly keep things "simple".
Eric
K2CB
This is, unfortunately what happens when code is not developed in the open.
The current strategy is that chan_usbradio is going to be the general source of an updated channel audio driver that combines general ALSA/Pipewire support with a GPIO layer that provides more flexibility in audio devices. Doing it WELL is going to be a huge challenge. At that time, fixing audio issues, adding all the normal processing delays, etc. are going to be on the table. Once the kernel-module-free version of app_rpt is done, that's the next strategic interest.