<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">What HT brand/model are you using, just
out of curiosity?<br>
<br>
<br>
On 9/26/2014 11:37 PM, Doug Crompton wrote:<br>
</div>
<blockquote cite="mid:BLU172-W42774C580132E9C4448ED3BABC0@phx.gbl"
type="cite">
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style>
<div dir="ltr"><font style="" color="#000000"
face="Tahoma,sans-serif">Mike,<br>
<br>
You can try the changing the courtesy time wait then set back
to duplex=1<br>
</font><br>
The wait-times section<br>
This section allows the wait times for voice responses and other
audio telemetry events to be adjusted. All wait times are in
milliseconds.<br>
<br>
<strong><em>telemwait</em></strong> sets the time before sending
the general audio telemetry responses used in the application
which are not specifically defined below<br>
<strong><em>idwait</em></strong> sets the time to wait before
sending ID audio telemetry<br>
<strong><em>unkeywait</em></strong> sets the amount of time to
wait before sending the courtesy tone. This can be used to
ensure breaking stations can get their turn<br>
<strong><em>calltermwait</em></strong> sets the amount of time
between an autopatch disconnect and the audio telemetry message
indicating the call has been terminated<font style=""
color="#000000" face="Tahoma,sans-serif"><br>
<br>
The unkeywait is the one to mess with. It is 400ms on the BBB
by default. Make it longer like 1000 so it spans the dropout
period you are seeing. Experiment with times.<br>
<br>
If that doesn't work I really think you should try a different
radio. My thoughts are that it is some kind of recovery issue
with TX. <br id="FontBreak">
</font><br>
<b><font style="font-size:16pt;" size="4">73 Doug</font><font
style="font-size:16pt;" size="4"><br>
</font><font style="font-size:16pt;" size="4">WA3DSP</font><font
style="font-size:16pt;" size="4"><br>
</font><font style="font-size:16pt;" size="4"><a class="moz-txt-link-freetext" href="http://www.crompton.com/hamradio">http://www.crompton.com/hamradio</a></font></b><font
style="font-size:16pt;" size="4"><br>
</font><br>
<br>
<div>
<hr id="stopSpelling">From: <a class="moz-txt-link-abbreviated" href="mailto:kf7mbk@w7ara.net">kf7mbk@w7ara.net</a><br>
Date: Fri, 26 Sep 2014 18:59:26 -0700<br>
Subject: Re: [App_rpt-users] Fwd: COR signal getting confused<br>
To: <a class="moz-txt-link-abbreviated" href="mailto:doug@crompton.com">doug@crompton.com</a><br>
CC: <a class="moz-txt-link-abbreviated" href="mailto:app_rpt-users@ohnosec.org">app_rpt-users@ohnosec.org</a><br>
<br>
<div dir="ltr">OK, so I did some more testing.
<div><br>
</div>
<div>I have routed the signal out of the radio to an NPN and
switched from usbinvert to usb as suggested. This made
little difference, but in this configuration I could make
the RC work a little better bridging the dropouts. But
still would end up not detecting carrier after a quick
dropout even though the COR signal into the dongle was
high.</div>
<div><br>
</div>
<div>Duplex = 0 seems to eliminate the problem. Is there a
setting to tell it how long to wait after COR dropped to
start transmitting the courtesy tone? (though I suppose
that would defeat the purpose of the duplex=1 setting)
Note that I have the PTT disconnected for testing, so all
I see is the red LED come on as soon as the COR out of the
radio drops. </div>
<div><br>
</div>
<div>Actually as I'm typing this and playing with it, I just
noticed it appears if the COR is restored ANY time the PTT
is active for the courtesy tone, it will ignore the COR
line until it's dropped and brought back up AFTER the PTT
is done. This behavior seems VERY repeatable, even with a
cleanly restored COR signal, So it may have nothing to do
with quick dropouts and everything to do with the courtesy
tone..</div>
<div><br>
</div>
<div>Are there any settings that control this?</div>
<div><br>
</div>
<div>The LED on the radio (and hence my COR input) is
controlled by noise squelch opening.</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
</div>
<div class="ecxgmail_extra"><br>
<div class="ecxgmail_quote">On Fri, Sep 26, 2014 at 3:05 PM,
Doug Crompton <span dir="ltr"><<a
moz-do-not-send="true" href="mailto:doug@crompton.com"
target="_blank">doug@crompton.com</a>></span>
wrote:<br>
<blockquote class="ecxgmail_quote" style="border-left:1px
#ccc solid;padding-left:1ex;">
<div>
<div dir="ltr"><font color="#000000"
face="Tahoma,sans-serif">Mike,<br>
<br>
Are you using PL or noise squelch or both? Like I
said I have not seen this problem and I am using
basically stock timing. Every time the PL or
squelch goes untrue for a certain (short) duration
you should hear a courtesy tone. Perhpas you
should try duplex=0 just to see if there is an
issue with TX recovery. Do you have another radio
you can try? <br>
</font><span><br>
<b><font style="font-size:16pt;" size="4">73 Doug</font><font
style="font-size:16pt;" size="4"><br>
</font><font style="font-size:16pt;" size="4">WA3DSP</font><font
style="font-size:16pt;" size="4"><br>
</font><font style="font-size:16pt;" size="4"><a
moz-do-not-send="true"
href="http://www.crompton.com/hamradio"
target="_blank">http://www.crompton.com/hamradio</a></font></b><font
style="font-size:16pt;" size="4"><br>
</font><br>
<br>
</span>
<div>
<hr>From: <a moz-do-not-send="true"
href="mailto:kf7mbk@w7ara.net" target="_blank">kf7mbk@w7ara.net</a><br>
Date: Fri, 26 Sep 2014 10:18:19 -0700
<div>
<div class="h5"><br>
Subject: Re: [App_rpt-users] Fwd: COR signal
getting confused<br>
To: <a moz-do-not-send="true"
href="mailto:doug@crompton.com"
target="_blank">doug@crompton.com</a><br>
CC: <a moz-do-not-send="true"
href="mailto:app_rpt-users@ohnosec.org"
target="_blank">app_rpt-users@ohnosec.org</a><br>
<br>
<div dir="ltr">The scope image in the OP shows
there doesn't appear to be a problem with
pulling hi or low, The transitions (without
the RC) are very clean and go all the way to
ground.. It seems like the URI is doing
edge detection instead of level detection,
and it's just missing fast edges. Wasn't
sure if this was something that could be
tweaked in software or if I'll have to put
some external debounce logic on the line.
<div><br>
</div>
</div>
<div><br>
<div>On Fri, Sep 26, 2014 at 10:07 AM, Doug
Crompton <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:doug@crompton.com"
target="_blank">doug@crompton.com</a>></span>
wrote:<br>
<blockquote style="border-left:1px #ccc
solid;padding-left:1ex;">
<div>
<div dir="ltr"><font color="#000000"
face="Tahoma,sans-serif">Mike,<br>
<br>
Before you change any timing make
sure as Jon pointed out that your
COS signal is going hard high and
low on signal and non-signal. You
might need a pullup. The URI is
kind of weak in that regard. It
should be TTL levels <.5 volt
low and >2.5 volt high and
preferably rail to rail.<br>
</font><span><br>
<br>
<b><font style="font-size:16pt;"
size="4">73 Doug</font><font
style="font-size:16pt;"
size="4"><br>
</font><font
style="font-size:16pt;"
size="4">WA3DSP</font><font
style="font-size:16pt;"
size="4"><br>
</font><font
style="font-size:16pt;"
size="4"><a
moz-do-not-send="true"
href="http://www.crompton.com/hamradio"
target="_blank">http://www.crompton.com/hamradio</a></font></b><font
style="font-size:16pt;" size="4"><br>
</font><br>
<br>
</span>
<div>
<hr>From: <a
moz-do-not-send="true"
href="mailto:kf7mbk@w7ara.net"
target="_blank">kf7mbk@w7ara.net</a><br>
Date: Fri, 26 Sep 2014 09:56:21
-0700<br>
Subject: Re: [App_rpt-users] Fwd:
COR signal getting confused<br>
To: <a moz-do-not-send="true"
href="mailto:doug@crompton.com"
target="_blank">doug@crompton.com</a><br>
CC: <a moz-do-not-send="true"
href="mailto:app_rpt-users@ohnosec.org"
target="_blank">app_rpt-users@ohnosec.org</a>
<div>
<div><br>
<br>
<div dir="ltr">Doug,
<div><br>
</div>
<div>First: thanks for the
excellent writeup on
getting allstar running on
the BBB. I used it to get
up and running very
quickly and is the setup I
am having this issue with.</div>
<div><br>
</div>
<div>I am running duplex =1
as well. I have not
changed any timing values,
(I'm essentially running
the as-installed setup
from the install image on
your site) but I will take
a look at them and see if
I can make some changes
for the better.</div>
<div><br>
</div>
<div>Thanks!</div>
<div>-Mike</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
</div>
<div><br>
<div>On Fri, Sep 26, 2014 at
9:49 AM, Doug Crompton <span
dir="ltr"><<a
moz-do-not-send="true"
href="mailto:doug@crompton.com" target="_blank">doug@crompton.com</a>></span>
wrote:<br>
<blockquote
style="border-left:1px
#ccc
solid;padding-left:1ex;">
<div>
<div dir="ltr">
<hr>From: <a
moz-do-not-send="true"
href="mailto:doug@crompton.com" target="_blank">doug@crompton.com</a><br>
To: <a
moz-do-not-send="true"
href="mailto:kf7mbk@w7ara.net" target="_blank">kf7mbk@w7ara.net</a><br>
Subject: RE:
[App_rpt-users] Fwd:
COR signal getting
confused<br>
Date: Fri, 26 Sep
2014 12:46:14 -0400<br>
<br>
<div dir="ltr"><font
color="#000000"
face="Tahoma,sans-serif">That is very strange. Have you changed any of
the default
timing values?
Are you using
simplex/duplex?
Courtesy tone?
Timing values
could effect
that. <br>
<br>
I use simplex
with courtesy
tone (duplex=1
in rpt.conf) on
several nodes
and I have never
seen that
problem. I have
one user who has
a signal like
you describe. He
walks in a park
with a handheld
and he is often
in and out.<br>
<br>
Also I assume
you are not
using any
rxdelay?<br>
</font><br>
<b><font
style="font-size:16pt;"
size="4">73
Doug</font><font
style="font-size:16pt;" size="4"><br>
</font><font
style="font-size:16pt;"
size="4">WA3DSP</font><font
style="font-size:16pt;" size="4"><br>
</font><font
style="font-size:16pt;"
size="4"><a
moz-do-not-send="true"
href="http://www.crompton.com/hamradio" target="_blank">http://www.crompton.com/hamradio</a></font></b><font
style="font-size:16pt;" size="4"><br>
</font><br>
<br>
<div>
<hr>From: <a
moz-do-not-send="true"
href="mailto:kf7mbk@w7ara.net" target="_blank">kf7mbk@w7ara.net</a><br>
Date: Fri, 26
Sep 2014
08:50:51 -0700<br>
To: <a
moz-do-not-send="true"
href="mailto:app_rpt-users@ohnosec.org" target="_blank">app_rpt-users@ohnosec.org</a><br>
Subject:
[App_rpt-users]
Fwd: COR signal
getting confused
<div>
<div><br>
<br>
<div dir="ltr">
<div>Resending
since my
initial post
has been
pending
moderation for
2 days now and
got no reply
from the list
owner email.<br>
<br>
I have
modified an HT
to bring out
the receive
LED signal and
use it<br>
as the COR
input to a DMK
URI. It is a
digital signal
as viewed on a<br>
scope (i.e.
very short
slope in the
transitions)
This seems
like it<br>
would work
well and it
does on strong
signals. But
on marginal
signals<br>
where the LED
may blink on
and off
quickly (like
during picket<br>
fencing), it
seems to
confuse the
URI (or the
software) were
it will<br>
start off
good, but then
a quick
dropout of the
COR signal
will cause<br>
the software
to no longer
detect
carrier, even
though the
signal on<br>
the COR input
has been
restored.
Even if the
input is solid
high (or<br>
low in my
case, I'm
using
usbinvert) it
will not
detect a
carrier<br>
until there is
another
dropout of
adequate time
to "reset" it.<br>
<br>
I've tried
putting a
simple RC on
the input but
it didn't
really help<br>
much. Seems
the URI (or
software)
needs a
significant
minimum time<br>
between
transitions to
properly
detect them,
long enough
that it would<br>
delay the
carrier
detection too
much without a
circuit more
complex<br>
than an RC
(i.e.
something that
would allow
instant keyup,
but delay<br>
the key down.)<br>
<br>
Linked is a
scope image. </div>
<div><br>
</div>
<div><a
moz-do-not-send="true"
href="https://lh5.googleusercontent.com/-CsJ9autUTAE/VCWK-uNJJpI/AAAAAAAAPSM/VsVvbPVvuEA/s800/20140923_184107.jpg"
target="_blank">https://lh5.googleusercontent.com/-CsJ9autUTAE/VCWK-uNJJpI/AAAAAAAAPSM/VsVvbPVvuEA/s800/20140923_184107.jpg</a></div>
<div><br>
</div>
<div>Carrier
was detected
until this
signal<br>
dropout
event. Ch A
is my RC
filtered
signal sent to
the URI, Ch B
is<br>
the signal out
of the radio.
Carrier was
not detected
after the 5th<br>
dropout even
though the
signal
remained low.<br>
<br>
Anyone ever
experience
this and/or
have ideas on
how to fix it?<br>
<br>
Thanks.<br>
<br>
Mike<br>
KF7MBK<br>
</div>
<br>
</div>
<br>
</div>
</div>
<span>_______________________________________________
App_rpt-users
mailing list
<a
moz-do-not-send="true"
href="mailto:App_rpt-users@ohnosec.org" target="_blank">App_rpt-users@ohnosec.org</a>
<a
moz-do-not-send="true"
href="http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users"
target="_blank">http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users</a>
To unsubscribe
from this list
please visit <a
moz-do-not-send="true"
href="http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users"
target="_blank">http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users</a>
and scroll
down to the
bottom of the
page. Enter
your email
address and
press the
"Unsubscribe
or edit
options
button"
You do not
need a
password to
unsubscribe,
you can do it
via email
confirmation.
If you have
trouble
unsubscribing,
please send a
message to the
list detailing
the problem.</span></div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
App_rpt-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:App_rpt-users@ohnosec.org">App_rpt-users@ohnosec.org</a>
<a class="moz-txt-link-freetext" href="http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users">http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users</a>
To unsubscribe from this list please visit <a class="moz-txt-link-freetext" href="http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users">http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users</a> and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button"
You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem. </pre>
</blockquote>
<br>
</body>
</html>