[aprssig] Gating Objects from Internet to RF

[Lynn W. Deffenbaugh (Mr)]

Pete Loveall AE5PL Lists wrote:
> My main comment is don't use KJ4ERJ as the "from call".  Why?  Because you already use it and ALL station callsigns must be unique.  Having multiple software/stations use the same callsign will cause loop checking algorithms to sometimes delete non-duplicate packets.
>   
I liked Mike (kb8zgl) comment:

"It would seem odd to me to see my KB8ZGL-R EL object come from someone
else's callsign. That would bother me more than seeing it come from my own
callsign even though I didn't put it out there."

The ToCall will be APELNK and I'll have that added as an "official" 
ToCall documented with my call as the source of the packets.  I'll still 
include ,KJ4ERJ* in the path of the APRS-IS injected packets so they'll 
see it there as well.  I really didn't like being the FromCall of these 
objects.  The information in the object is owned, mastered, and 
controlled by the EchoLink node operator.  Their call should be the 
FromCall.


> I highly recommend using a unique callsign that, as Mike mentioned, could then be Googled and the explanation/contact information for that "station" would easily be found.
>   
That's the intent of the APELNK ToCall.  As soon as Google picks up the 
change, anyway.
> I recommend sending this out no more often than every 10 minutes to keep from overloading an RF frequency.  Now, that said, one of the original thoughts on Echolink objects was to have them sent anytime there is a status update (busy to online, for instance) or every 10 minutes, whichever is sooner.  This would require you maintaining a mirror database of sorts indicating when you sent the last packet for a station and what its status was.  The good thing about this method is that, after a while of uptime, the packets would spread out some if you checked the XML every minute, for instance.  Just a thought for "phase 2" ;-)
>
>   
I actually considered trolling the XML that frequently, but really don't 
think it's worth it.  We're trying to show the availability of resources 
on the RF (and -IS viewers), not mirror all of the capabilities of the 
EchoLink Internet client.  I really wouldn't want to be responsible for 
QRMing some remote APRS RF environment just because some EchoLink 
operator is ping-ponging his status every minute!

As for spreading the packets out over time, I'm considering a short 
delay between packet injections anyway so as not to flood the APRS-IS 
distribution channels every 10 minutes.  I haven't figured it out yet, 
but I might inject the current status over 5 minutes and then let things 
settle for 5 minutes before starting again.  I know it means that 
stations at the end of the list are beaconing 5 minute old status, but I 
really don't want to risk flooding either the RF or -IS channels.

Lynn (D) - KJ4ERJ - "Almost there!" (Wedge Antilles, StarWars)