[App_rpt-users] Long Squelch tail problem

Ken ke2n at cs.com
Sat Oct 5 14:07:53 UTC 2013


I have found that, if the noise test does not pass, then DSP squelch
operation will be generally unsatisfactory. You can fiddle with the
"rxsquelch" setting so that it closes reliably, but then you will find it
cuts out people in mid-sentence, when their signal seems quite copy-able
(very annoying).  Best thing to do in that case is to use hardware squelch.
With an HT, it's problematical, of course. You have to "operate" on the
radio and void whatever warrantee.  There is only one amateur HT I am aware
of that had the COS signal available as an external signal (in the
microphone connector I think).

 

73

Ken

 

 

 

From: Bill Hurlock [mailto:bill.hurlock at cpcomms.com] 
Sent: Friday, October 04, 2013 12:18 PM
To: Tim Sawyer
Cc: app_rpt-users at ohnosec.org list
Subject: Re: [App_rpt-users] Long Squelch tail problem

 

The 736R seems to be lacking in the HF noise area as I can't make it to the
27000 number the program is looking for. It almost gets there. About 26231.
I'll have to run a SQ open point test on the radio and see where the SQ
opens. I have the test gear to do that.

Thanks

 

Bill Hurlock

 

From: Tim Sawyer [mailto:tim.sawyer at me.com] 
Sent: Friday, October 04, 2013 10:49 AM
To: Bill Hurlock
Cc: app_rpt-users at ohnosec.org list
Subject: Re: [App_rpt-users] Long Squelch tail problem

 

Wouxon HTs seem to do that even on systems with perfectly good squelch.
Maybe they slowly reduce the transmit power or something. It seems worse
when you're close to the receiver. 

 

As far as your usbradio long squelch tail problem; some radios just don't
have enough high frequency noise to drive the DSP properly. In that case you
have to use simpleUSB.

 

Also please note that even with a properly working DSP squelch quickly
kerchunking will produce a long squelch tail... just like MICOR squelch will
do. 

--

Tim

:wq

 

On Oct 4, 2013, at 7:05 AM, Bill Hurlock <bill.hurlock at cpcomms.com> wrote:

 

I have tried tightening the SQ but then I start to have decode issues with
some of the connecting radios. The current signal strength reading, no
carrier present, is 776 and SQ setting is 900. This does eliminate the SQ
tail but I'm sure this is going to affect RX sensitivity over all being so
high. There appears to be a very narrow range of SQ levels that provide no
SQ tail and decode is fair. Most problematic are the Wouxon radios.

 

Bill Hurlock

 

From: Corey Dean [mailto:n3fe at repeater.net] 
Sent: Friday, October 04, 2013 12:30 AM
To: Bill Hurlock; app_rpt-users at ohnosec.org
Subject: RE: Long Squelch tail problem

 

Have you tried increasing the squelch level?  What is the current squelch
level?

 

Corey  N3FE

 

From:  <mailto:app_rpt-users-bounces at ohnosec.org>
app_rpt-users-bounces at ohnosec.org [
<mailto:app_rpt-users-bounces at ohnosec.org>
mailto:app_rpt-users-bounces at ohnosec.org] On Behalf Of Bill Hurlock
Sent: Thursday, October 03, 2013 7:46 PM
To:  <mailto:app_rpt-users at ohnosec.org> app_rpt-users at ohnosec.org
Subject: [App_rpt-users] Long Squelch tail problem

 

I had to go back to my URI interface and my FT-736R. I have it set up to do
tone encode and decode using the URI. All the encode and decode are working
however when I unkey there is a squelch tail that lasts about 1 to 2
seconds. I'm allowing the URI to determine COR thru DSP. The connections are
setup for raw audio both ways with the node supplying the pre and de
emphasis. I have played with the settings but nothing changes the problem.
It isn't a consistent duration of tail. I know it is in tone decode mode
because if I turn tone off on the portable I can't open the squelch thru the
node. Anyone have any ideas..

 

Bill Hurlock

CPCommunications

856-234-1661 Office

 <http://www.totalrf.com/> 856-264-1010 Cell

 <http://www.cpcomms.com/> www.cpcomms.com

WA2TQI

 


-- 
This message was scanned and is believed to be clean. 
 <http://simba.repeater.net:8080/cgi-bin/learn-msg.cgi?id=33F0DD0244.A818B>
Click here to report this message as spam.

_______________________________________________
App_rpt-users mailing list
App_rpt-users at ohnosec.org
http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.keekles.org/pipermail/app_rpt-users/attachments/20131005/9e9721b2/attachment.html>


More information about the App_rpt-users mailing list