Squelch Tail Elimination

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. 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.

With this said is there anything in Allstar that would help with this situation?

Wayne

The short answer is yes.

What you need to do is bring out raw discriminator to the URI or USB

fob. Then configure youfr node for USB radio to have

Carrierfrom = dsp and ctcss from = dsp.

you also need to set the rx demod to flat.

[usbnode_num]

hdwtype=0   

rxboost=1

txboost=1

rxctcssrelax=1

txctcssdefault=131.8    ; default pl tone

rxctcssfreqs=131.8    ;rx pl tone

txctcssfreqs=131.8    ;tx pl tone if used

;rxctcssoverride=0

carrierfrom=dsp    ;carrier squelch detection

ctcssfrom=dsp    ; pl tone detection

rxdemod=flat

txprelim=yes

txlimonly=no

txtoctype=phase

txmixa=voice

txmixb=no

invertptt=0

duplex=0

rxondelay=0

rxnoisefiltype=0

eeprom=0

Save your settings and restart your Allstar node so the changes take

affect.

Do your audio calibrations.

Then you will need to set the carrier squelch. Typically the default

squelch setting in Allstar is below the threshold. So you will get
squelch crashes.

Do a "radio tune rxsquelch" at the cli with no signal at the

receiver. It will return the current squelch setting and the current
squelch level.

*CLI> radio tune rxsquelch

Current Signal Strength is 788

Current Squelch setting is 500

If the squelch level is below the signal strength then the carrier

squelch is open.

Set the squelch higher than the signal strength by about 80-100

points.

*CLI> radio tune rxsquelch 820 <enter>

Try the squelch. It should give you a "fast squelch" for signals

that have 20 db quieting or better.

then test the threshold and see how weak signal will open the

squelch. You may have to tweak the squelch to liking.

Once you have the squelch set correctly then save thew settings.

*CLI> radio tune save.

You should be good to go.

Jon VA3RQ
···

App_rpt-users@ohnosec.orghttp://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-usershttp://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users

  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
···

App_rpt-users@ohnosec.orghttp://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-usershttp://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users

But as we said we are using a RTCM.

···

From: REDBUTTON_CTRL

Sent: Sunday, March 29, 2015 5:09 AM

To: app_rpt-users@ohnosec.org

Subject: Re: [App_rpt-users] Squelch Tail Elimination

The short answer is yes.

What you need to do is bring out raw discriminator to the URI or USB fob. Then configure youfr node for USB radio to have

Carrierfrom = dsp and ctcss from = dsp.
you also need to set the rx demod to flat.

[usbnode_num]

hdwtype=0
rxboost=1
txboost=1
rxctcssrelax=1
txctcssdefault=131.8 ; default pl tone
rxctcssfreqs=131.8 ;rx pl tone
txctcssfreqs=131.8 ;tx pl tone if used
;rxctcssoverride=0
carrierfrom=dsp ;carrier squelch detection
ctcssfrom=dsp ; pl tone detection
rxdemod=flat
txprelim=yes
txlimonly=no
txtoctype=phase
txmixa=voice
txmixb=no
invertptt=0
duplex=0
rxondelay=0
rxnoisefiltype=0
eeprom=0

Save your settings and restart your Allstar node so the changes take affect.
Do your audio calibrations.

Then you will need to set the carrier squelch. Typically the default squelch setting in Allstar is below the threshold. So you will get squelch crashes.

Do a “radio tune rxsquelch” at the cli with no signal at the receiver. It will return the current squelch setting and the current squelch level.

*CLI> radio tune rxsquelch
Current Signal Strength is 788
Current Squelch setting is 500

If the squelch level is below the signal strength then the carrier squelch is open.
Set the squelch higher than the signal strength by about 80-100 points.

*CLI> radio tune rxsquelch 820

Try the squelch. It should give you a “fast squelch” for signals that have 20 db quieting or better.
then test the threshold and see how weak signal will open the squelch. You may have to tweak the squelch to liking.

Once you have the squelch set correctly then save thew settings.

*CLI> radio tune save.

You should be good to go.

Jon VA3RQ

On 3/29/2015 1:33 AM, R. Wayne wrote:

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. 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.

With this said is there anything in Allstar that would help with this situation?

Wayne

