That command does work in simpleusb also but I think it is the opposite that is the problem. It is not responding. Worth a try I suppose.
73 Doug
WA3DSP
http://www.crompton.com/hamradio
Date: Sat, 27 Sep 2014 00:32:19 -0400
From: kp4tr.ramon at gmail.com
To: doug at crompton.com; kf7mbk at w7ara.net
CC: app_rpt-users at ohnosec.org
Subject: Re: [App_rpt-users] Fwd: COR signal getting confused
Try this in usbradio.conf (this is not
recognized in simpleusb):
rxondelay=25 ; This will instruct the usbradio driver
to ignore the COR line
; for a specified number of 20mSec
intervals following the release of PTT.
On 9/26/2014 11:37 PM, Doug Crompton wrote:
Mike,
You can try the changing the courtesy time wait then set back
to duplex=1
The wait-times section
This section allows the wait times for voice responses and other
audio telemetry events to be adjusted. All wait times are in
milliseconds.
telemwait sets the time before sending
the general audio telemetry responses used in the application
which are not specifically defined below
idwait sets the time to wait before
sending ID audio telemetry
unkeywait sets the amount of time to
wait before sending the courtesy tone. This can be used to
ensure breaking stations can get their turn
calltermwait sets the amount of time
between an autopatch disconnect and the audio telemetry message
indicating the call has been terminated
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.
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.
73 Doug
WA3DSP
http://www.crompton.com/hamradio
From: kf7mbk at w7ara.net
Date: Fri, 26 Sep 2014 18:59:26 -0700
Subject: Re: [App_rpt-users] Fwd: COR signal getting confused
To: doug at crompton.com
CC: app_rpt-users at ohnosec.org
OK, so I did some more testing.
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.
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.
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..
Are there any settings that control this?
The LED on the radio (and hence my COR input) is
controlled by noise squelch opening.
On Fri, Sep 26, 2014 at 3:05 PM,
Doug Crompton <doug at crompton.com>
wrote:
Mike,
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?
73 Doug
WA3DSP
http://www.crompton.com/hamradio
From: kf7mbk at w7ara.net
Date: Fri, 26 Sep 2014 10:18:19 -0700
Subject: Re: [App_rpt-users] Fwd: COR signal
getting confused
To: doug at crompton.com
CC: app_rpt-users at ohnosec.org
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.
On Fri, Sep 26, 2014 at 10:07 AM, Doug
Crompton <doug at crompton.com>
wrote:
Mike,
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.
73 Doug
WA3DSP
http://www.crompton.com/hamradio
From: kf7mbk at w7ara.net
Date: Fri, 26 Sep 2014 09:56:21
-0700
Subject: Re: [App_rpt-users] Fwd:
COR signal getting confused
To: doug at crompton.com
CC: app_rpt-users at ohnosec.org
Doug,
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.
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.
Thanks!
-Mike
On Fri, Sep 26, 2014 at
9:49 AM, Doug Crompton <doug at crompton.com>
wrote:
From: doug at crompton.com
To: kf7mbk at w7ara.net
Subject: RE:
[App_rpt-users] Fwd:
COR signal getting
confused
Date: Fri, 26 Sep
2014 12:46:14 -0400
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.
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.
Also I assume
you are not
using any
rxdelay?
73
Doug
WA3DSP
http://www.crompton.com/hamradio
From: kf7mbk at w7ara.net
Date: Fri, 26
Sep 2014
08:50:51 -0700
To: app_rpt-users at ohnosec.org
Subject:
[App_rpt-users]
Fwd: COR signal
getting confused
Resending
since my
initial post
has been
pending
moderation for
2 days now and
got no reply
from the list
owner email.
I have
modified an HT
to bring out
the receive
LED signal and
use it
as the COR
input to a DMK
URI. It is a
digital signal
as viewed on a
scope (i.e.
very short
slope in the
transitions)
This seems
like it
would work
well and it
does on strong
signals. But
on marginal
signals
where the LED
may blink on
and off
quickly (like
during picket
fencing), it
seems to
confuse the
URI (or the
software) were
it will
start off
good, but then
a quick
dropout of the
COR signal
will cause
the software
to no longer
detect
carrier, even
though the
signal on
the COR input
has been
restored.
Even if the
input is solid
high (or
low in my
case, I'm
using
usbinvert) it
will not
detect a
carrier
until there is
another
dropout of
adequate time
to "reset" it.
I've tried
putting a
simple RC on
the input but
it didn't
really help
much. Seems
the URI (or
software)
needs a
significant
minimum time
between
transitions to
properly
detect them,
long enough
that it would
delay the
carrier
detection too
much without a
circuit more
complex
than an RC
(i.e.
something that
would allow
instant keyup,
but delay
the key down.)
Linked is a
scope image.
https://lh5.googleusercontent.com/-CsJ9autUTAE/VCWK-uNJJpI/AAAAAAAAPSM/VsVvbPVvuEA/s800/20140923_184107.jpg
Carrier
was detected
until this
signal
dropout
event. Ch A
is my RC
filtered
signal sent to
the URI, Ch B
is
the signal out
of the radio.
Carrier was
not detected
after the 5th
dropout even
though the
signal
remained low.
Anyone ever
experience
this and/or
have ideas on
how to fix it?
Thanks.
Mike
KF7MBK
_______________________________________________
App_rpt-users
mailing list
App_rpt-users at ohnosec.org
http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
To unsubscribe
from this list
please visit http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
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.
_______________________________________________
App_rpt-users mailing list
App_rpt-users at ohnosec.org
http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
To unsubscribe from this list please visit http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.keekles.org/pipermail/app_rpt-users/attachments/20140927/14ccdce9/attachment.html>