[App_rpt-users] Command Mode Timeout

Kent Ochs kentochs at sbcglobal.net
Sat Dec 29 21:25:05 EST 2012


Thank you for a second set of eyes on this problem.  

I am very aware of the Radio_Relax parameter and it is not my intention to reopen those discussions.  I am willing to accept an occasional false decode.

Changing the code to 4123 would certainly resolve the issue, as would disabling it altogether.  The real problem is the fact that *40 opens the last node a command was issued on, otherwise it would take at least *4XXXX to start a command session.  I'm still try to understand under what circumstances I would need to put a node into Command Mode.

Can anyone confirm, that as Monty has indicated, totime it is watching the receive side?  If it is, then it would be nice if there was a timeout timer that actually watched the transmit side. 


 From: Ken <ke2n at cs.com>
To: 'Kent Ochs' <kentochs at sbcglobal.net>; 'Monty' <monty at ke7jvx.com> 
Cc: app_rpt-users at ohnosec.org 
Sent: Saturday, December 29, 2012 6:20 PM
Subject: RE: [App_rpt-users] Command Mode Timeout

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.
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/2c416ef8/attachment.html>

More information about the App_rpt-users mailing list