[App_rpt-users] Command Mode use

Sun Dec 30 03:15:52 UTC 2012

*4 is used to run commands on a remote node. (Assuming you have and use more than one node). Possibilities are really endless.

One place I use it:  I have a weather script on my 440 node … it’s a nifty one that gets MP3 podcasts from NOAA and plays them on the air using the Asterisk MP3 player. The podcast files, the player and the script are on the 440 machine. I did not want to put all of that on the other systems. 

The 440 and 224 machines are “perma-linked” together. 

So when a user punches in the code for weather on the 224 machine, it just issues a remote command to the 440 machine and the weather plays on both.

I also do weekly bulletin transmissions – on three systems simultaneously. This requires disabling the TOT (etc) on all three machines, for the duration. The bulletin script runs on one machine and issues remote commands to the other machines to make them go into “bulletin mode” and then back to normal again, at the end.

73

Ken

From: Kent Ochs [mailto:kentochs at sbcglobal.net] 
Sent: Saturday, December 29, 2012 9:25 PM
To: Ken; 'Monty'
Cc: app_rpt-users at ohnosec.org
Subject: Re: [App_rpt-users] Command Mode Timeout

Ken,

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. 

Kent

  _____  

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.

GL

Ken

W4BRM/R

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

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 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.

Monty

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.

Thanks.

Kent

W9KAO

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.keekles.org/pipermail/app_rpt-users/attachments/20121229/900396a3/attachment.html>