| |
ZL3AI > APRDIG 01.10.03 11:19l 229 Lines 9677 Bytes #999 (0) @ WW
BID : 2040-ZL3AI
Read: GUEST
Subj: TAPR Digest, Sep 28, 1/2
Path: DB0FHN<DB0RGB<DB0MRW<DB0FOR<DB0SIF<DB0EA<DB0RES<ON0AR<7M3TJZ<IK1ZNW<
ZL2TZE<ZL3VML
Sent: 030930/1329Z @:ZL3VML.#80.NZL.OC #:9371 [Chch-NZ] FBB7.00i $:2040-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
TAPR APRS Special Interest Group Digest for Sunday, September 28, 2003.
1. RE: TH-D7A(G) Odd behaviour
2. PASSALL
3. The NEW WIDEn-N Paradigm
4. Re: APRS Grass growing...
5. Re: APRS Grass growing...
6. Re: APRS Grass growing...
7. Re: APRS Grass growing...
8. APRS PERL FINDU PORT 80
9. Re: APRS PERL FINDU PORT 80
10. Even cheaper GPS receivers
11. Re: Another thought on reducing congestion in busy metro areas...
12. Re: Even cheaper GPS receivers
13. Re: Even cheaper GPS receivers
14. Re: Even cheaper GPS receivers
15. RE: Even cheaper GPS receivers
----------------------------------------------------------------------
Subject: RE: TH-D7A(G) Odd behaviour
From: "WalterH" <walterh@k5wh.net>
Date: Sat, 27 Sep 2003 22:55:10 -0500
X-Message-Number: 1
I saw this very problem on a THD-7G as well, on a friend's radio just
last month. I don't have idea what got it into this mode, but I was able
to back up his memories, did a HARD reset on it, and returned to normal.
Then the restore of the memories worked also.
It was a minor inconvenience to have to do that, but it had a happy
ending just the same.
Walter/K5WH
----------------------------------------------------------------------
Subject: PASSALL
From: "Andrew Rich" <vk4tec@hotmail.com>
Date: Sun, 28 Sep 2003 20:05:48 +1000
X-Message-Number: 2
Seems this digi has passall on
calls: VKE4LTT>EPRS,W4G3-1,WID82-1,qAo,N1HQ:!32#2.37NU0d558.78Wg
-Frien-ship Diipeater
dest : EPRS
digis: W4G3-1,WID82-1,qAo,N1HQ
payld: !32#2.37NU0d558.78Wg -Frien-ship Diipeater
----------------------------------------------------------------------
Subject: The NEW WIDEn-N Paradigm
From: Bob Bruninga <bruninga@usna.edu>
Date: Sun, 28 Sep 2003 10:44:19 -0400 (EDT)
X-Message-Number: 3
Please consider the following ultimate (and immediate) fix to the
long-path FLOODING problems in APRS:
What's Wrong with WIDEn-N Routing and How to FIX it!
---------------------------------------------------------
WIDEn-N FLOODS equally in ALL directions with dozens if not almost 200
copies. We can no longer afford this QRM in our network. If each digi can
hear 3 others, here is the resulting number of COPIES at each HOP:
SETTING 1st 2nd 3rd 4th 5th 6th 7th TOTAL
------- --- --- --- --- --- --- --- -----
WIDE1-1 3 3
WIDE2-2 3 6 9
WIDE3-3 3 6 12 21
WIDE4-4 3 6 12 15 36
WIDE5-5 3 6 12 15 21 57
WIDE6-6 3 6 12 15 21 24 81
WIDE7-7 3 6 12 15 21 24 30 111
That's bad enough. But in many cases digipeaters can easily hear 4 other
digis. Then the numbers become:
SETTING 1st 2nd 3rd 4th 5th 6th 7th TOTAL
------- --- --- --- --- --- --- --- -----
WIDE1-1 4 4
WIDE2-2 4 12 16
WIDE3-3 4 12 20 36
WIDE4-4 4 12 20 28 64
WIDE5-5 4 12 20 28 36 100
WIDE6-6 4 12 20 28 36 44 144
WIDE7-7 4 12 20 28 36 44 52 196
THE SOLUTION (and QUICK FIX):
-----------------------------
Does this make WIDEn-N unusable in today's network? No!
But we must CHANGE how we use it to ensure its usefullness while bounding
its impact. Here are 3 ways to do this:
1) LINKn-N: Arrange linear propagation paths along our travel or
communications corridors. Then the total copies is limited between N
and 2N depending on where you enter the link.
2) LANn-N: Bound areas of common interest of X digipeaters. Then n-N hits
every digi in the area and dies no matter how big is N. The total
copies is bounded by X.
3) NOn-N: This approach simply turns off WIDEn-N digipeating in high
density saturated areas so that distant packets cannot flood the LOCAL
network. Local operation of 2 or 3 hops remains reliable using the
universal RELAY and WIDE and fixed calls.
In ALL cases, all digipeaters will continue to function normally in the
local area by supporting the APRS universal paths of RELAY,WIDE or
WIDE,WIDE or DIGI,WIDE so that no change in local activity anywhere is
affected.
WIDEn-N will continue to work but even BETTER!
-----------------------------------------------
Also in vast areas of few users, WIDEn-N will still be the default though
it too will operate as a "Bounded LANn-N" in that area. It will be bounded
in the wilderness and thus cannot propagate into other Bounded LANn-N
networks. It is also OK, for multiple WIDEn-N "bounded LANn-N" areas to
touch, because in this case, the linear model prevails and again FLOODING
is limited.
XXXX and YYYY LANS:
-------------------
Now, it is difficult in many areas to get a large density of Hams to agree
on what constitues a Bounded LAN. (I recommend geopolitical boundaries
where practical). But different groups may want to use the area
differently with different boundaries. This can still be accomodated with
2 levels of flexibility as follows:
The CALLSIGN-SUBSTITUTION algorithm in most digipeaters supports 4
different generic calls. Two of those are committed to RELAY and WIDE. The
other two are available for LOCAL SUB-GROUP distribution bounds. So if say
the SAR group has a favored area that may even cross into other Bounded
LANn-N areas, they can simply add SAR to any digipeater they want included
in their SAR area. Similarly, the SKYWARN folks may want to add SKY to all
digipeaters that they consider to be needed in their coverage area.
And ALL of this can be implemented in all existing WIDEn-N digis by a
simple chnage to the UIFLOOD ZZZZ 28,NOID command.
OVERLAPING BOUNDED LAN'S
--------------------------
Nothing in this proposal prevents the overlaping of multiple Bounded
LANn-N's in the same geographical area. That is, a set of digis can be
dedicated to a geopolitical boundary of AAAn-N while other digis in
adjacnet overlaping areas can use BBBn-Y. In either case, packets are
bounded into their area of interest only and do not generally FLOOD
everyone else. The practical limitation here is that existing TNC's can
only support one LANn-N callsign at time. Though UIDIGI and DIGI_NED can
overcome this limiatation quickly.
Please consider these changes as to how we use the UIFLOOD parameter so
that we can get APRS back to where it works RELIABLY locally and then we
can begin the USER EDUCATION process with a single set of rules and
recommendations.
de WB4APR, Bob
----------------------------------------------------------------------
Subject: Re: APRS Grass growing...
From: Henk de Groot <henk.de.groot@hetnet.nl>
Date: Sun, 28 Sep 2003 15:38:53 +0200
X-Message-Number: 4
Hello Bob,
At 09:58 27-9-03 -0400, Bob Bruninga wrote:
>1) If users set a FIXED rate of say 30 minutes, then the network has up to
>30 minute LATENCY in data. If the home station changes his POSIT text to
>say add his phone number or to change his status, then the EOC might not
>get that info for 30 minutes , or an HOUR if there was a collision...
>That is NOT the design of APRS!!!!
That makes sense! I think clients need to be adjusted and change to this
behaviour. A pitty the Kenwoods cannot be changed... Its a frustrating that
this, like many other finer details, is not described in the APRS spec. To
my knowledge it is also not in the errata sheet (yet), it should be added.
We can have a double axe here: clients that decay rates if nothing changed
and digis that prefer changed data over unchanged data. That way we have a
stopgap for all the existing clients (other than APRSdos and PMmap).
>transmitting NEW information once every 30 minutes, I dont blame USERS for
>moving their update rate up to something more TIMELY. That is the only
>way that those client progrms allow the user to get his NEW data out.
>BUT then the USER forgets to change it back to 30 minutes after his new
>data gets old. So it is not the USER'S fault here, it is the CLIENT
>software that FAILS to implement the FUNDAMENTAL APRS concept of Fast
>updates of NEW data and decaying to 30 minutes of OLD data.
If it goes wrong a DIGI with a large dupe check time of 29 minutes after
the first hop will at least contain the effects of this obvious human error
almost completely in the local area, networks further away will still see a
30 minute cycle time since the other redundant packets will be stopped
before causing excessive load. If all clients are fixed the DIGI will not
get in the way.
>I have been complaining of this FUNDAMENTAL flaw of some client software
>for now 8 years and (to my knowledge) it is still not fixed. It is
>KILLING APRS as a reliable real-time communications system.
If this is so fundamental then something seriously went wrong when the APRS
Spec was written. How could such a fundamental point be missed? I don't
want an analysis, I like to know: how do we fix it and what else is missing?
>Fortunately, I think some newer programs have implemented the FUNDAMENTAL
>decaying algorithm. I'd like to see a list of how the various client
DIGI_NED is not an end-user client and its beacon is used only to announce
its presence so a fixed time is okay for that type of application. The
decay algorithm was described for messaging and as a result of that it is
used in DIGI_NED for messaging (it doubles the time for the next
transmission after each try to deliver the message, as described in the spec).
Kind regards,
Henk.
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
