[OZAPRS] European v USnewparadigmand pathlimiting +confusion....

Tue Nov 7 12:02:45 EST 2006

> We're using KPC3+ (with 8.2 firmware) in VK6 (eg VK6KRB-2,
VK6KSB-1)
> 
> Can I ask why ZONEn-N is defined in the UIFLOOD parameter?  
> Why don't we just define it in the UITRACE parameter (
> along with WIDE), and then it is traceable?

Because there can only be one parameter in UITRACE.  We DO want
WIDEn-N to be traceable, so it gets UITRACE.  This leaves you
with UIFLOOD unused.  So that is why we came up with SSn-N to
find a good use for UIFLOOD which is not traceable except to the
LAST digi (with ID turned on).  But since the LAST digi is
pretty useless info and the FIRST digi is very important info,
then that is why we suggest tht SSn-N users that use that path,
should use SS1-1,SSn-N so that the first digi gets identified.

OK, now with the 8.2 ROMS we have a problem, because they to do
not mark a final WIDEn-0 with a *.  This means that
WIDE1-1,WIDEn-N dies at the first hop.  Also SS1-1,SSn-N would
also.  This is why for the 8.2 ROM, the workaround is to set the
digi so that it digipeates the WIDE1-1 and SS1-1 with callsign
substitution first.  Use these parameters:

UIDIGI SS1-1,WIDE1-1,WIDE5-5,WIDE6-6
UIFLOOD SS,30,ID
UITRACE WIDE,30

OOPS, I think there is anotehr bug in the UITRACE function in
the 8.2 ROMS and so we didn't do it that way.  We actually ended
up receommending this for 8.2 ROM digis:

UIDIGI SS1-1,WIDE1-1,WIDE5-5,WIDE6-6
UIFLOOD WIDE,30,ID
UITRACE SS

This is so that WIDE1-1,WIDEn-N is traced at least with the
FIRST and LAST digi, and UITRACE on SSn-N works, but has some
bug (I cant remember right now), so UITRACE in the 8.2 digis
should be avoided...

The WIDE5-5 and WIDE6-6 are just TRAPS to prevent those from
going more than one hop.  We assume here that no one anymore
would ever use WIDE7-7...

Again, SSn-N is for relatively LARGE are nets (but not routine
operations).  Smaller areas that can be hit with WIDE2-2 or
WIDE3-3 don't need any SSn-N path...

Bob

