I'm starting to think its the URI.
And finally I tried using the CTCSS input, same exact behavior.
The ctcss and carrier from are just bits so technically you could use
either one and it would work the same. You do need to set the one you are
not using to none. We always use carrierfrom even though it is ctcss that is
driving it.
I tried what you are doing here. I listened to myself iaxrpt from a
distant node. Then I key the local PTT on my handheld into my local node. I
immediately unkey and then keyed again before I heard the courtesy tone and
it worked fine. Tried it several times.
Why don't you eliminate the 1620 node in the test and iaxrpt directly to
1998 to see what happens there.
This is acting like what you would see with an rxdelay setting but it
should be 0 by default unless you somehow got that into your config.
Specifically say rxdelay=0 in the 1998 rpt.conf context to be sure.
73 Doug
WA3DSP
WA3DSP Amateur Radio Resources
________________________________
From: kf7mbk@w7ara.net
Date: Fri, 26 Sep 2014 21:15:03 -0700
Subject: Re: [App_rpt-users] Fwd: COR signal getting confused
To: doug@crompton.com
CC: app_rpt-users@ohnosec.org
Doug, this behavior happens even if I manually toggle the COR independent
of the radio and audio so unless I'm not understanding, I can't see this
being the radio.
I tried changing unkeywait to 1000 but made no difference other than
extending the time the PTT is active for the courtesy tone, and thus
extending the window in which the COR line going high will be ignored.
Seems that anything that extends the time that the PTT is active for the
courtesy tone also extends the time that the COR is ignored.
Just to make sure I'm not doing anything stupid or have an unconventional
setuo,. my test setup is:
HT -> DMK URI -> BBB (node 1998) -> ethernet -> Allstar on a VM (node
1620) -> IAX -> Zioper soft phone on laptop
HT has audio in/out connected to the URI. PTT from the URI is not
connected to the HT while testing. Signal from receive LED on the HT goes
to COR URI input.
I have the HT tuned to the weather frequency and I'm making/breaking the
antenna connection to simulate picket fencing and I'm monitoring the audio
received by the URI/BBB on the softphone.
Bottom line is if the COR line drops, the courtesy pause and tone is
instantly triggered, triggering the URI PTT. This works. But, if while the
PTT is active, the COR line goes high again, the audio through the URI is
not routed through until the COR line goes low* and high again after the
PTT/courtesy tone is done transmitting.
* when going low after getting ignored going high, no courtesy tone is
triggered.
Would it be useful/appropriate change carrierfrom to "no" and instead set
ctcssfrom = usb and switch the radio output to the ctcss input on the URI
and see if the problem still exists?
Thanks for all the help!
-Mike
On Fri, Sep 26, 2014 at 8:37 PM, Doug Crompton <doug@crompton.com> 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
WA3DSP Amateur Radio Resources
________________________________
From: kf7mbk@w7ara.net
Date: Fri, 26 Sep 2014 18:59:26 -0700
Subject: Re: [App_rpt-users] Fwd: COR signal getting confused
To: doug@crompton.com
CC: app_rpt-users@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@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
WA3DSP Amateur Radio Resources
________________________________
From: kf7mbk@w7ara.net
Date: Fri, 26 Sep 2014 10:18:19 -0700
Subject: Re: [App_rpt-users] Fwd: COR signal getting confused
To: doug@crompton.com
CC: app_rpt-users@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@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
WA3DSP Amateur Radio Resources
________________________________
From: kf7mbk@w7ara.net
Date: Fri, 26 Sep 2014 09:56:21 -0700
Subject: Re: [App_rpt-users] Fwd: COR signal getting confused
To: doug@crompton.com
CC: app_rpt-users@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@crompton.com> wrote:
________________________________
From: doug@crompton.com
To: kf7mbk@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
WA3DSP Amateur Radio Resources
________________________________
From: kf7mbk@w7ara.net
Date: Fri, 26 Sep 2014 08:50:51 -0700
To: app_rpt-users@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@ohnosec.org
ohnosec.org 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.
