<div dir="ltr"><div dir="ltr">Hi Kevin, thanks very much... I understand 999 is supposed to represent a strong fully quiet signal. That's the issue, there isn't one...but app_rpt thinks there's a signal present and is sending it 100% of the time, unless I use CTCSS decode (or plain vox), which I don't want to do for this node.<div><br></div><div>I'm using the discriminator output from a Motorola Radius M120, but the same issue occurs on other rigs, and the "signal level" is still at 999 regardless of if there's a radio connected to the dongle or not :( If there's no input, signal level should be at (or close to) zero, shouldn't it?</div><div><br></div><br></div><br><div class="gmail_quote"><div dir="ltr">On Sun, Dec 23, 2018 at 9:29 PM Kevin Custer <<a href="mailto:kuggie@kuggie.com">kuggie@kuggie.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<div class="gmail-m_6715075134168745870moz-cite-prefix">Brian,<br>
<br>
If the application reports 999, my guess is you aren't inputting
raw discriminator audio into the interface. If the audio you are
inputting into your radio interface has been Low Pass Filtered or
is squelch gated, you cannot use DSP for noise squelch detection.
The application will tell you if there is sufficient squelch
noise to utilize DSP noise squelch detection after you do the
"radio tune rxnoise" command. If it fails, the audio type, amount,
or quality isn't sufficient for DSP noise detection.
<br>
<br>
When fed with good discriminator audio, the noise squelch
detection in app_rpt is nearly as good as a Motorola M6709
(analog) squelch chip, commonly thought to be the high water mark
in noise squelch detection. 999 is the total absence of noise,
and is the result one would expect with a full quieting signal, or
an inappropriately muted RX audio line.
<br>
<br>
Kevin W3KKC
<br>
<br>
<br>
<br>
On 12/23/2018 7:28 PM, Brian G wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr"><span>Hi all,
Merry Christmas</span><br>
<br>
<span>My local
club is working on setting up a few ASL nodes, and I've been
busy modifying some CM119 based USB sound cards to control the
radios. I'm using this card/dongle: </span><a href="https://www.amazon.ca/Syba-SD-CM-UAUD-Adapter-C-Media-Chipset/dp/B001MSS6CS" rel="nofollow" target="_blank">https://www.amazon.ca/Syba-SD-CM-UAUD-Adapter-C-Media-Chipset/dp/B001MSS6CS<br style="box-sizing:border-box">
</a><br>
<span>I've
done several so far and have a few nodes working great with
CTCSS carrier detect. One issue I'm consistently running into,
is when setting the "RX Squelch Level" in the radio-tune-menu,
it detects the current RX signal strength as 999. This results
in the inability to use anything other than CTCSS for carrier
detect. I can make plain old VOX work too, but it results in
considerable (2 sec+) hang time.</span><br>
<br>
<span>Using
DSP carrier detect won't work because it's impossible to set
the squelch high enough (max value 999). It always thinks
there's a signal present when there isn't. This happens
regardless of whether there's a radio connected to the dongle
or not. As a matter of fact it happens even when plugging in
an unmodified dongle right out of the package. I need it to
work with no CTCSS. VOX would be fine if it wasn't for the
hang time, but would rather use the DSP option in
usbradio.conf. </span><br>
<br>
<span>I assume
it's just the nature of the beast, and if I want it done
properly I need an adapter and radio capable of COS. But maybe
someone knows if there's something that can be done or not?
Anyone have any insight on how to either eliminate the VOX
hang time, or eliminate that "invisible" signal? </span><span>I might
be overlooking something. Thanks for reading!</span>
<div>
<div>
<div dir="ltr" class="gmail-m_6715075134168745870gmail_signature">--<br>
Brian - VA3DXV<br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
</div>
</blockquote></div></div>