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

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.

GL

Ken

W4BRM/R

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

Monty,

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.

Kent

---

From: Monty <monty@ke7jvx.com>
To: Kent Ochs <kentochs@sbcglobal.net>
Cc: "app_rpt-users@ohnosec.org" <app_rpt-users@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.

Monty

On Wed, Dec 26, 2012 at 7:16 PM, Kent Ochs <kentochs@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.

Thanks.

Kent

W9KAO

_______________________________________________
App_rpt-users mailing list
App_rpt-users@ohnosec.org
http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users