| |
ZL3AI > APRDIG 30.09.03 10:52l 194 Lines 9292 Bytes #999 (0) @ WW
BID : 2025-ZL3AI
Read: GUEST
Subj: TAPR Digest, Sep 27, 1/7
Path: DB0FHN<DB0RGB<OK0PPL<DB0RES<DB0EEO<DB0GOS<ON0AR<WB0TAX<7M3TJZ<F6CDD<
EA5RQ<VK4TUB<ZL2BAU<ZL3VML
Sent: 030929/1334Z @:ZL3VML.#80.NZL.OC #:9303 [Chch-NZ] FBB7.00i $:2025-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
TAPR APRS Special Interest Group Digest for Saturday, September 27, 2003.
1. Clueless Users? How's that <g>...
2. Re: Clueless Users? How's that <g>...
3. Another thought on reducing congestion in busy metro areas...
4. Re: Another thought on reducing congestion in busy metro areas...
5. Re: Another thought on reducing congestion in busy metro areas...
6. APRS Igate traffic graph
7. Re: Part 2/2 -Re: Take Control - oh let's just go backwards
8. Re: APRS Grass growing...
9. Re: Clueless Users? How's that <g>...
10. Re: I guess we're going to agree to disagree Bob. Part 3 of hopefully 3
11. Re: APRS Grass growing...
12. Re: APRS Grass growing...
13. Re: I guess we're going to agree to disagree Bob. Part 3 of hopefully 3
14. Re: Another thought on reducing congestion in busy metro areas...
15. LINKn-N linear routing
16. Re: APRS Grass growing...
17. Re: APRS Grass growing...
18. More Complexity-Yes, was Re: APRS Grass growing...
19. Re: Part 2/2 -Re: Take Control - oh let's just go backwards
20. Re: Part 2/2 -Re: Take Control - oh let's just go backwards
21. RE: Clueless Users? How's that <g>...
22. Re: APRS Grass growing...
23. Re: Another thought on reducing congestion in busy metro areas...
24. Re: APRS Grass growing...
25. National WIDE5-5 day
26. RE: More Complexity-Yes, was Re: APRS Grass growing...
27. Re: More Complexity-Yes, was Re: APRS Grass growing...
28. Funny! Paths!
29. RE: Emergency Power lights.
30. RE: Emergency Power lights.
31. RE: Emergency Power lights.
32. LANn-N routing.
33. RE: LANn-N routing.
34. Re: LANn-N routing.
35. TH-D7A(G) Odd behaviour
36. Re: APRS Grass growing...
<LYR30523-151730-2003.09.27-09.59.07--kb2scs#optonline.net@lists.tapr.org>
37. RE: Emergency Power lights.
38. RE: LANn-N routing.
39. Re: APRS Grass growing...
40. Re: APRS Grass growing...
41. RE: TH-D7A(G) Odd behaviour
----------------------------------------------------------------------
Subject: Clueless Users? How's that <g>...
From: "Dick Stanich" <dick@kb7zva.com>
Date: Sat, 27 Sep 2003 1:7:8
X-Message-Number: 1
>>Violates the KISS principle and gains nothing. Already a home station is
>>only transmitting once every 30 minutes. Why get the digi involved in it?
>
>I think having the digis treat non-changing posits as dupes over an extended
>period would be a significant congestion-reducing measure. I might set the
>the dupe period a bit less -- perhaps 10-15 mins or so.
Interesting. I thought most digis in L.A. were using KPC-3's. If so, the
maximum hold time for a packet is 4.25 minutes (0-255 seconds) and can
retain only 64 checksums. Once the checksum buffer fills, the oldest packet
would be dumped. You can rule out dupe checking once the buffer fills vs.
timing.
Several problems with this. If that mobile is being heard by more than one
digi, each packet is different, so you would have several checksums with
the same exact payload, however, the headers would contain different
information, enough to change effective dupe checking.
In L.A., I can't think of too many digis that can handle dupe checking
effectively for more than 30 seconds, not minutes. Besides, if my math is
correct, 64 checksums in a high density area would be ineffective. Those
tnc's aren't capable of doing what you have suggested.
A good thought, but it won't happen, unless all digi owners upgrade to
smart digis. The odds of that happening?
It's likely that not much is going to change until digi owners sit down and
discuss their outdated local configuration. Right now the traffic load is
great, because users appear to be trying longer paths, increased power,
more frequent intervals and screwed up packet timing. It's not unique to
just L.A. if you read this list.
Bob said, Why get the digis involved? Easy answer... because it may be
easier to control the local network at that level.
The Real World <g>...
The hub to all APRS activity is the internet. It currently is a very solid
and the best backbone for APRS and Igates around the world. Thanks to some
major improvements done at the Core and Tier 2 servers.
Should we start thinking about taking the load off high density areas with
the use of different frequencies? The key is to maintain 144.390 as the
national channel for mobile travelers. But, there could be a different
channel on the local scene. It doesn't matter to the APRS-IS how the data
got there. Aren't pilots told to switch to different control frequencies.
In some areas <g>, we use different frequencies on APRS for tactical
operations, using the internet hub as the backbone. Also, we have
digipeaters with budlists and different to_be_digipeated calls, other than
RELAY,WIDE,TRACE for special events and tactical ops. I think some of these
options could be applied to high density networks with ease. I'd leave
144.390 in place and invite those willing to comply, to a different
channel. This time, set a few rules and share information on what is to be
expected. A series of low level digis acting also as Igates would work,
along with low level relay stations dotted here and there.
I tested this in our local area with my Igate on another frequency. It
would be so easy to bring one digipeater into play on the same channel. I'd
like to expand on this idea more, if anyone is interested. But, I think you
can see where this might be headed.
Dick, KB7ZVA
APRSWest
----------------------------------------------------------------------
Subject: Re: Clueless Users? How's that <g>...
From: WA8LMF2@aol.com
Date: Sat, 27 Sep 2003 05:18:02 EDT
X-Message-Number: 2
In a message dated 9/26/2003 11:12:13 PM Pacific Daylight Time,
dick@kb7zva.com writes:
>Interesting. I thought most digis in L.A. were using KPC-3's. If so, the
>maximum hold time for a packet is 4.25 minutes (0-255 seconds) and can
>retain only 64 checksums.
A lot (actually I think most) of the high-elevation wide-area digipeaters
here are running UI-DIGI on TNC-2s
>Should we start thinking about taking the load off high density areas with
>the use of different frequencies? The key is to maintain 144.390 as the
>national channel for mobile travelers.
Except that absolutely every freq in the two-meter and 450 bands is already
occupied here in SoCal. Trying to claim another freq for APRS around here
would start a major uprising. The real problem is the "50,000-watt
clear-channel" WIDEn-Ns on 5000' mountain tops overlooking the entire
densely-populated metro area. A mobile anywhere in the greater L.A. area
will simultaneously hit 3,4 or 5 of these monster wides on mountain tops.
One on Tejon Peak (astride the mountain pass at 7 or 8 thousand feet that
separates Los Angeles from California's central valley) floods WIDEn-Ns
clear to Bakersfield, Modesto, and the hills around Sacramento and Stockton
in one hop. [ As well as into your neck of the woods in AZ. ]
This was great 5 years ago when there were one-tenth as many users as today,
and before broadband always-on Internet connectivity became as ubiquitous as
it is now.
Now the internet needs to substitute for the on-frequency WIDEn-N hops. If
these "super-WIDEs" were replaced with a lot more lower-level "normal"
WIDEs (on 10-story buildings or "mere" 500 or 1000-foot hills) with "mere"
5 or 10 mile coverage radius, and low-level IGATEs, the vast majority of
users could be seen on FINDU in just one WIDE hop. Or be seen county-wide
on RF with WIDE, WIDE. The number of simultanous transmissions the single
144.39 channel could support would go up by a factor of 5 or 10. Indeed if
you start siting wides in office buildings and hilltop homes instead of on
remote mountain tops, they would actually be in places with Internet access
so that IGATES could be co-located with DIGIs (instead of having to depend
on multiple on-air hops to connect DIGIs to IGATEs). An awful lot of of
the everyday-commuter local SoCal user load would be able to get into FINDU
with no path at all (or a national travelers standard RELAY,WIDE).
With the current regime of mountaintop WIDEn-N only (Socal digis don't
respond to ordinary plain WIDE or RELAY at all) I have taken to setting
my APRSplus mobile to WIDE1-1 while running around the greater L.A. area
with no noticible reduction in the number of packets that reach findu. Even
with just WIDE1-1, I sometimes hear 2 or 3 of the two-tone "Kenbeeps"
everytime the radio beacons, indicating I have simultanously hit 2 or 3 of
these monster WIDEn-Ns. The only effect I have noticed is that the success
in messaging another mobile is sharply reduced.
With a lot of lower-level combo WIDE/IGATEs, one should be able to pass
through the Internet "wormhole" from one small WIDE cell to another WIDE
cell elsewhere in the basin, for messaging , in a single RF hop. Without
flooding the entire southern half of California with duplicate wideN-n
packets.
Stephen H. Smith wa8lmf (at) aol.com
Home Page: http://wa8lmf.com
Ham Radio/Mobile SSTV page: http://members.aol.com/wa8lmf/ham
APRS Stuff
http://members.aol.com/wa8lmf/aprs
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
