[App_rpt-users] Squelch Tail Elimination

[REDBUTTON_CTRL]

> After relocating our MSF 5000 to a new location and adjusting the 
> squelch as low as we could reliably go we noticed that we have a 
> squelch tail. Our coordination requires that we don't.
Just a further explanation on squelch tail. This is usually the noise 
burst heard after unkeying. I find it difficult to believe that anyone 
would require a repeater to not have a squelch burst as a requirement 
for coordination.

Having said that, what is probably meant is CTCSS or tone squelch is 
required. Sometimes this is referred to as "PL" for Motorola equipment 
and "Channel Guard " for GE.

> It appears that the MSF has a fixed squelch tail elimination method an 
> no control other than cranking up the squelch again. This is 
> surprising since we use PL encode / decode. I would think that the PL 
> would mute as soon as the user unkeys.
Motorola and GE and a few others have a feature that is used along with 
simple ctcss tone decoding. The radios transmit the pl tone and when the 
radio is unkeyed, the transmitter stays on for about 250 MS and changes 
the tone phase, then drops the transmitter. The phase change tells the 
tone decoder at the other end to mute the audio before the carrier 
drops. So this is how they eliminate the squelch burst. This is referred 
to as "Reverse Burst" for Motorola radios and the  GE version is called 
"Squelch Tail Elimination" or STE.

Radios that have Reverse Burst (or STE) feature, normally have a 200-300 
ms delay after the tone disappears before it mutes the receive audio 
unless it gets the phase shift of the PL tone then it mutes immediately.

This is the way it works for radios and repeaters that both employ 
reverse burst on transmit and Receive.

So what happens when you have a radio that doesn't transmit reverse burst?

The mobile radio doesn't send the reverse burst but just drops the 
carrier. The repeater decoder will give the 250 ms squelch burst. It 
does this because there was no phase shift in the tone to tell the 
receiver to mute before the carrier was dropped. Also the delay is in 
place in case the signal is weak and prevents the squelch from chopping 
the audio.

Most ham radio rigs don't encode the reverse burst, thus the long 
squelch burst at the end of every transmission.

Now in the case of the MSF, it could be setup so that if its put into 
carrier squelch mode then the Motorola "Smart squelch" would take care 
of most of the squelch bursts if the signals are 20 db quieting or better.

In this case the COR line could be brought out to the URI and some how 
you would also need to bring out a line from the PL decoder that 
operates independently from COR, even though its "not being used" from 
the MSFs point of view.

The Allstar node would then be configured to use external hardware COR 
and PL signals instead of doing the dsp internally.

In my opinion it would seem easier to just bring out the discriminator 
and let the Allstar node do all the hard work on the RX side.
The App_Rpt SW has a good SW "Smart Squelch" for carrier squelch and 
also does work with reverse burst radios too. So most of the time you 
will have no squelch tails on good signals and only have some bursts on 
the weak signals.

Jon VA3RQ









On 3/29/2015 1:33 AM, R. Wayne wrote:
> With this said is there anything in Allstar that would help with this 
> situation?
> Wayne
>
>
> _______________________________________________
> App_rpt-users mailing list
> App_rpt-users at ohnosec.org
> http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
>
> To unsubscribe from this list please visit http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button"
> You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.keekles.org/pipermail/app_rpt-users/attachments/20150329/bb95a6e9/attachment.html>