| |
ZL3AI > APRDIG 20.09.03 10:18l 320 Lines 12289 Bytes #999 (0) @ WW
BID : 1959-ZL3AI
Read: GUEST
Subj: TAPR Digest, Sep 17, 6/7
Path: DB0FHN<DB0RGB<DB0FSG<DB0PV<DB0MRW<OK0PKL<OK0PPL<DB0RES<ON0AR<VK6HGR<
ZL2BAU<ZL3VML
Sent: 030919/1410Z @:ZL3VML.#80.NZL.OC #:8667 [Chch-NZ] FBB7.00i $:1959-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: RELAY,WIDE,WIDE
From: Bob Bruninga <bruninga@usna.edu>
Date: Wed, 17 Sep 2003 17:30:00 -0400 (EDT)
X-Message-Number: 45
On Wed, 17 Sep 2003 WA8LMF2@aol.com wrote:
>Southern Cal digis ignore RELAY -- any path starting with it won't go
>anywhere....
Again, I think this is shortsightedness and another example of hacking the
system without due consideration of all the ramifications while still not
correcting the root problems...
And guess what, They have a very big problem with too many packets from
too many digipeaters. A little thought might suggest that they may be
shooting themselves in the foot...
If they would let mobiles use RELAY correctly and turn maybe half of their
digipeaters into local, lower, shorter range RELAY-ONLY digi's, then that
would go a long way towards *reducing* overall packets on the system.
Remember not only does RELAY help mobiles, it is the basis of the original
APRS two-tier digipeater system that helps provide connectivity without
the rampant exponential increase in packets caused by EVERY digi being a
WIDE or WIDEn digi.
Because there are no RELAY digis in LA to fill in the weak areas (yet NOT
MULTIPLY ALL PACKETS), then ALL packets get the same treatment by ALL
digipeaters and they have too many packets and too many digis.
They have a big problem and there are no easy solutions, but killing RELAY
was a wrong step in my mind. If they are after cheap fixes, then the best
thing they can do is disable WIDEn. I say that partly in jest, but
hummh... maybe it would improve things... It would sure cut down on long
paths in a hurry.
Why wouldnt this HACK solve the LA problem:
1) Go back to callsign substitution using RELAY and WIDE.
2) Convert most low level digis to RELAY ONLY digis.
3) Disable WIDEn-n in any digi that can see the LA basin
4) Encourage mobiles to use RELAY,WIDE paths
5) Encourage home stations to use WIDE,WIDE.
Think about it...
Bob, WB4APR
----------------------------------------------------------------------
Subject: Re: Travel Report on use of "WIDE" - IGATE access
From: "hasan schiers" <schiers@netins.net>
Date: Wed, 17 Sep 2003 10:06:46 -0500
X-Message-Number: 46
----- Original Message -----
From: "Bob Bruninga" <bruninga@usna.edu>
To: "TAPR APRS Special Interest Group" <aprssig@lists.tapr.org>
Cc: "TAPR APRS Special Interest Group" <aprssig@lists.tapr.org>
Sent: Tuesday, September 16, 2003 2:02 PM
Subject: [aprssig] Re: Travel Report on use of "WIDE" - IGATE access
>THe better fix is to educate and teach users the proper paths.
>
>de WB4APR, Bob
This is PRECISELY the problem. No amount of knee jerk automation is going
to solve the problems without creating new ones. This is called the "law of
unintended consequences".
With a combination of smart digis and user education, this entire thread,
along with the "home port" stuff is rendered moot.
UI-DIGI has pretty darn good control of loops and dupes. UI-View32 acting as
a smart digi has superb control of same. In Iowa we now support (smartly):
WIDENn-n
TRACEn-n
RELAY
WIDE
TRACE
IOWA
IA
and at the borders,
MN
NE
MO
Virtually ALL the users in the area of our digipeater network (the entire
western 1/2 of the state from I-35 to I-29 and into Nebraska) have been
personally "educated" to use the following path (or something close to it)
while mobile:
RELAY, WIDE2-2
No one deliberately uses wides while mobile any longer.
>From home stations:
WIDE2-2 or WIDE3-3
or
TRACE2-2 or TRACE3-3
Some home stations put one dumb WIDE in at the beginning per Bob's
suggestion. Others (like me) run simply TRACE3-3 from home, because we are
doing path analysis. In any case, our network can easily support TRACEn-n
instead of WIDEn-n. Given the density and placement of our digis, and the
user load, this system works great FOR US.
The key is that ANY digi network needs to be MONITORED continuously and
MANAGED. Users need to be spoken with, consulted and suggestions that help
the overall network efficiency need to be IMPLEMENTED, hence the "managed"
portion of the key above. We do continuous traffic counts (UI-TRAFFIC),
PROBE statistics (TNX BOB), and Path Analysis (UI-Path), and the results are
PUBLISHED and shared wiith the users on a continual basis. (TRAFFIC ICONS,
PROBE STATS). Our users KNOW how the channel is being loaded, and who/what
is doing it.
We actually TALK about our network nearly every day M-F. We have a linked
repeater system that covers a large part of the state (including the
footprint of our digi network), so the digi ops, igate ops, and users ALL
talk to each other, FREQUENTLY. (Iowa scenery isn't that compelling, and we
all drive to work)
If you want a network to work, it must be discussed on a regular basis with
those who have the biggest impact on it....typically mobiles.
DESIGN > MONITOR > ANALYZE > FEEDBACK > TWEAK > MONITOR > LOOP to
ANALYZE....one continuous loop. After enough iterations, it becomes:
MONITOR > ANALYZE > FEEDBACK > LOOP to MONITOR
From this point on, (barring any changes to the digi infrastructure), it's
simply a matter of monitoring the network and providing continuous feedback
to the users. When the users see themselves as an important PART of the
system, and having some say in how it is set up and operates, they show a
LOT more respect for it.
One can simply not talk enough to the users, keeping them informed,
soliciting their input, and then ACTING on it. If users deliberately don't
comply with the agreed upon best practices, then more feedback...then more
feedback...and if that doesn't work... well, we have control over the entire
digi system, so it or they can be 'worked out'.
We have the software (UI-View32 is best at this) and the firmware (UI-DIGI
et al), these kinds of things need to be implemented and then the users need
to be kept in the loop. If we do this, given the power ALREADY IN PLACE with
superb client software and digi firmware, all that is needed is to make a
concerted effort with users and this volunteer network will become as good
as it possibly can. (Yet there will always, I know, be something or someone
to complain about.)
The process described above worked here, your mileage may vary ;o)
....hasan, N0AN
----------------------------------------------------------------------
Subject: Digi Range Experiment
From: "Bill Vodall - WA7NWP" <wa7nwp@jnos.org>
Date: Wed, 17 Sep 2003 15:04:39 -0700
X-Message-Number: 47
Here in the Pacific Northwest, one local digi is broadcasting a PHG value
of 6875
Power = 6^2 or 36 watts
HAAT = 10 * 2^8 = 2560 feet
Gain = 10 ^ (7/10) = 5.01
Range = sqrt( 2 * HAAT * sqrt( (power/10) * (gain/2)))
Range = sqrt ( 2 * 2560 * sqrt( (36/10) * (5.01/2) )
= sqrt ( 5120 * sqrt ( 3.6 * 2.5 ) )
= sqrt ( 5120 * 3)
= sqrt ( 15360 )
= 124 miles
That sounds about right for this digi.
Now checking the 50 station range for the same digi thanks to Findu,
it shows 27.7 miles.
A digi with a range of 124 miles is "full" in under 30 miles...
I'd suggest that this is one way to show a digi is "too good"
for the network.
73,
Bill - WA7NWP
PS. Creating a report for all digi's would be a good project for
some mysql programmer.
----------------------------------------------------------------------
Subject: Re: Digi Range Experiment
From: David VanHorn <dvanhorn@cedar.net>
Date: Wed, 17 Sep 2003 17:23:00 -0500
X-Message-Number: 48
>Now checking the 50 station range for the same digi thanks to Findu,
>it shows 27.7 miles.
>
>A digi with a range of 124 miles is "full" in under 30 miles...
interesting.
i've often thought that the findu data set could show what a given digi's
actual coverage is, as opposed to the advertised coverage.
you'd want to restrict that view to mobiles only, probably by selecting
only stations with a relatively high speed, like more than 5-10 mph.
coverage range for fixed stations isn't so interesting, and you'd have to
factor in their phg's as well.
----------------------------------------------------------------------
Subject: Re: RELAY,WIDE,WIDE
From: "Spider" <spider@rivcom.net>
Date: Wed, 17 Sep 2003 16:07:06 -0700
X-Message-Number: 49
From: "Bob Bruninga" <bruninga@usna.edu>
To: "TAPR APRS Special Interest Group" <aprssig@lists.tapr.org>
Cc: "TAPR APRS Special Interest Group" <aprssig@lists.tapr.org>
Sent: Wednesday, September 17, 2003 2:30 PM
Subject: [aprssig] Re: RELAY,WIDE,WIDE
>On Wed, 17 Sep 2003 WA8LMF2@aol.com wrote:
>
>>Southern Cal digis ignore RELAY -- any path starting with it won't go
>>anywhere....
>
>If they would let mobiles use RELAY correctly and turn maybe half of their
>digipeaters into local, lower, shorter range RELAY-ONLY digi's, then that
>would go a long way towards *reducing* overall packets on the system.
Exactly Bob! It works that way here where I am and it works in nearby
communites as well... It DOES NOT reduce packets however, it creates more.
The concept is to use RELAY only if you can not hit a WIDE by yourself or
are only needing to cover the relay's area. The problem....There can be 30
RELAYs that hear you!!!
Same principle of my use of SAR to cover a specific local area without
going wide but there can be dozens of RELAYS!!!!
However the use of a 'special name' makes it better because I do not sound
off all the RELAY digis using SAR or any other special name for local
tactical communications!. You seemed not to understand that a few weeks
ago! If a digi uses the name FRED and I only wanted to cover FRED's area
then I sould use FRED in my path. It is a Local issue and locals would
decide that, regardless of the RELAY, WIDE, TRACE national plan.
Mobiles using RELAY in our area only add more packets to the
channel...period.
There are enough digi's doing WIDE and WIDEn-n that hear these mobiles
WITHOUT the need for RELAY!
IMHO the ONLY time you should use RELAY is if you can not directly reach a
WIDE or WIDEn-n. Then and only then should you use RELAY!
It just add more packets to an already busy channel! Very few cases in the
Southwest USA where you would need to run RELAY.
>Remember not only does RELAY help mobiles,
Bob, I do not know how to tell you this....no it does not help mobiles. And
'mobiles' has absoulutely nothing to do with the equation!
RELAY helps those stations that are not able to directly reach a WIDE or
WIDEn-n due to poor path caused by bad location, very low power or whatever.
If a station...Mobile or otherwise can directly hit WIDES and WIDEn-n's then
why on earth suggest they use RELAY that will only add dozens and dozens of
more packets on the air from low level stations that CAN reach a WIDE or
WIDEn-n.
Suggesting RELAY in the SOUTHWEST USA is just absoulutely NUTS!
I'll give you just one example that happened last week.
A station (mobile) in Yuma was set to WIDE,WIDE2-2 which is considered a
reasonable setting in these parts. For technical reasons between this
station and the local Yuma WIDE digi, he could not get into it. I contacted
two parties in Yuma that would be 'experts' in Yuma to find out why we were
not seeing him a couple hops away when we knew we should. We did confirm he
had a technical problem between his station and the WIDE node.
HOWEVER, in order to make it work, it was suggested he run RELAY,WIDE2-2
because there are two low level RELAY digis that would allow a path to the
WIDEn-n digi!
This is a PERFECT example of how RELAY should work. If the station can hit
a WIDE without the need for a RELAY then using RELAY only adds packets and
is certainly NOT needed!
My Igate is also a RELAY digi...Why? Because if someone in my area can not
hit one of 4 nearby mountaintop WIDES then my station can help him get out.
It would be a really rare case for the need of RELAY in my area.
But if a mobile running 5 watts comes through the area running RELAY in the
path....well, I still digi him but is just plain nuts when he can hit the
WIDEs himself!
I would not ever suggest mobiles in the southwest USA to ever run RELAY.
They just be adding to the mess. And that is not to say that there should
not be RELAY digi's to take care of those that really need RELAY, as in my
example above.
Jim, WA6OFT
----------------------------------------------------------------------
Read previous mail | Read next mail
| |