[App_rpt-users] Kerchunk filter or equivalent of pulseback timer?

[Stephen Rodgers]

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

Unless you are comfortable doing manual updates of code, its best to
wait until it is released as an ACID distro.

Steve
WA6ZFT