| |
ZL3AI > APRDIG 02.10.03 10:09l 272 Lines 14127 Bytes #999 (0) @ WW
BID : 2047-ZL3AI
Read: GUEST
Subj: TAPR Digest, Sep 29, 3/12
Path: DB0FHN<DB0RGB<DB0MRW<DB0ERF<DB0FBB<DB0IUZ<DB0GOS<DB0EEO<DB0RES<ON0AR<
LU6DTS<ZL2TZE<VK3KAY<ZL2BAU<ZL3VML
Sent: 031001/1341Z @:ZL3VML.#80.NZL.OC #:9447 [Chch-NZ] FBB7.00i $:2047-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: Take Control of your DIGI part1
From: "Tim Cunningham" <tim_cunningham@mindspring.com>
Date: Mon, 29 Sep 2003 13:58:41 -0500
X-Message-Number: 16
>Please, Everyone, save this proposal and come back and read it when you
>have time to digest it. Keep an open mind.
OK I am taking the bait. Please take a very deep breath and read the
reality of our local network which may be typical of other APRS
configurations around the country, except for the number of users.
>* PROPOSAL: If your local APRS LAN is overloaded, *
>* turn off WIDEn-N on that digi. *
Turning off WIDEn-N will not solve the over loading problem on the local
LAN. The problem is not WIDEn-N. The problem is a fundamental philosophical
APRS issue, digipeater owner understanding of how the network should work,
and an end user education on how and why the PATH setting causes problems.
Add to this the frequency of a user beacon and how it affects some distant
location outside their local area. Add the growing popularity of APRS and
the addition of weather stations and the load has naturally increased.
Again, WIDEn-N itself has nothing to do with the end result of the load or
the QRM.
The initial introduction of WIDEn-N was conveyed as a way to reduce the
packet payload by 7 bytes per designator used in the packet path. Thus, if
I use WIDE3-3 instead of WIDE,WIDE,WIDE one could save 14 bytes of extra
bandwidth. Whether one uses WIDE3-3 or WIDE,WIDE,WIDE the end result is the
same in a perfectly functioning network. The only affect that the efficient
WIDE3-3 would have is that it could possible make some distant location
because the payload is smaller than the 14 byte longer packet. In either
case, both payloads would have made the route to the distant station, but
maybe the shorter more efficient WIDE3-3 may have been decoded since the
probability that it did not get clobbered by a local station to that
distant digipeater is lower. The transmission is still heard regardless if
it was decoded or not. Called this undecoded QRM versus decoded QRM. The
undecoded QRM is the QRM that is the most troublesome, but you cannot
record this in looking at the packets. Thus, you would have a distorted
view of the real problem as it is masked in reality.
>There is nothing wrong with WIDEn-N, unless it is bringing in distant QRM
>that is preventing your LAN from serving its primary local purpose. This
>is a radical concept, but on close inspection, it has far, far more
>positives than negatives.
WIDEn-N performs the same path instructions as the verbose WIDE method with
the exception that WIDE is limited to a complete path of 8 entries,
whereas, one could go wild with a WIDEn-N and far exceed more than 8
digipeaters.
The bottom line is WIDE7-7 performs no differently where the packet goes
unless a digipeater does not support WIDEn-N. In that case, the nature of
our beasthood would compel us to change our path to
WIDE,WIDE,WIDE,WIDE,WIDE,WIDE,WIDE which in effect sends the payload out to
all the same directions as a WIDE7-7 and consuming more bandwidth. However,
the WIDE7-7 is now 42 bytes more efficient and has a higher probability of
propagating through the network as a smaller packet payload. If anything,
the WIDE7-7 path makes it to the distant DX digipeater because it has a
smaller payload than the 7 WIDE path. The interference it creates is less
for a WIDEn-N since the bandwidth consumption is smaller increasing its
probability to reach the intended distant location.
>I am impressed with many areas where the local sysops are trying their
>best to build a network to serve their local needs. But in most cases the
>problems are external and beyond their control. The big problem is very
>long paths from out of area stations over which they have no control.
>Sometimes the result is that they make local hacks to the fundamentals of
>APRS which may do more damage than good to APRS overall.
This has everything to do with user education. It is no different than
educating folks digipeating through the ISS. It is a constant battle and
one that never ends. If the problem is on the user end and we know the
problem is a continuous problem, then the only way around this is to create
a system that takes care of the problem and remove the configurability that
causes the problem from the user.
On the other hand, we are suppose to be communicators!
Are we doing a good job of communicating or are we failing at being
communicators? This is an issue to think about... If we are failing in
being communicators, then what good are we? This is a serious issue. We can
side step it and whine until the cows come home, but at the end of the day
we still have a problem. Solving the problem takes action and cooperation
by everyone on the network. Everybody has a responsibility to uphold good
operating practices. That is our code of ethics as Amateur Radio Operators.
If the problem is related to uncooperative and hard headed operators, there
are ways to make them conform or risk forfeiting their license due to
intentional interference once they are made aware of the impact of the
problem and decide to do nothing.
----------------------------------------------------------------------
Subject: Re: Take Control of your DIGI part 3
From: "Tim Cunningham" <tim_cunningham@mindspring.com>
Date: Mon, 29 Sep 2003 13:59:11 -0500
X-Message-Number: 17
Here are some examples of no callsign substitution along with NOID
WIDEn-N digis:
K4GIG-7>S4TT9V,RELAY,WIDE2-2/1:'rDFog#k/]"61}
K4GIG-7>S4TT9V,RELAY*,WIDE2-2/1:'rDFog#k/]"61}
K4GIG-7>S4TT9V,RELAY*,WIDE2-2/1:'rDFog#k/]"61}
K4GIG-7>S4TT9V,RELAY*,WIDE2-1/1:'rDFog#k/]"61}
K4GIG-7>S4TT9V,RELAY*,WIDE2-1/1:'rDFog#k/]"61}
NN4S>APP194,RELAY,WIDE3-3/1:>311619zVisor Prism/Magellan GPS
Companion/KPC-3/DR-13050w into 1/4 wave whip[AI4CW]
NN4S>APP194,RELAY*,WIDE3-3/1:>311619zVisor Prism/Magellan GPS
Companion/KPC-3/DR-13050w into 1/4 wave whip[AI4CW]
NN4S>APP194,RELAY*,WIDE3-2/1:>311619zVisor Prism/Magellan GPS
Companion/KPC-3/DR-13050w into 1/4 wave whip[AI4CW]
Wow! Compare the above examples with the initial example of RELAY,WIDE,WIDE
with callsign substitution and you see a major reduction in traffic by the
same packet taking the same path .
Below are more examples of callsign substitution issues causing too much
data duplication on the local network:
K4DOH>CQ,RELAY,WIDE2-2/1:>TinyTrakII v1.00
K4DOH>CQ,RELAY*,WIDE2-2/1:>TinyTrakII v1.00
K4DOH>CQ,WC4ADG*,WIDE2-2/1:>TinyTrakII v1.00
K4DOH>CQ,WC4ADG*,WIDE2-1/1:>TinyTrakII v1.00
K4DOH>CQ,WC4ADG*,WIDE2/1:>TinyTrakII v1.00
K4DOH>CQ,RELAY,WIDE2-2/1:>TinyTrakII v1.00
K4DOH>CQ,RELAY*,WIDE2-2/1:>TinyTrakII v1.00
K4DOH>CQ,W4GPS-7*,WIDE2-2/1:>TinyTrakII v1.00
K4DOH>CQ,RELAY*,WIDE2-1/1:>TinyTrakII v1.00
K4DOH>CQ,WC4ADG*,WIDE2-2/1:>TinyTrakII v1.00
N4CCO-2>S4TS3S,RELAY,WIDE2-2/1:'r>Kl >/]"6'}
N4CCO-2>S4TS3S,RELAY*,WIDE2-2/1:'r>Kl >/]"6'}
N4CCO-2>S4TS3S,WC4ADG*,WIDE2-2/1:'r>Kl >/]"6'}
N4CCO-2>S4TS3S,RELAY*,WIDE2-1/1:'r>Kl >/]"6'}
N4CCO-2>S4TS3S,WC4ADG*,WIDE2-1/1:'r>Kl >/]"6'}
N4CCO-2>S4TS3S,RELAY*,WIDE2-1/1:'r>Kl >/]"6'}
N4CCO-2>S4TS3S,WC4ADG*,WIDE2-1/1:'r>Kl >/]"6'}
N4CCO-2>S4TS3S,RELAY*,WIDE2/1:'r>Kl >/]"6'}
N4CCO-2>S4TS3S,WC4ADG*,WIDE2/1:'r>Kl >/]"6'}
N4CCO-2>S4TS3S,RELAY*,WIDE2/1:'r>Kl >/]"6'}
N4CCO-2>S4TS3S,WC4ADG*,WIDE2/1:'r>Kl >/]"6'}
My point is that WIDEn-N is not the problem. We have other bigger problems
wasting bandwidth on the APRS network.
1. Do we need callsign substitution?
I think it causes more duplication than anything because the present day
digis do not handle duplicate packets when the path has been altered by
another digipeater. The examples shown above should solidify any doubts
on this topic.
2. Some digipeater owners still do not understand how to configure their
WIDEn-N as a NOID digipeater. This causes duplication of packets because
the path is altered.
3. WIDEn-N works perfectly well when no callsign substitution and WIDEn-N
digis are configured as NOID.
>UNIVERSAL: Advantage #2 is that it can be applied to ANY existing
>digipeater. It doesnt require special ROMS or new hardware AND Draconian
>filtering. Disabling WIDEn-N in selected digis is something that can be
>done now, today, on ANY digi and it can even be done remotely! AND it
>puts the solution to the LOCAL problem Local.
I must be missing something. 7 WIDE's in my path is no different than a
WIDE7-7 as far as the area that is going to be covered. The probability of
WIDE7-7 getting the network with a smaller payload (42 bytes less) seems to
be a justification that WIDEn should be utilized to reduce the size of the
payload and increase reliability. I do not feel we should take a step back
from WIDEn-N at this point simply because we have a user issue.
In every case I have approached a local station about the misuse of the
WIDEn-N, I found it was they did not understand how it worked. In one case
a local operator was using RELAY,WIDE3-3, TRACE3-3. It was obvious to me
that something was not understood. His reason was that he wanted to make
sure he had all bases covered in his path so it would work anyplace he
traveled. He did not understand that the path worked in a serial
progression. He thought the RELAY's, WIDE's, and TRACE's would all pick him
up since they were all in the path with no knowledge of how it worked. He
quickly fixed the problem when I explained how the digipeat function
worked, how far the packet would travel, and how many stations and
locations would be affected by his path. This is actually a case of good
Elmering for those in need.
I would really prefer to use RELAY,WIDE2-2 in the mobile versus
RELAY,WIDE,WIDE and save the 7 bytes. The use of WIDEn-N in this case is
not going to make any difference how far it travels. It is simply going to
increase the probability of the shorter packet payload to make the trip.
>NO MORE FLOODING: There is a reason we named the WIDEn-N parameter in the
>digis as UIFLOOD. The intent of a WIDEn-N packet is to FLOOD the network.
>We can no longer afford that kind or RF polution.
I can only agree that the function works as intended, but it is not the
problem. If we all Elmer our local users to understand how the path in APRS
works, we might see some change. This is simply exercising our work as
communicators. We have to learn to communicate to bring any value to HAM
radio.
What I see happening is if we remove WIDEn-N from the network, the person
who uses the WIDE6-6 will learn that WIDE,WIDE,WIDE, WIDE,WIDE,WIDE will
accomplish the same job. There is power in numbers of people talking to the
individual if one person fails. If it continues, it could be treated as
malicious interference, or you always have the option to Budlist the
callsign if all else fails. The question is are we really adapting to our
known environment or are we trying to push something that is not the root
cause of the problem. We should focus on fixing the fundamental root
problems based on the reality we know in the digipeater world to arrive at
what we can do right now.
>SIMPLIFIES USER EDUCATION: We all know "user education" is the solution,
>but our current situation is THE PROBLEM that makes user education
>impossible! With every area of the country making thier own local HACKs
>to APRS digis, there is no single recommendation that works everywhere.
>And it is not a "soft" failure. It is a HARD failure. If I have a
>tracker going via RELAY,WIDE and drive into an area that doesnt support
>RELAY at all digis, then I am totally cut off.
There is a problem in itself which is a non-conforming standard of WIDE's
responding to RELAY. Is the network broken in that case? I guess that
really depends on what is being accomplished in that area. It does nothing
to help the out of town traveler getting into the network. In that case.
the network has an incompatibility.
>THREE TIER NETWORK: What this does in effect is give SYSOPS more
>flexibiilty in the design of their network with now three compatible
>options for digis:
>
> WIDES: The local area network. The basis of APRS.
> RELAYS: Fill in digis for blind spots
> WIDEn-N: Long haul in sparse areas
If you do this now, you have to start re-education process all over. I
think this is going to confuse the APRS population for some time to come
and could potentially distract some potential players with complication.
The use of WIDE and WIDEn simply stated is very trivial or I do not
understand the problem at all.
>HUB-and-SPOKE: I have no problem with WIDEn-N packets. In fact, this
>concept will actually IMPROVE WIDEn-N:
>1) it will remove the stigma that all long path N-N packets are bad.
>2) it will limit the high density city packets (which now will not
>use WIDEn-N) from flooding all surrounding area long-haul digis.
>3) WIDEn-N digis will carry the WIDEn-N traffic to the EDGE of
>the high density areas where it can find an IGate, but no further.
>4) Removing WIDEn-N digipeating in the cental city, CUTS the long chains
>that FLOOD everywhere.
>5) this naturally restricts WIDEn-N into its most powerful advantage
>of long linear propogation instead of FLOODING QRM...
From what I have read in this post, WIDEn-N is bad. That seems to be the
underlying message because users abuse it. What I see happening is the
WIDE6-6 user moving to WIDE,WIDE,WIDE,WIDE, WIDE,WIDE. Then, what have you
accomplished? Besides taking 35 bytes of bandwidth with the extra WIDE's I
am not sure I see any difference in that logic except wasting bandwidth and
increasing the probability of a larger packet payload colliding with
another packet and getting lost. Of course, you might still have WIDEn-N,
but that may not work everywhere under the new plan. This is too confusing
for Joe HAM. If you want to simplify it then eliminate WIDEn-N completely.
My point is this is becoming more difficult even for an experience person
in APRS. This is too much confusion in comparison to simply educating users
how to make APRS work for them.
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
