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 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
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.
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 <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 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 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.
On 3/29/2015 10:01 AM, R. Wayne wrote:
But as we said we are using a RTCM.
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
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%2FAudi... 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 <jrorke@cogeco.ca> *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 <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
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 listApp_rpt-users@ohnosec.orghttp://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.
_______________________________________________ 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 <jrorke@cogeco.ca> *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 <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
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 listApp_rpt-users@ohnosec.orghttp://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.
_______________________________________________ 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.
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@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> 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
participants (5)
-
Chuck Henderson -
Ken -
R. Wayne -
REDBUTTON_CTRL -
Sam Nabkey