[App_rpt-users] Micor Squelch like available on APP?

[Lu Vencl]

All,

Just got confirmation from one of the developers that it is confirmed to be
a known issue. It will be worked on later this year so I suspect in a future
update, this will be corrected.

In the meantime, I will just put up with it and help with testing future
patches. Worse case, one can loosen up the squelch, but you will have to put
up with the burst. Hmm, if we can only get a longer delay then we could rely
on CTCSS decoding only . A longer delay would ensure the squelch burst would
not be heard, but you might hear your own last word when you unkey LOL...
Now that would be a cool temp fix.

Lu

KA4EPS

 

From: app_rpt-users-bounces at ohnosec.org
[mailto:app_rpt-users-bounces at ohnosec.org] On Behalf Of Tim Sawyer
Sent: Monday, July 25, 2011 7:59 PM
To: app_rpt list
Subject: Re: [App_rpt-users] Micor Squelch like available on APP?

 

Lu Venci,

 

I found the same issue thought I did not measure it as you have. I reverted
to good-old Micor squelch and P/L reeds because I did not feel that app_rpt
DSP did as well as the Micor  in either case. Sometimes 40 year old
technology is still best.   

--
Tim
:wq

 

On Jul 25, 2011, at 11:24 AM, Lu Vencl wrote:





Seems like I recall at one of the VOIP conventions years past that someone
stated that the APP_RPT had the micor squelch algorithm built in.

I have two micor repeaters now that I set up nodes using the URI board when
DSP on both COR and CTCSS.

I calibrated the URI using the radio-tune-menu and I even tested the signal
break point with a service monitor.

Example -110 dBm is when squelch clamps down.. That is about right.. It has
a hysteresis of about 5 dB which is ok, but here is the kicker.. When you
are fluttering into the receiver, the app is squelching, muting and it does
not allow for the extra rx unsquelched condition like the micor does when
you are weak. So you end up hearing a lot of muting when the signal is
useable. I know there is a delay and an attempt to remove squelch burst, but
should that not be triggered by the DSP upon CTCSS decoder not seeing
signal? I have heard this issue with other nodes as well, and I though all
along it was a setting issue.

My squelch setting is at 765, and if I lower it to 760, it them provides a
long squelch burst on even strong signals.

 

So I am looking for guidance to see if perhaps I may be doing something
wrong? Or is this just the short coming of the DSP and as I would hate to
revert back to the repeater CTCSS and COR signaling, I suppose I could if
justified.

Let me know if you have seen this and have found resolution.

Thanks in advance.

73

Lu, KA4EPS

Node 27870, 27869, 27875

_______________________________________________
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/20110725/38aa9cf9/attachment.html>