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.

KA4EPS

From: app_rpt-users-bounces@ohnosec.org [mailto:app_rpt-users-bounces@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.

Lu, KA4EPS

Node 27870, 27869, 27875

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