[aprssig] Throttleing EchoLink Objects

[Pete Loveall AE5PL Lists]

javAPRSSrvr makes up less than 20% of the IGates out there (probably much less).  Adjunct like you are talking about would be next to useless.

As I indicated before, APRS-IS is not a good mechanism for blasting large amounts of data out to one or two properly configured IGates (yes, that is about the number that would get it right), especially since the three or four mobile operators that have a second in their car watching the display for Echolink nodes will probably not be in the area with a properly configured IGate.

A few years ago we had "the sea of blue".  This was not CWOP (that was a different issue already explained earlier in these threads).  This was an experiment of injecting all of the METAR (airport) weather information, all buoy reports, all wild-fire reports, etc. into APRS-IS.  We quickly saw the bandwidth damage and, more importantly, the lack of benefit to 99.999% of the amateur radio community.  That didn't make that other .001% unimportant; it just made it necessary to find a new home for this and other experiments where the information is readily available elsewhere and not of great value to the general RF-bound amateur community.  That experiment was Firenet and that subnet still exists, although the server is not under heavy usage these days.

I bring this up to remind us all that sometimes the best intentions do not generate the desired results.  There is zero benefit to having an already overcrowded APRS map generated from APRS-IS show more information that is otherwise found elsewhere on the Internet.  The primary purpose of APRS-IS today is to interconnect the RF APRS networks.  Yes, Echolink is an amateur endeavor.  It has been asked "what is the difference between having individual stations generate objects and a central server?"  Very simple, normalized dataflow (not bursting whenever the central server does an update) with accurate and timely station status.  It also leaves in the hands of the Echolink station owner the choice of whether they want their station to be "known" on APRS.  If you get only 40 or 50 stations participate, then you must assume that the other 2000 don't want to be advertised on APRS or they just don't care.  In any case, it is their decision, not yours.

After reading all of the bantering back and forth, I guess I am fully in the camp of "scuttle the idea of a central server doing it all" and approaching Jonathan about giving Link and Repeater operators the ability to send their "packet" to APRS-IS instead of or in addition to sending it to a TNC.  This would give a mechanism for an Echolink operator to make an agreement with a local IGate operator so the Echolink operator doesn't have to have two radios dedicated to the link/repeater.

73,

Pete Loveall AE5PL
pete at ae5pl dot net





> -----Original Message-----
> From: Lynn W. Deffenbaugh (Mr)
> Sent: Wednesday, July 22, 2009 9:16 PM
> 
> 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.  If the IGate operator directly configured the beacon, it'd
> keep cluttering up the RF channel regardless of the actual availability
> of the node it is advertising.
> 
> 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.  Then we only need the IGate
> operator to add the adjunct once and all current and future EchoLink
> nodes would be gated and any obsolete nodes would just stop.
> 
> But it still needs the APRS-IS to deliver the data to be gated.