[App_rpt-users] Remote Base Limitations

[mike at midnighteng.com]

While I have no direct answers to your problems since I do not quite understand why
you have the problems, but here is how I look at it.

The entire remote base functions should be moved out of the core code and placed as
external AGI scripts. Then every/anyone can have just what they want in adapting
the remote base to what it is they want for the devices they want to control.

What started my thinking this way was...
In the case of a 706MKii, it can't also be used for the standard 706 because the
expected return data is not the same because it was written for the extended
capability of the MKii. Where as if it were written the right way, it could have
been used for both and used much less code.
That is not to say I do not appreciate the time someone took in writing and testing
the code for the remote or 706mkii. I have written many control programs for them
for the last 20 years and I know the time involved in laying it out and making it
work.

But, if you have the communication format for your remote, there is nothing
stopping you from making your own RB set-ups driven from a shell or agi script.
That is how I do it.

...mike/kb8jnm


> I really like the features of the remote base on app_rpt. I have ran into
> many walls, and am getting annoyed at the limits. First, why can't I have
> custom remote commands that run a shell script?
>
> I have written my own shell scripts that steer my radio to where I want it
> to go, because cop commands are not valid in a function-remote stanza, I
> have had to set up my entire node as a standard allstar node, and make it
> private so only select people can transmit on it. Although it would have
> been neat to let anyone listen, and permit TX to stations with the login, I
> have not found a way to do so while allowing my shell scripts to be
> executed being a user of the remote base.
>
> Second, I wish there were more options for telemetry. If I run a playback,
> it will transmit out of my remote base (now in a standard node
> configuration) as well as a remote link. I really wish there was a playback
> style command that ONLY plays remotely, not locally. I can't have my custom
> audio files giving channel steering confirmation announcements coming out
> of 52 simplex.
>
> What I have been able to do is hack around it, use the event management
> system, a few scripts, and the System disable / enable command so that when
> a station connects, the transmitter automatically disables, plays a
> message, and then requires DTMF to re-enable the transmitter. I also have
> it automatically disable TX when the channel is steered so it can run a
> playback without actually TX'ing over the remote base transmitter. The
> problem I have run into is that the transmitter needs to be enabled for a
> station to connect, so I have to re enable the transmitter when the number
> of nodes = 0. It's almost too much hacky hacky for a mountaintop remote
> base that needs to be reliable.
>
> The other part that is sort of annoying is every time the TX is enabled
> (*902 i think) , the user hears "TXENA" (I know, It is not RPTENA because
> my distro has a modified source code which changed it to TX just to make it
> a little shorter)
>
> For anyone interested, this is my steer script : amsatnet.info/steer32.sh.
> I made a few modifications after writing that script, ignore the re-enable
> transmitter at the end, that is what the user has to do by DTMF. Feel free
> to give suggestions or hints to features I don't know about.
>
> 73
> Skyler KD0WHB
> _______________________________________________
> App_rpt-users mailing list
> App_rpt-users at ohnosec.org
> http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
>
> To unsubscribe from this list please visit
> http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the
> bottom of the page. Enter your email address and press the "Unsubscribe or edit
> options button"
> You do not need a password to unsubscribe, you can do it via email confirmation. If
> you have trouble unsubscribing, please send a message to the list detailing the
> problem.