[aprssig] The new N-N paradigm summary (fwd)

[scott at opentrac.org]

The only excessive WIDEs I see from outside the area on a regular basis are
from a handful of digis in Nevada and thereabouts.  Yeah, some of the locals
could learn to reduce their paths, but the west coast has a pretty large
buffer of sparsely populated areas surrounding it and I don't see saturation
problems here.  I'm sure the LA basin is another matter, but that's local
traffic.

Scott
N1VG

-----Original Message-----
From: aprssig-bounces at lists.tapr.org
[mailto:aprssig-bounces at lists.tapr.org]On Behalf Of Wes Johnston
Sent: Tuesday, January 04, 2005 4:27 AM
To: TAPR APRS Mailing List; Cap Pennell
Subject: RE: [aprssig] The new N-N paradigm summary (fwd)


We'll still have a universal path.. it will be WIDE,WIDE or RELAY,WIDE.
Cap,
with all due respect, your area must not be as saturated as mine, so you
aren't
bothered by the wide5-5's and wide7-7's streaming in from 300 miles away.

You say that this conversion is short sighted, but I (obviously ;-) )
disagree.
It _would_ be counter productive if not for the 'still to remain universal'
path
of RELAY,WIDE.  You are incorrect about dupe checking in the KPC3's... They
use
a checksum of the dataportion of each digipeated packet for the Wn-n and
Tn-n
packets, and they use callsign substitution for dupe checking on the UIDIGI
type of packets (wide w/o the n-n).  This second method is far from optimal,
but it is a limited dupe supression method.  The problem comes in when, say
2
WIDE stations hear my packet and the next furtherest digi ends up hearing
both
copies.  It'll digipeat both of them because it doesn't see it's callsign
has
been substituted in either of them.  WIDEn-n would not do this.  However the
solution is to make sure that UIDWait if off so that both digis that heard
me
transmit as soon as my packet is complete.  They both TX at exactly the same
moment, and the next furtherest digi only copies the packet from the one
nearest to it due to FM capture effect.  But, the n-n digipeating is perfect
for dupe supression.

This switch over will be view by many as we view the metric system switch
over... people will say the metric system is too darned hard.  What's really
difficult is the _conversion_.  If you live in a purely metric world or a
purely english system world, you are happy.  The problem is getting there,
not
being there.  Once this conversion is complete (along one interstate for
example), you will be able to send a packet further than ever... in ONE
direction.  It will not be unethical to run a path of 95LNK7-7 or SC7-7 as
it
is now a LID offense to run WIDE7-7.

Enjoy your trip!
Wes
--



Quoting Cap Pennell <cap at cruzio.com>:

> I'd simply like to register my opinion (before slipping off on a trip, so
> unfortunately I won't see any replies).  I think this is a short-sighted
> idealistic plan, in search of a problem.  That would be okay, and I
haven't
> complained before now because it seemed like another harmless idea.  But
now
> that it's become an idea to move away from WIDEn-N it has too much
potential
> to cause excessive harm to our existing modern fully WIDEn-N capable VHF
> network in California (and throughout the Western US).  The existing full
> WIDEn-N network in California and adjacent states _is working_.  I've seen
> different problems on the East coast where not all the digis are WIDEn-N
> capable, but that's not the situation in the Western US.  The WIDEn-N
> network _works_ for hundreds of APRSers here.  It works _beyond_ the
"ALOHA
> circle".  It works _with_ our high altitude WIDEn-N digis.  The "reduced
> throughput" problem on VHF is tolerable, and declining.  There really
aren't
> many severe negative consequences of "reduced throughput due to packet
> collisions on VHF" except slow message ACKs for those keyboarding.  The
VHF
> WIDEn-N APRS network is amazingly resilient!  Warnings of a VHF net "death
> spiral" have been greatly exaggerated.  More of our users are learning
that
> simply WIDE2-2 is a good path for general use, and it works.  It's better
> than a path that includes any commas.  Using only WIDEn-N or TRACEn-N
> produces no dupes.  Kantronics TNCS do not do any dupe checking on packets
> other than with pure WIDEn-N and TRACEn-N paths.  RELAY or WIDE or TRACE
> aren't much needed, and digipath commas cause loss of dupe-checking in our
> Kantronics TNCs. Going back to RELAY,WIDE (or worse yet RELAY,WIDE,WIDE)
> would be a step backward in California.  For years, we've been educating
> local users that using only WIDE2-2 or TRACE2-2 will do the job for the
VHF
> community of APRS users, especially considering very few places in
> California are more than 2 hops from an IGate.  This has slowly been
paying
> off in our fully WIDEn-N capable network over the past few years,
> especially.  Most users have learned to avoid overly broad digipaths (if
> they've learned anything) by now.  Many have learned to avoid commas in
> their digipaths.  We're making good progress, and our VHF traffic load is
> _declining_, despite new stations appearing regularly.  The Western US,
> besides being more complete as a pure WIDEn-N network than the East, is
just
> different topographically, too.  Interstates?  We have high digis
> overlooking the LA Basin that cover big stretches of 5 or more interstate
> freeways at once, and I-5's 800 miles in California can be covered by only
a
> few WIDEn-N digi hops.
>
> So, why lose (throw away) this progress we've worked so hard for so many
> years to produce?  Is there really some new "enforcement" plan or idea
that
> is worth more than all the courteous effort that's already been expended
in
> educating ourselves and our fellow hams on VHF?  I don't think so.  I know
> some feel frustrated with the slow effort of education, elmering, and some
> aren't much good at it.  But I think "nationally" throwing out WIDEn-N in
> favor of LINKn_N or equivalent is like throwing the baby out with the
> bathwater.
> 73, Cap KE6AFE
>
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
>


_______________________________________________
aprssig mailing list
aprssig at lists.tapr.org
https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig