[Xastir-dev] a readable version of the latest official APRS spec?

[Tom Russo]

On Wed, May 25, 2005 at 08:16:02AM -0400, we recorded a bogon-computron collision of the <alan at columbia.edu> flavor, containing:
> Thanks Tom and Tapio.
> 
> I believe I also made dupe checking in my aprsdigi code always be turned 
> on so it's already suppressing dupes to RELAY and WIDE.  I guess I just 
> assumed dupe checking is a good thing and didn't think it made sense for 
> the *user* of the digipeater to be the one to decide whether dupe 
> checking is to be done or not.  So, I think my code already implements 
> everything that's needed and I'll be leaving my RELAY and WIDE aliases 
> in until things settle down.  We still have old-style non-fancy TNC 
> digis in this area anyway!

Tapio's right: It's mostly a parameter change, not a big code change.

I think the prevalence of old-style non-fancy TNCs are exactly what Bob's 
trying to deal with using his "new n-N paradigm hoops" --- if every digi
used good software that could always dupe-check even on RELAY and WIDE, or if 
the APRS infrastructure were a real network with no explicit source routing, 
there'd be no need.  But since most digis in most areas are just TNCs, the 
hack is needed --- even then it's going to take for-freakin'-ever to get it 
implemented.  Leaving RELAY and WIDE in the MYALIAS parameter of simple 
TNC-based digis is a Bad Thing in areas where coverage by WIDEn-Ns is good.  

Things are mostly settled down.  It got a little crazy a few months ago, with
the recommendations changing every few weeks (you shoulda seen it when 
the recommendation was all about SSn-N, LNKn-N, linear digi paths along
freeways, alternate channels, etc.).  But now since the recommendations are 
very simple (don't use RELAY and WIDE aliases, fill-in with WIDE1-1 alias when 
necessary, limit to short paths) it's got some acceptance and it's getting 
implemented in some places.  Not my area, unfortunately --- Albuquerque's 
triple- and quadruple-covered by KPC-3+ WIDEn-N digis on mile-high mountain 
tops, still answering to RELAY and WIDE, and people still driving around with 
"RELAY,WIDE" for their paths.  

> Tapio Sokura wrote:
> >Tom Russo wrote:
> >
> >>In a nutshell, as I understand it:
> >
> >
> >And in another nutshell, a digipeater that has working dupe checking no 
> >matter what path the user uses shouldn't need much _code_ changes. Maybe 
> >implement hop count limiting/trapping some way if it's not implemented 
> >already.
> >
> >What I'm trying to say is that there should be no need to completely 
> >remove features like the traditional RELAY and WIDE digipeating from the 
> >code, just keep them as configurable items. There are many places in the 
> >world that are not jumping through Bob's new n-n paradigm hoops anytime 
> >soon so it would be nice to be able to use current software versions for 
> >more "traditional" paths.
> >
> >Someone mentioned digipeating longer/shorter paths and packets from 
> >close/far away depending on channel loading, it sounds like something 
> >that could be nice in a digipeater. But this isn't really part of the 
> >new n-n agenda, just a feature suggestion if you feel like you'd like to 
> >implement something new in the digipeater..
> >
> >  Tapio
> >_______________________________________________
> >Xastir-dev mailing list
> >Xastir-dev at xastir.org
> >https://lists.xastir.org/mailman/listinfo/xastir-dev
> >
> _______________________________________________
> Xastir-dev mailing list
> Xastir-dev at xastir.org
> https://lists.xastir.org/mailman/listinfo/xastir-dev

-- 
Tom Russo    KM5VY     SAR502  DM64ux         http://www.swcp.com/~russo/
Tijeras, NM  QRPL#1592 K2#398  SOC#236 AHTB#1 
 "The only thing you can do easily is be wrong, and that's hardly
  worth the effort." -- Norton Juster