_______________________________________________
App_rpt-users mailing list
App_rpt-users@ohnosec.org
[http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users](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](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.


App_rpt-users mailing list
App_rpt-users@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.

OK that wasn’t clear from your recent post, but I see that was
mentioned in a different thread.

I'm no expert on the RTCM but I thought it does do a DSP decode for

Carrier Squelch and PL Decode. If the RTCM is set up to do the DSP
decoding from discriminator audio you should be able to achieve the
goal of no squelch tails.

The setup and calibration is different for the RTCM from an ACID but

should be doable.

Perhaps someone else will correct me if I'm wrong here.

If you have the RTCM connected such that the MSF is doing all the

decoding and audio gating and sending the COR to the RTCM then you
are stuck with the way the MSF works. See my other post on how the
reverse bust of the MSF for further explanation.

Jon VA3RQ
···

On 3/29/2015 10:01 AM, R. Wayne wrote:

But as we said we are using a RTCM.

The RTCM has a manual squelch threshold pot. It will function as a bilevel squelch with a strong signal.

Are you feeding the discriminator audio to the RTCM and have it set up as such?

If you cannot use discriminator audio you may need an audio delay board in place as well. This is not a standard configuration if you’re feeding non discriminator audio to the RTCM.

···

App_rpt-users@ohnosec.orghttp://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-usershttp://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users

You will need an audio delay board. I’ve got the same issue at an analog voted system. I used this…

http://arsrepeaters.com/site/mobile?url=http%3A%2F%2Farsrepeaters.com%2FAudio_Delay_W462.php#2834

However, I have had great success with the built in squelch in the RTCM… As good as Motorola.

···

On Mar 29, 2015 10:10 AM, “R. Wayne” allstar@controlservers.net wrote:

But as we said we are using a RTCM.

From: REDBUTTON_CTRL

Sent: Sunday, March 29, 2015 5:09 AM

To: app_rpt-users@ohnosec.org

Subject: Re: [App_rpt-users] Squelch Tail Elimination

The short answer is yes.

What you need to do is bring out raw discriminator to the URI or USB fob. Then configure youfr node for USB radio to have

Carrierfrom = dsp and ctcss from = dsp.
you also need to set the rx demod to flat.

[usbnode_num]

hdwtype=0
rxboost=1
txboost=1
rxctcssrelax=1
txctcssdefault=131.8 ; default pl tone
rxctcssfreqs=131.8 ;rx pl tone
txctcssfreqs=131.8 ;tx pl tone if used
;rxctcssoverride=0
carrierfrom=dsp ;carrier squelch detection
ctcssfrom=dsp ; pl tone detection
rxdemod=flat
txprelim=yes
txlimonly=no
txtoctype=phase
txmixa=voice
txmixb=no
invertptt=0
duplex=0
rxondelay=0
rxnoisefiltype=0
eeprom=0

Save your settings and restart your Allstar node so the changes take affect.
Do your audio calibrations.

Then you will need to set the carrier squelch. Typically the default squelch setting in Allstar is below the threshold. So you will get squelch crashes.

Do a “radio tune rxsquelch” at the cli with no signal at the receiver. It will return the current squelch setting and the current squelch level.

*CLI> radio tune rxsquelch
Current Signal Strength is 788
Current Squelch setting is 500

If the squelch level is below the signal strength then the carrier squelch is open.
Set the squelch higher than the signal strength by about 80-100 points.

*CLI> radio tune rxsquelch 820

Try the squelch. It should give you a “fast squelch” for signals that have 20 db quieting or better.
then test the threshold and see how weak signal will open the squelch. You may have to tweak the squelch to liking.

Once you have the squelch set correctly then save thew settings.

*CLI> radio tune save.

You should be good to go.

Jon VA3RQ

On 3/29/2015 1:33 AM, R. Wayne wrote:

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. 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.

With this said is there anything in Allstar that would help with this situation?

Wayne

_______________________________________________
App_rpt-users mailing list
App_rpt-users@ohnosec.org
[http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users](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](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.


App_rpt-users mailing list
App_rpt-users@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.


App_rpt-users mailing list

App_rpt-users@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.

There are two squelch tails. One in the user’s receiver which can be eliminated by using tone squelch and turning off the PL some time before dropping the carrier. Some commercial rigs respond to the reverse phase tone burst. That is unusual in amateur rigs I think. And some amateur rigs require the tone to be turned off longer that the app_rpt default. This all has to do with the squelch tail being generated in the user’s receiver.

But if you want the repeater not to transmit a squelch tail - from its own receiver - then you need:

Rxsquelchdelay in usbradio.con

as previously discussed in :

http://ohnosec.org/pipermail/app_rpt-users/2014-April/009175.html

for example

rxsquelchdelay=50 ; delayline in ms, carrier squelch tail eliminator

this requires use of the usbradio channel driver.

73

Ken

···

From: R. Wayne [mailto:allstar@controlservers.net]
Sent: Sunday, March 29, 2015 1:34 AM
To: app_rpt-users@ohnosec.org
Subject: [App_rpt-users] Squelch Tail Elimination

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. 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.

With this said is there anything in Allstar that would help with this situation?

Wayne

There are two squelch tails. One in the user’s receiver which can be eliminated by using tone squelch and turning off the PL some time before dropping the carrier. Some commercial rigs respond to the reverse phase tone burst. That is unusual in amateur rigs I think. And some amateur rigs require the tone to be turned off longer that the app_rpt default. This all has to do with the squelch tail being generated in the user’s receiver.

But if you want the repeater not to transmit a squelch tail - from its own receiver - then you need:

Rxsquelchdelay in usbradio.con

as previously discussed in :

http://ohnosec.org/pipermail/app_rpt-users/2014-April/009175.html

for example

rxsquelchdelay=50 ; delayline in ms, carrier squelch tail eliminator

this requires use of the usbradio channel driver.

73

Ken

···

From: R. Wayne [mailto:allstar@controlservers.net]
Sent: Sunday, March 29, 2015 1:34 AM
To: app_rpt-users@ohnosec.org
Subject: [App_rpt-users] Squelch Tail Elimination

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. 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.

With this said is there anything in Allstar that would help with this situation?

Wayne

Crank your RTCM squelch pot 4-5 turns past the threshold. I have a voted system that was doing the same thing. Also make sure your ctcss line from the receiver to the rtcm. I had one of the ctcss output lines programmed wrong when I was setting it up and everything was CSQ.

···

On Sun, Mar 29, 2015 at 11:01 AM, Bryan Fields bryan@bryanfields.net wrote:

I believe he’s using the RTCM, so the usbradio commands will not work.

On March 29, 2015 12:33:30 PM EDT, Ken ke2n@cs.com wrote:

There are two squelch tails. One in the user’s receiver which can be eliminated by using tone squelch and turning off the PL some time before dropping the carrier. Some commercial rigs respond to the reverse phase tone burst. That is unusual in amateur rigs I think. And some amateur rigs require the tone to be turned off longer that the app_rpt default. This all has to do with the squelch tail being generated in the user’s receiver.

But if you want the repeater not to transmit a squelch tail - from its own receiver - then you need:

Rxsquelchdelay in usbradio.con

as previously discussed in :

http://ohnosec.org/pipermail/app_rpt-users/2014-April/009175.html

for example

rxsquelchdelay=50 ; delayline in ms, carrier squelch tail eliminator

this requires use of the usbradio channel driver.

73

Ken

From: R. Wayne [mailto:allstar@controlservers.net]
Sent: Sunday, March 29, 2015 1:34 AM
To: app_rpt-users@ohnosec.org
Subject: [App_rpt-users] Squelch Tail Elimination

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. 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.

With this said is there anything in Allstar that would help with this situation?

Wayne



---


App_rpt-users mailing list
App_rpt-users@ohnosec.org
[http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users](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](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.

Bryan Fields

727-409-1194

http://bryanfields.net


App_rpt-users mailing list

App_rpt-users@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.

I have made some changes to the squelch code that I think will fix the issues you are having but they are not included in the pre-compiled versions on SVN. To enable them it is necessary to download the source files, edit src/HardwareProfile.h and change the line “// #define CHUCK” to “#define CHUCK”, in other words, remove the // from the beginning of the line.

Then compile the appropriate code version for your hardware version and update the firmware in your RTCM.

Chuck Henderson, WB9UUS

···

On Sun, Mar 29, 2015 at 9:01 AM, R. Wayne allstar@controlservers.net wrote:

But as we said we are using a RTCM.

From: REDBUTTON_CTRL

Sent: Sunday, March 29, 2015 5:09 AM

To: app_rpt-users@ohnosec.org

Subject: Re: [App_rpt-users] Squelch Tail Elimination

The short answer is yes.

What you need to do is bring out raw discriminator to the URI or USB fob. Then configure youfr node for USB radio to have

Carrierfrom = dsp and ctcss from = dsp.
you also need to set the rx demod to flat.

[usbnode_num]

hdwtype=0
rxboost=1
txboost=1
rxctcssrelax=1
txctcssdefault=131.8 ; default pl tone
rxctcssfreqs=131.8 ;rx pl tone
txctcssfreqs=131.8 ;tx pl tone if used
;rxctcssoverride=0
carrierfrom=dsp ;carrier squelch detection
ctcssfrom=dsp ; pl tone detection
rxdemod=flat
txprelim=yes
txlimonly=no
txtoctype=phase
txmixa=voice
txmixb=no
invertptt=0
duplex=0
rxondelay=0
rxnoisefiltype=0
eeprom=0

Save your settings and restart your Allstar node so the changes take affect.
Do your audio calibrations.

Then you will need to set the carrier squelch. Typically the default squelch setting in Allstar is below the threshold. So you will get squelch crashes.

Do a “radio tune rxsquelch” at the cli with no signal at the receiver. It will return the current squelch setting and the current squelch level.

*CLI> radio tune rxsquelch
Current Signal Strength is 788
Current Squelch setting is 500

If the squelch level is below the signal strength then the carrier squelch is open.
Set the squelch higher than the signal strength by about 80-100 points.

*CLI> radio tune rxsquelch 820

Try the squelch. It should give you a “fast squelch” for signals that have 20 db quieting or better.
then test the threshold and see how weak signal will open the squelch. You may have to tweak the squelch to liking.

Once you have the squelch set correctly then save thew settings.

*CLI> radio tune save.

You should be good to go.

Jon VA3RQ

On 3/29/2015 1:33 AM, R. Wayne wrote:

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. 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.

With this said is there anything in Allstar that would help with this situation?

Wayne

_______________________________________________
App_rpt-users mailing list
App_rpt-users@ohnosec.org
[http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users](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](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.


App_rpt-users mailing list
App_rpt-users@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.


App_rpt-users mailing list

App_rpt-users@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.