[aprssig] New and playing

[Robert Bruninga]

>>> ve7gdh at rac.ca 11/18/04 3:50:48 PM >>>
>Keep in mind that there are lots of "plug and play cars" 
>running around on the highways and bumping into people 
>or things these days. I don't hear you complaining about 
>the cars. 

Well, I will! <grin>

>Let's concentrate on driver education instead of shooting 
>down the car manufacturers. 

If the car MFRS make cars that hog the road network
at the expense of others (and I can think of all kinds of
examples) then I will complain about the manufacturers.
Because human nature will cause people to choose what
is best for -them-, not what is best for others.  That is
why MFRS (and code writers) must share the responsibility
for sharing the network (or road)...

>Unlike many areas of amateur radio, APRS requires a bit 
>of cooperation to make it work. 

You got that right!  And a lot of that cooperation for sharing
the nnetwork should be built into the code, not be dependent 
on expecting people to violate human nature....  The "its-a-
beautiful-mind" movie guy got the Nobel Prize for proving that
human nature will always choose what is best for the individual
at the expense of everyone else no matter how much you 
prove to them that doing what is better for everyone will
actually get you a better overall return...


>We are going through growing pains now that just didn't 
>exist when it was a new concept and only a few people 
>were doing it.

No, what we are experiencing now is the emergence of 
some popular software clones that have practically none of 
the network stewardship parts of APRS built in.    They 
do little to share the channel, do nothing to decay out old 
data or give priority to new data, do nothing to improve 
ACKS so that there are fewer MSG retries, do nothing to 
warn users of distructive paths, nor limit their ability to choose 
them.  Does not automatically adjust net-cycle timing, allows
users to choose any timing they want to trample others.
They do not not randomize multiple transmissions.

All of those were fundamental to the APRS protocol and to
the sharing of the channel.  What we have today are map
authors writing code to display positions on maps, and 
making NO ATTEMPT at network stewardship, reliability
and paying any attention to the proper implementation of
the protocol...

>I'm convinced that problems are "user problems" and not 
>problems caused by the software authors.

I disagree completely.  Any understanding of the 1200 baud
channel and the desire to communicate REAL-TIME about
new and changing data to everyone reliably would tell any 
thoughtful observer that the implementation in some "aprs" 
software is bad.

> All you can do is build desirable features into software that 
>you write, and suggest those features to other authors. Over 
>time, maybe it will be a perfect world, but for now, let's help 
>the new guys (I was one just a year ago) and also help 
>educate the ones that are abusing the system either 
>intentionally or otherwise.
 
I say sure!  But lets also FIX the software that does NOTHING
to educate those users, nor help them share the channel, nor
guide them to "see" the network, nor display for them the
range of the RF network and its limitations, nor encourage
good paths, nor punishes bad paths... etc...

Its not the users fault.  Its the software that does not *help*
the user do the right thing nor help the network to work more
efficiently independent of user mistakes...

Sorry, I get wound up, but the APRS channel is getting worse, 
not better and I cant just sit by and watch it become a useless 
internet video game which is functinonally useless in the real world
on RF for a local event...  except for the stations that run 100W
and use the path of WIDE7-7...

de WB4APR, Bob