[App_rpt-users] Fwd: COR signal getting confused

Sat Sep 27 15:47:11 UTC 2014

I'm starting to think its the URI.

First, I got rid of all the components (transistor and RC) because they
made little difference and don't want the added complexity.  I went back to
usbinvert.
I brought the radio and URI to the 1620 node on the VM (basically a stock
install of ACID) and connected Zoiper directly to the node.  This left the
BBB and its configuration completely out of the loop and I still got the
same behavior.

Next I reconnected the URI and radio to the BBB and connected directly to
it via Zioper (I didn't do this before because I was having trouble
connecting Zoiper to the BBB, but I got that figured out) and it's still
the same behavior.

And just to eliminate the radio, I disconnected it completely, connected
the COR input to a pullup, and grounded it by hand.  When I ground the COR
line (usbinvert), I can hear slight background noise through Zoiper and
when I unground it, the courtesy tone is triggered (URI PTT active as well)
and then the background noise goes away when the CT is done.  But if I
ground the COR line while the courtesy tone is playing, it ignores the COR
and does not pass audio to zioper until I cycle the COR line again.

And finally I tried using the CTCSS input, same exact behavior.

I know there is a URI test program from DMK, but I didn't really see a way
to simply read out the status of the inputs, just automated tests requiring
a loopback.

-Mike

On Fri, Sep 26, 2014 at 9:47 PM, Doug Crompton <doug at crompton.com> wrote:

> 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 DougWA3DSPhttp://www.crompton.com/hamradio
> <http://www.crompton.com/hamradio>*
>
>
> ------------------------------
> From: kf7mbk at w7ara.net
> Date: Fri, 26 Sep 2014 21:15:03 -0700
>
> Subject: Re: [App_rpt-users] Fwd: COR signal getting confused
> To: doug at crompton.com
> CC: app_rpt-users at 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 at 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 DougWA3DSPhttp://www.crompton.com/hamradio
> <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 DougWA3DSPhttp://www.crompton.com/hamradio
> <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 DougWA3DSPhttp://www.crompton.com/hamradio
> <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 DougWA3DSPhttp://www.crompton.com/hamradio
> <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.
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.keekles.org/pipermail/app_rpt-users/attachments/20140927/8f14a9ad/attachment.html>