[aprssig] KPC3+ Question

Tue May 22 13:45:11 EDT 2007

Thanks for the info Bob, very useful as always!

The system is put up for a special event and is "closed" in the sense that
it's off the normal frequencies and the configuration of all equipment is
absolutely controlled.

Currently using WIDE3-3 anyway as a beacon will get to the monitoring point
in 3 or less, currently looking at past data to see if we can reduce that to
2.

Looks like we can't do what I was looking to with the existing equipment, so
we'll just carry on as we are!

Jim

-----Original Message-----
From: Robert Bruninga [mailto:bruninga at usna.edu] 
Sent: 22 May 2007 17:47
To: bruninga at usna.edu; 'TAPR APRS Mailing List'; jim at stuckinthemud.org
Subject: RE: [aprssig] KPC3+ Question

You also asked:

> Is there a way of BULIST-ing or excluding certain stations, to control 
> what a digi will actually repeat?

Again, assuming you really want only one-way paths to a single point and
want to cutoff everyone else in the remote areas of your system from seeing
those close to that single point, then there is something you can do.

No matter how all of your 8 digis are arranged, there are some that are
Immediately adjacent to your one-single-point site where you want to collect
the data.  These 1st tier digis only need to digipeat a WIDE3-3 packet ONCE.
Therefore you can put WIDE3-3 into the UIDIGI LIST settings.  Then when a
WIDE3-3 station is in that area, their packets are only digipeated ONCE.
But everyone else beyond that first tier wont see them.  TO me this
undermines the intent of APRS...

Repeating myself, if the central single site you want to receive all this
data is more or less centrally located, I would think that WIDE2-2 would get
packets there from all 8 surrounding digis.  If the one single site is at
the end of a very long string of 8 linear digis, then you are going to have
to tell your users to use SS1-1,SS7-7.  So it all depends...

Bob, WB4APR

> -----Original Message-----
> From: aprssig-bounces at lists.tapr.org
> [mailto:aprssig-bounces at lists.tapr.org] On Behalf Of Robert
Bruninga
> Sent: Tuesday, May 22, 2007 12:25 PM
> To: jim at stuckinthemud.org; 'TAPR APRS Mailing List'
> Subject: RE: [aprssig] KPC3+ Question
> 
> > A question for all KPC3+ experts out there.
> 
> Jim, I'm going to answer based on the lowest common
denominator
> of interpretation of the information you have provided.  That is, I am 
> assuming you have not implemented the New-N paradigm settings on these 
> digis.  Forgive me if you already have...
My
> answers are more for others who may be following this thread.
> 
> > I have a scenario with eight KPC3+ digi's in a mountainous area, 
> > which are set up to get location beacons back to a central point.
> 
> Probably you mean they are "set up" situationally located for
RF
> such that they can all see the central point, that is one
thing.
> Again, I will assume a worst case assumption and assume you
may
> be talking about "TNC settings"...  In that case, there is practically 
> nothing you can do in a digipeater to "force" any particular packets 
> anywhere.  Where the packets go is up to
the
> originator of the packet.  If it takes 3 hops from one of
those
> digis to get the data back to the single specific point, then users in 
> that area will have to use WIDE3-3.
> 
> > Digi's are hill-top, so I want to stop beacons from being repeated 
> > in areas they don't need to be (i.e.
> > cut down the redundant RF traffic).
> 
> Simply implementing the New-N Paradigm in the KPC-3+'s should cut down 
> on all dupes perfectly.  It eliminates all duplicate packets.  Each 
> New-N digipeater repeats each packet once and only once.
> 
> > Control of the route via the sending station is not possible as they 
> > can be anywhere, which is why I'm looking for a "system" solution.  
> > KPCs are running v9.1.
> 
> The system solution is to determine what the worst case path
is
> (say 3 hops) and have everyone in the area use three hops.
This
> is easy to convey to users, since all DIGIS under the New-N paradigm 
> are supposed to show as the first few bytes of their Position Comment 
> something like "W3,SSn-N" to tell users that
> WIDE3-3 is recommended in that area (and SSn-N is supported).
> This displays nicely from all New-N digis.
> 
> Maybe you only want packets to go to the central site, but focusing 
> too much on that one-way path will exclude users in your "system" from 
> seeing each other at the extremes.  In my opinion, you want packets 
> originated anywhere in the area to
be
> able to hit all other digis, so that all users in your system see each 
> other too.  APRS is for all-to-all communications.
> Most mobiles receive and display data as well as just transmit it.
> 
> On the other hand,
> 
> If your "system" is well defined and truly has a specific well defined 
> and well understood mission, then you can set it up
with
> a specific SSn-N system (SS can be from 2 to 5 bytes long).
> Then tell all users in the system to use SSn-N where N is the maximum 
> worst case path from the fartherest extremes of the system.  This will 
> guarantee that all 8 of your digis repeat each packet, but that NONE 
> of the sourrounding states or areas will see any of them.  This might 
> be unfair for the overall regional APRS communicatinos, but it will 
> accomplish what you say you want.  You can even use SS7-7 without 
> regret, because
no
> matter how big "7" is, these packets will still only hit each
of
> your eight SSn-N digis once and only once.  And not spread outward 
> beyond your "system".
> 
> The KCPC3+'s all support both WIDEn-N and SSn-N
simultaneously,
> so this way you can meet your specific unique objective for specific 
> users while also serving the general APRS mobile
public
> as well.
> 
> Hope this helps.
> 
> By the way, if you do implemente the SSn-N system, then the paths are 
> the most traceable if the users use the path of SS1-1,SSn-N.  This 
> will identify the packets when they arrive anywhere by the FIRST and 
> LAST digis in the path.
> 
> Bob, WB4APR
> 
> 
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
> 