[aprssig] Throttleing EchoLink Objects
steve at dimse.com
Wed Jul 22 22:43:37 CDT 2009
On Jul 22, 2009, at 10:54 PM, Lynn W. Deffenbaugh (Mr) wrote:
> Almost, I want to see the EchoLink nodes on BOTH platforms. RF for
> the mobile or non-Internet connected user, and -IS interleaved with
> the remainder of the APRS landscape for trip planning in advance. I
> know the data is available elsewhere, but I would like to see it
> integrated in one view.
As Pete summarized, we have had a lot of issues with putting stuff on
APRS IS because it is convenient or cool. Unfortunately we are victims
of our own success and we must be selective about what we put on the
APRS IS. My criteria for what belongs on APRS IS are:
1. Data not available elsewhere. CWOP was here (and 2, 3 and 4) until
it ran afoul of number 5.
2. Data somewhat useful to a lot of people. I place weather warnings
in this category as well as the next two.
3. Data highly useful to some people. This would be messaging for
4. Data critical in emergencies. If there were, say another hurricane
in New Orleans and someone uploaded Echolink status for nodes within
100 miles I'd put that here.
5. Most importantly, data whose #1-4 advantages are not outweighed by
the disadvantage of its volume.
Unfortunately when I look at this proposal, I see a maybe on number 3
(I'd give you a yes if it automatically appeared on on every
appropriate RF net, but requiring IGate configuration drops it to a
maybe at best). It fails on all the others, especially number 5 even
at the one hour time interval where you have taken any potential
usefulness and diluted it greatly.
Sorry, but to me being possible, cool, and convenient are just not
>> 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.
> I'm still not enamored of trying to reflect the realtime status
> (Available, Busy, Conference) in the object. I think we'd be ok
> with just Online and completely suppressed for Offline. If we
> included the ABC status (+-= in the current proposal), that's a
> bonus but a snapshot of the status at the time of beaconing.
The one possible justification that fits with APRS being a real time
tactical system is to have this data be real time. Otherwise a user
could go to echolink.org and print out a list of nodes along his route.
>> 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!
> Unless it is as I described above. In order to do messaging, we
> have to gate from Internet to RF. If we put our licenses at risk,
> so be it.
Fortunately for everyone, the creator and the leadership of the APRS
IS feels a sense of responsibility for its users. We fight those
things which can harm the internet system, the RF networks, and their
operators. Understand this is not just a legal issue. We believe that
every locality has the right to set its own priorities for its RF
network; we do not dictate what must appear on their RF networks.
Every locality is different, some areas are already grossly overloaded
and this proposal could really harm them.
A mechanism created to allow internet operators (whether Pete, Bob,
myself, or a popular vote) to choose what appears on local RF networks
is very much against our principles. We all certainly try to influence
what locals think should be on there, but that is VERY different from
throwing a programmatic switch and making it so. I hope, even as much
as Bob wants to see his present vision fulfilled, he would agree with
More information about the aprssig