[aprssig] conflicting APRS intructions

[Gary Dezern]

As a fairly new ham and APRS user (and now digi/igate operator), I've  
noticed that a stated goal for APRS is somewhat conflicting.

Take, for example, the statements (from aprs.org): "APRS is not about  
vehicle tracking. It is a single information resource channel ", "APRS  
is not about dumb-one-way-trackers. ", and "And finally, that all  
mobiles would have simple displays to keep them in communicaitons and  
aware of their surroundings."

This implies 2-way communication.  Yet, elsewhere on APRS.org the  
solution for "dead zones" in the APRS network is a "wide1-1" digi -  
documented as:

WIDE1-1 fill-in digis provide a way for mobiles in a dead zone to be
able to be digipeated out without that same digipeater adding to the
congestion elsewhere by also digipeating every other packet heard from
everywhere else.  In otherwords, it only responds to 1st hop packets
from mobiles and/or stations that explicitly use the WIDE1-1 hop first
in their path.

This is in direct conflict with a stated goal of 2-way communication,  
as the "fill-in" is only repeating packets FROM the mobile station,  
and wouldn't repeat TO that mobile station any packet (unless it  
happened to have an unused WIDE1-1 hop specified in its path - which  
is unlikely.)

If the mobile can't talk to the major WIDE2 digi's in the area, they  
likely can't "hear" them either.  The WIDE1 "fill in" digi, in this  
case, only serves to support "dump-one-way-trackers" and does nothing  
to facilitate 2-way communication between the station in the dead zone  
and the rest of the APRS network.

There are other areas that I found conflicting as

To this end, I really like what aprx is doing with the experiment of  
"viscous digitpeating."  This seems to be a BETTER solution to black  
holes than the above mentioned "fill in" digi's (which are nothing  
more than "dumb-tracker" relays.)  It doesn't completely solve the  
problem, as the aprx digi can't know if a local mobile can hear other  
digi's, but I think its a step in the right direction.

Take care
Gary / K3WOW



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.tapr.org/pipermail/aprssig/attachments/20091023/adcb56b2/attachment.htm>