> 
> -----Original Message-----
> From: ozaprs-bounces at aprs.net.au 
> [mailto:ozaprs-bounces at aprs.net.au] On
> Behalf Of Robert Bruninga
> Sent: Tuesday, 7 November 2006 8:28 AM
> To: 'VK / ZL APRS Users'
> Subject: Re: [OZAPRS] European v USnewparadigmand pathlimiting
> +confusion....
> 
> > I think Bob summed it up here
> > 
> > >The SSn-N is for organizing APRS communications networks 
> > >around specific organized communication areas and needs....
> 
> Yes, ZONES...
> 
> But zones based on any existing "organizational" boundaries
> between communications organizations.  These Ham radio
> communiations organizations usually match perfectly with the
> government or public service sector that those volunteer
> organizations support.  So again, don't tie them to geographic
> boundaries necessarily, but to "comm" boundaries between those
> areas who form-up as nets when emergency communications are
> needed.
> 
> Again, we call them SSn-N because most ham radio emergency and
> public service response nets and teams are organized at the
> State level in the USA (or smaller for larger states), but if
> you make sure that your zones match your COMMS organizations
> coverage areas, then that is the intent of the SSn-N system.
> EXAMPLE:  This is so that someone in the ZZZ zone can check in
> with APRS to the ZZZ area net using ZZZ5-5 hops that is called
> up every Tuesday night at 8 PM... For example, without QRMing
> the entire country.
> 
> Lets say it takes 5 hops to go from one end of a zone to the
> other.  Then users in the middle of that zone only need to use
> the path of ZZZ3-3.  But those people on the edges may have to
> use ZZZ5-5 to cover the zone.  But this is far different from
> using WIDE5-5 which goes 5 hops in ALL directions instead of
> just inward to the ZZZ zone.  That is the advantage of ZZZn-N
> routing.  An order of magnitude reduction in QRM during these
> events.
> 
> Now consider this!  Since the objective of ZZZ3-3 in the
center,
> or ZZZ5-5 from someone on the edge of the zone is to hit all
the
> digis in the zone, then there really is no difference between
> ZZ3-3, or ZZZ5-5 or ZZZ7-7 for that matter.  It is still going
> to hit every digi and that is the intent of this ZONE system.
> So, for these ZONE wide nets, then ZZZ7-7 is no different.
That
> too is the advantage of the ZZZn-N system, in that all QRM (if
> abused) stays in the ZONE.
> 
> Again, ZZZ7-7 or 5-5 is NOT used routinely, it is only for
> specific purposes within that ZONE.  But when it is used in a
> ZONE WIDE net, then that is the only time that statiosn use
the
> larger hops above say ZZZ3-3 or so.  But it is OK to use
ZZZ2-2
> routinely if there is an advantage to it over WIDE2-2...
> 
> One LAST thing:
> 
> Since the New-N paradigm makes WIDEn-N traceable by using the
> UITRACE parameter, this means that the ZZZn-N system used the
> UIFLOOD parameter that is NOT traceable.  This is a
> disadvantage.  But here is the workaround.  If UIFLOOD in the
> DIGI's (KPC-3+ TNC's) is set to UIFLOOD ZZZ,30,ID then this
> forces at least the LAST digi to insert its call.  Now then,
if
> the users use ZZZ1-1,ZZZn-N you get a packt that will arrive
> everywhere with at least its FIRST and its LAST digi
identified.
> These two are most of what you need.  So a ZZZ1-1,ZZZ3-3
packet
> would arrive like this:
> 
> ZZZ1-1,ZZZ3-3  as heard direct
> DIGI1,ZZZ1*,ZZZ3-3 heard via DIGI1
> DIGI1,ZZZ1,DIGI2*,ZZZ3-2 heard via DIGI1 and DIGI2
> DIGI1,ZZZ1,DIGI3*,ZZZ3-1 heard via DIGI1 and ??? and DIGI3
> DIGI1,ZZZ1,DIGI4,ZZZ3*   heard via DIGI1 and ???,??? and DIGI4
> 
> If you don't use the initial ZZZ1-1, you never get the first
> digi identified...
> 
> Now, only the KPC-3+ TNC does this correctly,  If you use an
> older KPC-3 with only version 8.2, then it can be made to
work,
> but takes some other settings at the digi.  I have no clue
> whether Australia uses KPC3's anyway, so I will stop here
until
> I learn more...
> 
> Bob, WB4APR
> 
> 
> 
> > -----Original Message-----
> > From: ozaprs-bounces at aprs.net.au 
> > [mailto:ozaprs-bounces at aprs.net.au] On Behalf Of Andrew
McDade
> > Sent: Monday, November 06, 2006 5:43 PM
> > To: VK / ZL APRS Users
> > Subject: Re: [OZAPRS] European v USnewparadigmand 
> > pathlimiting +confusion....
> > 
> > Gday all,
> > 
> > I think Bob summed it up here
> > 
> > >The SSn-N is for organizing APRS
> > >communications networks around specific organized
> communication
> > >areas and needs.  Not specifically geographic areas.
> > 
> > Perhaps referring to this as SSn-n is causing some
confusion. 
> > Id prefer it to be referred to as ZONEn-n. And be based on a

> > setup whereby the first 4 letters of the major centre 
> > containing the zone ( regions ) igate is the path ie.
MILDn-n 
> > = Mildura. LINCn-n = Port Llincoln, GAMBn-n = Mt Gambier,
and 
> > so on. In Tasmania for example , instead of using TASn-n , 
> > perhaps we should use HOBAn-n or NTASn-n or STASn-n, If this

> > zone covers the whole of a state then well be it. This will 
> > at least then head towards developing some sort of 
> > commonality between all states. 
> > 
> > And to summarize Dion ... 
> > 
> > This is the most important point !!
> >  >think its these differences that need to be sorted, like 
> > the confused  
> > >operator in the next message asks, which path will work?
If 
> > we could all  
> > >settle on one configuration, this confusion would be 
> > eliminated.  Mobiles  
> > >that stay close to home would/could use SS1-1,SS2-2.  
> > Roaming mobiles  
> > >would use WIDE1-1,WIDE2-2..  I think the US example is 
> > excellent, it  
> > >simplifies everything.
> > 
> > Seems simple enough to me !!
> > 
> > Only point here is perhaps we should refer to this as
ZONEn-n 
> > instead of SSn-n. What to you think ?
> > 
> > Regards .. Andrew .. VK5EX
> > _______________________________________________
> > Ozaprs mailing list
> > Ozaprs at aprs.net.au
> > http://aprs.net.au/mailman/listinfo/ozaprs
> > 
> 
> _______________________________________________
> Ozaprs mailing list
> Ozaprs at aprs.net.au
> http://aprs.net.au/mailman/listinfo/ozaprs
> 
> _______________________________________________
> Ozaprs mailing list
> Ozaprs at aprs.net.au
> http://aprs.net.au/mailman/listinfo/ozaprs
> 

_______________________________________________
Ozaprs mailing list
Ozaprs at aprs.net.au
http://aprs.net.au/mailman/listinfo/ozaprs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://second.aprs.net.au/pipermail/ozaprs/attachments/20061107/ef5122d6/attachment.htm 