<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<blockquote type="cite">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.</blockquote>
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.<br>
<br>
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.<br>
<br>
<blockquote type="cite">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.
<div> </div>
</blockquote>
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.<br>
<br>
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. <br>
<br>
This is the way it works for radios and repeaters that both employ
reverse burst on transmit and Receive.<br>
<br>
So what happens when you have a radio that doesn't transmit reverse
burst? <br>
<br>
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.<br>
<br>
Most ham radio rigs don't encode the reverse burst, thus the long
squelch burst at the end of every transmission.<br>
<br>
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.<br>
<br>
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.<br>
<br>
The Allstar node would then be configured to use external hardware
COR and PL signals instead of doing the dsp internally.<br>
<br>
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.<br>
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.<br>
<br>
Jon VA3RQ<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
On 3/29/2015 1:33 AM, R. Wayne wrote:
<blockquote cite="mid:1C25F83802714DAD9562D2F02199D5FB@delllaptop"
type="cite">
<div dir="ltr">
<div style="FONT-SIZE: 12pt; FONT-FAMILY: 'Calibri'; COLOR:
#000000">
<div> </div>
<div>With this said is there anything in Allstar that would
help with this situation?</div>
<div> </div>
<div>Wayne</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
App_rpt-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:App_rpt-users@ohnosec.org">App_rpt-users@ohnosec.org</a>
<a class="moz-txt-link-freetext" href="http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users">http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users</a>
To unsubscribe from this list please visit <a class="moz-txt-link-freetext" href="http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users">http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users</a> 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. </pre>
</blockquote>
</body>
</html>