[App_rpt-users] Fwd: COR signal getting confused

(KP4TR)Ramon Gonzalez kp4tr.ramon at gmail.com
Sat Sep 27 04:32:19 UTC 2014


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 
> <mailto: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 <mailto: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 <mailto:doug at crompton.com>
>     CC: app_rpt-users at ohnosec.org <mailto: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
>     <mailto: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 <mailto: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 <mailto:doug at crompton.com>
>         CC: app_rpt-users at ohnosec.org <mailto: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 <mailto:doug at crompton.com>> wrote:
>
>             ------------------------------------------------------------------------
>             From: doug at crompton.com <mailto:doug at crompton.com>
>             To: kf7mbk at w7ara.net <mailto: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 <mailto:kf7mbk at w7ara.net>
>             Date: Fri, 26 Sep 2014 08:50:51 -0700
>             To: app_rpt-users at ohnosec.org
>             <mailto: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
>             <mailto: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/34a82294/attachment.html>


More information about the App_rpt-users mailing list