[aprssig] Throttleing EchoLink Objects

[Steve Dimse]

On Jul 22, 2009, at 10:15 PM, Lynn W. Deffenbaugh (Mr) wrote:

> Actually, there is a difference here.  When an EchoLink node dies,  
> the APRS-IS feed will automatically quit sending the objects and it  
> won't matter that the IGate operator is configured to get them to  
> RF, they'll just quit.

Let's back up. Are we agreed the point here is to get the beacon to  
RF? If so, do you understand that in order for something on the APRS  
IS to be gated to RF, the IGate operator MUST manually enter the  
callsign of the blessed station or object?

So if I add a new echolink node, it will not appear on RF until the  
local IGate operator finds out about it, and manually edits his  
configuration file.

Yes, you are right that if we choose not to clutter the APRS IS, the  
data will not reflect the changing status of the node, but with  
proposals for updates once every 10 minutes or 1 hour, it is not  
exactly like we are talking about real time information.

> To address that manual configuration issue, I"m trying to figure out  
> if it'd be possible to build a javAPRSsrvr adjunct to make the  
> gating from IS to RF automatic based on the position of the IGate  
> and the position/range of the EchoLink object.

Only for an IGate running javAPRServ. I run a very old version of that  
program on findU, perhaps the new versions are capable of being  
IGates, I'm sure Pete will help me out on this. Even if it is capable,  
the majority of IGates are client programs like WinAPRS and UIView, or  
aprsd. These require the operator to manually configure the blessed  
station list. Nothing javAPRServ could do would control the output of  
these IGates.

This is not a bug. An IGate operator is responsible for everything  
sent out on its transmitter, to pass off automatic control is not  
something I would ever want to see!

Steve K4HG