[aprssig] APRSLink

[Bill Vodall WA7NWP]

> It also doesn't mean, as you imply, that it will work a large percentage
> of the time.  Let's take a look at some simple statistics: over 50% of
> all the RF clients are either Kenwood radios running in APRS mode or
> UI-View.  Neither of these will ever be "smart messaging clients" nor
> will UI-View be a "smart IGate" per your definition.

So they're obsolete?  (Do I smell a troll?)

>  Use of APRSLink is
> pointed towards the mobile or portable user.  Their paths to/from an
> IGate will vary greatly and the mobile can vary greatly over a short
> period of time.  All of this actually makes your "smart" path operation
> less efficient that simple "flood" operation.

That is a valid point I hadn't considered in the APRSlink scheme.  Not 
so much for general RF messaging.   On the other hand, large changes of 
vicinity for a mobile is not the norm.  In my personal example, there 
have have 4 days of "mobile" action in the past four months.  The rest 
of the time has been in a fixed region.

>>So we should continue to refine the software to make more 
>>intelliget guesses.  That's what I said.
> 

> That is NOT what I said, however.  Using the "let's make 'intelligent'
> guesses" method for determining paths will result in significantly more
> packets being sent than standard flood paths simply because of the
> number of wrong guesses it takes to make an "intelligent" one when
> dealing with _multiple_ packet APRS messages.

That shouldn't be true.  A smart system should learn quickly what works 
and thus be saving packets in a matter of minutes.  It's a great project 
for somebody interested in AI...

> We can talk about ifs and wishes all day long and it still doesn't
> change what I said in my first post.  Before people go running out to
> their radios to try APRSLink, they should understand what the
> ramifications are in _today's_ world in their APRS LAN and what the
> intent was of the authors.  'nuff said.

Absolutely on the first part.  Everybody should understand what's going 
on.   If the system is too busy, that's the time to make an alternate 
cell - not to restrict the functionality.

Authors intent has little to do with it.  Many great inventions have 
come from finding new or better uses for technologies then what the 
author intended.   It's from stretching our tools and technologies that 
we progress.

>>PS.  Once we locals start using the APRSLINK and our local 
>>equivalent for message announcements -- the next step is to 
>>tie it in with Echotime on the local repeater.  *77* to hear 
>>who has Email waiting.  This is starting to be fun.
> 
> 
> A great application for Echolink (I am assuming you mistyped here) and

Gotcha...   Check google.   It's a very nifty add on to echolink.  It's 
letting us add-on to the voice repeater just as digi_ned is letting us 
add-on to the APRS and legacy/TCP packet systems

> IRLP: having an email reader accessible to those networks which would
> allow a person to check their Winlink account using a simple touchtone
> sequence.  But, that is not APRS so best passed over to the Winlink

It is APRS.  I'm envisioning checking any email account by the 
echotime/digi_ned toolbox.


73,
Bill