Thanks for the info Steve,<div><br></div><div>Thats great news for me, I occasionally deploy a portable system which uses the repeater pair in the same way - Its not possible for me to use a separate link freq for this system. If I need to link to another one of the portable repeaters, I get this ping-pong effect between them which this timer will fix for me.</div>

<div><br></div><div>I searched the <a href="http://qrvc.com">qrvc.com</a> website for rxondelay but couldn't find any info - can you tell me which version of chan_usbradio supports this please?</div><div><br></div><div>
Thanks,</div><div><br></div><div>Matt</div><div>G4RKY</div><div> </div><div><br><div class="gmail_quote">2009/9/11 Stephen Rodgers <span dir="ltr"><<a href="mailto:sales@qrvc.com" target="_blank">sales@qrvc.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div></div><div>Ramesh Dhami (VA3UV) wrote:<br>
> Hi All;<br>
><br>
> One of the local repeaters is connecting to the VE3TNK HUB (#2200) using<br>
> an off-site link radio (since there's no IP at the repeater site).<br>
><br>
> Unfortunately, the analog repeater controller can not be set for zero<br>
> hang time, and therefore the short hang time is being exposed to the hub<br>
> and all of the downstream nodes.<br>
><br>
> Is there a kerchunk filter or the equivalent of a pulseback timer (as<br>
> there is in IRLP) to compensate (filter out) such kerchunks?<br>
><br>
> Thanks!<br>
><br>
> Ramesh.<br>
> _______________________________________________<br>
> App_rpt-users mailing list<br>
> <a href="mailto:App_rpt-users@qrvc.com" target="_blank">App_rpt-users@qrvc.com</a><br>
> <a href="http://qrvc.com/mailman/listinfo/app_rpt-users" target="_blank">http://qrvc.com/mailman/listinfo/app_rpt-users</a><br>
><br>
<br>
</div></div>Something may not be described clearly enough, but what I read out of it<br>
is that you have a dedicated downlink radio from the IP-less repeater<br>
site on a different frequency than the repeater output. When you say<br>
"link" this is what I believe it mean.<br>
<br>
For a dedicated downlink channel separate from the repeater controller,<br>
you should be able to have zero hang time by bypassing the controller<br>
entirely and just retransmitting what comes in on the repeater input on<br>
the downlink transmitter from the remote repeater site. This is how I<br>
implement systems on remote sites without IP connectivity.<br>
<br>
If you are just using a simplex radio on to talk in to the repeater,<br>
then you are not implementing a link, you just have a radio interfaced<br>
to an app_rpt port tuned to the repeater pair. (Note: I try to<br>
discourage people from doing this it is just not a good way to engineer<br>
a communications system-- Your radio can jam the repeater input and<br>
cause problems for emergency traffic. Link traffic should be uplinked<br>
and downlinked on a dedicated link frequency to avoid this)<br>
<br>
All of that said, there is a new config option in the chan_usbradio and<br>
xpmr sources (rxondelay) which will hold off the COR recognition when<br>
PTT is de-asserted by the app_rpt port. I believe the units are<br>
milliseconds, but since Jim Dixon implemented this he would know best.<br>
This is  meant for simplex radios which assert or glitch COR during the<br>
transmit to receive turnaround time but if the delay is made long enough<br>
it could be used to filter out the hang time on the repeater output.<br>
<br>
Steve<br>
WA6ZFT<br>
<div><div></div><div><br>
<br>
_______________________________________________<br>
App_rpt-users mailing list<br>
<a href="mailto:App_rpt-users@qrvc.com" target="_blank">App_rpt-users@qrvc.com</a><br>
<a href="http://qrvc.com/mailman/listinfo/app_rpt-users" target="_blank">http://qrvc.com/mailman/listinfo/app_rpt-users</a><br>
</div></div></blockquote></div><br></div>