Order Tray | Contact Us | Home | SIG Lists

[aprssig] EchoLink and other Local Info - Future?

Robert Bruninga bruninga at usna.edu
Thu Jul 23 13:55:14 UTC 2009


>> ... the numbers of transient mobile hams
>> routinely reviewing their RF APRS displays for 
>> locating nearby Echolink stations... Will be 
>> just about the same... as APRS stations 
>> actually transmitting !x! or RFONLY...
>
> I have been beaconing the presence of my RF-link 
> Echolink node... In two years... exactly ONE user 
> discover it via APRS. 

AH, but that is thinking only inside the tracker box.

Using the above logic is like taking one word in the dictionary
(out of 600,000) and looking at the statistics of how often each
word is looked up, and since probably 95% of all the words are
only looked up 0.0000001% of the time, they should be
eliminated...  Keep going and about the only word left in the
dictionary is antidisestablishmentmonterianism.

On APRS, keep that attitude up and the only thing left will be
dumb trackers, and on-line shack-potatoes, with no information
content at all.  We have got to buck that trend by thinking
outside of the tracker box.

In the above case, I consider that beacon a success!  That one
user (who uses APRS as an info resource) was happy, and APRS
fulfilled the promise of what it was designed to do.

> [but] I HAVE had numerous users discover the node 
> via the online listings at echolink.org, or by using 
> the CQ-equivalent random-connect feature of Echolink.   

In talking with the Echolink Author, he too is as fed up with
EchoLink being used by shack-potatoes instead of RF as I am
about APRS being treated like an on-line video game.  One of my
recent requests to better integrate APRS (a data and universal
frequency independent contact system) with EchoLink (voice
contact), involved data that was only best viewable on-line.  He
rejected it out of hand, because he now tries to add nothing to
EchoLink that enhances the on-line experience at the expense of
the RF experience.

As far as this EchoLink objects project, we have arrived at a
show-stopper (traffic load).  To me, that simply offers a
challenge.  I see two possible approaches?:

1) A widget that runs in parallel with a local Igate, but that
can share the TNC.  It gets the Echolink status periodically
just for the local object, and then it beaons that object ONLY
to its own path (independent of the Igate's path).

2) An upgrade to the APRS-IS that provides regional feeds, so
that Lynn's engine can inject only regional info into regional
feeds.

I asked Pete Lovell if there was a way for the two-tier APRS-IS
to provide a regional feed of these objects and got a one-word
answer "no".  That may be true for the existing system.  But I
challenge the APRS-IS, then to move on and figure out a way to
do it anyway.  To meet the needs of Amateur Radio, we need an
alternative to global distribution of local info.

There are some very clever people working the APRS-IS.  Given
the challenge to provide more pertenant info direct to the
mobile operator, I would hope that they can figure out a way for
the future to provide this info without flooding the global
system.

It seems to me that some kind of regional feeds might be a
solution...  If the current system cannot do it, then is there a
way to figure out how to add it for the future without breaking
anything?

Bob, WB4APR





More information about the aprssig mailing list