[aprssig] New n-N success in North Carolina

[Wes Johnston]

The problem with the "trap out" method is that even if you trap W7-7,W6-6, and
W5-5, you still let the W7-6's and W7-2's thru....

There is another way and that is to support the alias of WIDE2-2,W2-1,W3-3,W3-2
under the UIDIGI setting.  It'll give ONE more hope to each elligible packet.

Eric, I agree with you...  SSn-n is the way to go.  Ok, fine, we can support ONE
hop and one hop only for W2-2 people by putting W2-2 in the UIDIGI setting.

Ideally, I'd really like to see is a hop count limit.  If this existed, it would
be fine for a fellow to run W7-7.  When he wandered in to an area where 2 hops,
his packets would be digipeated until they got to WIDE7-5.  Now imagine a guy
approaching a metro area.  Some of his packets would go toward the metro area,
other packets would head off in the rural direction.  Those packets going into
the metro area's 1 or 2 hop limit digi's would not be digi'ed once those
packets were decremented to W7-5.  Meanwhile the copies of packets going toward
the rural area's 5 hop limit digi's would continue to be digipeated until they
got to W7-2.  They could feasible route around the city! What I'm getting at is
that each area could filter the same packets to varying degrees...  wow.. what a
shame a hop limit wasn't spec'ed when the UIFLOOD was first written.

I kinda get a chuckle out of this next suggestion.  If I (or someone) was to
produce a KISS mode controller based on a PIC chip, it would probably cost $35
(around the price of a tiny trak).  This device could be added on to the back
of a kpc3 tnc in kiss mode and powered from pin 13 or pin25 of the serial port.
 The part I chuckle about is that kantronics wants $60 for firmware, but it
would be a neater solution.

Wes
--



Quoting "Eric H. Christensen" <kf4otn at earthlink.net>:
> > 1) SSn-N is still a perfect way to go for most local ops
> >     it remains a great feture of the New n-N Paradigm
>
> Absolutely!
>
>
> > 3) We found a simpler way to TRAP large N hops without
> >     haivng to drop WIDEn-N completely
>
> This will not work.  Yes, you can trap SOME of the WIDEn-N packets
> but that won't stop 4-4, etc.  PLUS, in NC we are putting additional
> LANs up to support gating of weather bullitens and objects so they
> don't go outside of the area. (We have someone on the Western part of
> Virginia or NC that is sending out bulletins to a very WIDE area.)
> So we don't have room to trap all these bad n-N packets.  By doing
> away with WIDEn-N, we have freed up our network from a lot of packets
> that used to come in from all over.  John's assessment is accurate.
>
>
> >
> > 4) LNKn-N will never work since it simply takes too much
> >     coordination and wont be of any value unless all links
> >     in the chain are good.    It has been abandoned
>
> I disagree.  As you coordinate the SSn-N you coordinate the LNKn-N.
> We ALREADY have THREE digipeaters up on the 95LNKn-N and that was
> within a month.  Not a lot of work there...
>
>
> >
> > What you have done is a great positive step.  But please
> > re-visit the New n-N Paradigm site and prepare for one more
> > round of changes.  Basically, send out a bulletin reminding
> > everyone how much better SSn-N (or Wn-N) is than W,W or R,W.
> > Then you can turn back on the WIDEn-N but with the filters on
> > 55,66,77 or what ever limit you want...
>
> I think the next best thing is to eliminate the WIDE and TRACE.
>
>
> >
> > >This has been the best thing that has happened to APRS
> > >to date. I hope we don't back track to our older ways.
> >
> > ANd thanks for trying it.  And dont be upset with this
> > latest change.  We have learned a lot from the user
> > feedback and it will make it even better...
>
> I disagree.  Even letting WIDE4-4 through would bring in many packets
> from hundreds of miles around and then we are back at square one.
>
> Eric KF4OTN
>
>
> >
> > de WB4APR, Bob
> >
>
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
>