[App_rpt-users] Squelch issue with RTCM and Kenwood

[James Cizek]

Hayden,

I have no issue with last syllable coming back.  I certainly did when the
system was defaults, but have found that the current settings eliminate it
for everything but the ultra-fastest of radios.

I run the TX buffer on the RTCM at 650
and buflen = 190 in voter.conf

With those settings, it's *extremely* rare anyone hears the tail of their
own conversation.  I do have some radios that if you are ultra-quick on
releasing the PTT on your last audible syllable, you can just barely hear
what sounds like your exhaling breath as it closes, but it's got to be just
right to hear it at all.

500ms of delay seems like a lot.  I have some voters far enough away in the
network that the latency over the microwave hops is 4~5 ms and I still
don't have any delay or buffer issues with those links.   Wonder if there
is something else going on.  You have plenty enough CPU in the DIAL box to
handle all the traffic it needs to handle?  Have you checked to make sure
your Ethernet is clean and you don't have a ton of retransmitted packets
happening?   Wirehsark/tcpdump is priceless for finding duplex
mis-matches/etc.... Just some thoughts...


James

Date: Tue, 2 May 2017 09:34:13 +1000
From: Hayden Honeywood <haydenph91 at gmail.com>
To: app_rpt-users at lists.allstarlink.org
Subject: [App_rpt-users] Squelch issue with RTCM and Kenwood
Message-ID:
        <CAC0VLD0gq4UvOGfbKYid-0hvxYZ=SES4Gc_US-R5m7qmPwHXMw at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi James,

As Lee said, load Chuck squelch and see how it goes. I had similar issues
with mine (although I'm running the VOTER board). The RSSI meter would jump
around all over the place. I also had to find a suitable location for the
discriminator on my radio. In my case the pin labelled "discriminator" had
some high pass filtering applied.

The delay seems inherent in the RTCM/voter. I've tested over a LAN with a
latency of <1ms and I still hear the last syllable of my last word when
unkeying.
This is with the RX buffer set at 120ms and the TX buffer at 60ms (so is
that 180ms total).

There must be over a half second delay elsewhere within the processing of
audio that is added?

Hayden
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.keekles.org/pipermail/app_rpt-users/attachments/20170502/d86332e9/attachment.html>