[App_rpt-users] Command Mode Timeout

Ken ke2n at cs.com
Sat Dec 29 19:20:37 EST 2012

I spent some time looking the other night and I could not find anything

The only timer seems to be one that clears out the digits - but does not
exit the mode.


If we rule out modifications to app_rpt.c, there are two other things you
could try:


1)      Make the function calling the cop command more complex - like 4123 -
and let people know


2)      Reduce the sensitivity of the DTMF decode - one way is to remove the
"RADIO_RELAX" compiler flag in /usr/src/astsrc/asterisk/menuselect.makeopts


There have been previous posts on the latter subject.







From: app_rpt-users-bounces at ohnosec.org
[mailto:app_rpt-users-bounces at ohnosec.org] On Behalf Of Kent Ochs
Sent: Saturday, December 29, 2012 6:30 PM
To: Monty
Cc: app_rpt-users at ohnosec.org
Subject: Re: [App_rpt-users] Command Mode Timeout




Thanks for the reply.  I have spent considerable time, and try as a I may,
have not found anything in the source that provides command mode timeout.
My inclination at this point is to disable the ilink,4 command mode option.





From: Monty <monty at ke7jvx.com>
To: Kent Ochs <kentochs at sbcglobal.net> 
Cc: "app_rpt-users at ohnosec.org" <app_rpt-users at ohnosec.org> 
Sent: Thursday, December 27, 2012 2:24 PM
Subject: Re: [App_rpt-users] Command Mode Timeout


Hi Kent,


I have come across this before, and I do believe there is a timeout to kill
the Transmitter when there is no activity while in command mode, just not as
short as the timeout timer.  Not sure what it is set to, but you should be
able to search the source file and see.  From my experience, the Timeout
Timer is looking at the Receiver activity and not the Transmitter activity,
and does still operate while in command mode.  


My situation was someone put a repeater in command mode while traveling and
went out of range of the repeater and could not take out of command mode.  I
brought up the repeater later and it was not keyed, but as soon as I keyed
the repeater it gave the command telemetry and stayed keyed, so I took it
out of command mode.  Hope this helps.




On Wed, Dec 26, 2012 at 7:16 PM, Kent Ochs <kentochs at sbcglobal.net> wrote:

Our repeater (A two node system consisting of VHF 27833 node linked to a UHF
receiver on node 1998) recently experienced a random false dtmf *40 decode.
This put the repeater into transmit mode.  What bothers me most, is that
while in command mode, the transmit timeout parameter (totime) appears to be
ignored, not good if there isn't someone around that knows to send "#" or
otherwise shutdown the machine.  In normal operating mode, totime works as
expected, and try as I may, I have not been able to find a "command mode
timeout" parameter.  


Have I missed or mis-configured something to cause this behavior?  


Is there a problem with the command function not honoring the transmit
timeout parameter?  


I understand that *4 is a mandatory command, but could someone enlighten me
as to why I shouldn't just disable this command altogether?


An inquired mind wants to know and appreciates your feedback.






App_rpt-users mailing list
App_rpt-users at ohnosec.org



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.allstarlink.org/pipermail/app_rpt-users/attachments/20121229/3eb5e9f1/attachment.html>

More information about the App_rpt-users mailing list