| |
ZL3AI > APRDIG 09.10.03 16:12l 233 Lines 9169 Bytes #999 (0) @ WW
BID : 2107-ZL3AI
Read: GUEST
Subj: TAPR Digest, Oct 05, 1/3
Path: DB0FHN<DB0RGB<DB0IGL<DB0FSG<DB0PV<OE2XOM<OE5XBL<OE3XSR<OK0PBX<OK0PAD<
OK0PPL<DB0RES<ON0AR<ZL2BAU<ZL3VML
Sent: 031007/1238Z @:ZL3VML.#80.NZL.OC #:9932 [Chch-NZ] FBB7.00i $:2107-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
TAPR APRS Special Interest Group Digest for Sunday, October 05, 2003.
1. Re: W1KFR-9 Trip
2. WIDEn-N can still work almost everywhere
3. DigiTraveler to PalmIIIxe
4. APRS - related PERL programming
5. Re: DigiTraveler to PalmIIIxe
6. DigiTraveler w/ MFJ1270C?
7. Re: DigiTraveler to PalmIIIxe
8. Re: The APRSteward SPAM filter [was: New Mexico LANn-N?]
9. Re: DigiTraveler w/ MFJ1270C?
10. RE: XMap with Digitravller WAS: Re: DigiTraveler to PalmIIIxe
11. is wide5-7 a valid path?
12. Re: is wide5-7 a valid path?
13. Re: is wide5-7 a valid path?
14. Issue with Palm...
15. Re: is wide7-7 a valid path?
16. Is something screwed up with the list serve again ?
17. Re: is wide5-7 a valid path?
18. RE: XMap with Digitravller WAS: Re: DigiTraveler to PalmIIIxe
19. Re: Is something screwed up with the list serve again ?
20. Re: aprssig digest: October 04, 2003
21. Re: aprssig digest: October 04, 2003
22. Re: How do you configure XASTIR IGATE ?
23. Re: aprssig DCD for tracker
24. AIRport report.
----------------------------------------------------------------------
Subject: Re: W1KFR-9 Trip
From: Bob Bruninga <bruninga@usna.edu>
Date: Sun, 5 Oct 2003 00:18:12 -0400 (EDT)
X-Message-Number: 1
On Sat, 4 Oct 2003, John Glenn wrote:
>Also never did see anything from Bob in the 4 days I was in the
>DC-Dumfries, VA area. That did surprise me.
All my antennas are down due to an addition I am supposed to be finishing.
Had to remove ALL hardlines going up the 80' tree. Now its on the
round-to-it list
BOb
de WB4APR@amsat.org, Bob
PCsat WEB page http://www.ew.usna.edu/~bruninga/pcsat.html
ISS-APRS FAQ: http://www.ew.usna.edu/~bruninga/iss-faq.html
CUBESAT Designs http://www.ew.usna.edu/~bruninga/cubesat.html
APRS LIVE pages http://www.ew.usna.edu/~bruninga/aprs.html
APRS SATELLITES http://www.ew.usna.edu/~bruninga/astars.html
MIM/Mic-E/Mic-Lite http://ssdl.stanford.edu/mims/
----------------------------------------------------------------------
Subject: WIDEn-N can still work almost everywhere
From: Bob Bruninga <bruninga@usna.edu>
Date: Sun, 5 Oct 2003 00:25:05 -0400 (EDT)
X-Message-Number: 2
More Ways to look at your network...
Population density and also HAM needs for routine operations and for
special events/emergencies involve three general topologies. One is general
use everywhere-anytime, another is areas-of-interest, and the third is
linear links to other areas. In most ARES/RACES/REACT/SAR/ SKYWARN
organizations and on most maps these topologies are easy to see.
Through 11 years of random growth, APRS in the USA is way beyond saturation
in most areas and this is caused by the combinatinon of the old paradigm of
intentional FLOODing in all directions and vulnerability to both USER and
local SYSOP settings, (right or wrong).
The NEW APRS digipeater paradigm is simple:
1) Vast area FLOODING can no longer be the basis for our networks
2) Networks should be designed to bound USER mistakes
3) We can return APRS to something that works locally everywhere
with standard settings.
4) With the greatly simplified new paradigm, continue education.
Our installed base of APRS digipeaters have tremendous flexibilty to meet
this new paradigm with a variety of "routing" mechanisms that already
exist:
1) MYCALL and MYALIAS <Respond by specific call>
2) CALLSIGN-SUBSTITUTION <4 different CALLS, NETS or ROUTES>
3) TWO n-N Mechanisms. <One FLOODs, and leaves a trace>
<the other FLOODS and doesnot.>
With this kind of flexibility, we have all kinds of un-tapped potential to
solve most of the current problems with our network. Here are the USER
recommendations under the new Paradigm for the general purpose objective of
something that will work everywhere:
GENERAL MOBILE: RELAY,WIDE
GENERAL PORTABLE: WIDE,WIDE
WILDERNESS OR NATIONAL MOBILE: WIDE,WIDEn-N
Conversly, however, almost all amateur radio service organizations have
well defined needs and areas of interest. For those groups, then, here are
the USER recommendations for all the ARES/RACES/SAR SKYWARN/REACT
applications in specific areas:
WIDEn-N - FLOODS outward to the area FIREWALLS and all
out-of-area traffic does not FLOOD into the area
LANn-N - FLOODS only the area of the LAN
LINKn-N - Goes LONG distance along a linear path
XXXX,XXXX... - Goes only VIA Specialty XXXX digis
YYYY,YYYY... - Goes only VIA Specialty YYYY digis
HERE is how SYSOPS should design their networks to facilitate operations in
their areas and to BOUND user induced errors. Remember, it is impossible
for APRS to support more than 50 to 100 stations in any one area. No
traffic should flood beyond that station density.
WIDEn-N: All digis are encouraged to continue to support WIDEn-N,
but everywhere, WIDEn-N must have TWO things:
1) An IGate in the WIDEn-N area
2) Firewall BOUNDS to limit QRM from coming in or going out.
In most large WIDEn-N areas, then SYSOPS should implement WIDEn-N with the
UIFLOOD 28,NOID parameter in the digipeater TNC (as is done now).
LANn-N: For specific NAMED LAN's in specific areas, LANn-N operates
identically to WIDEn-N except that it is SELF bounded by its NAME and does
not need FIREWALL digis. LANn-N can usually be implemented using the
UITRACE parameter without excessive overhead because LANn-N on average can
typically cover as many as 21 digis in 3 hops or less. This means on
average, that most packets are received with two or less digis displayed in
the path.
LINKn-N: Long hop links between areas are inherently self limiting and are
the most efficient n-N mechanism available. Since the path of the long
chain is known, no tracing is needed so this is usually implemented with
the UIFLOOD parameter. But since each digi can support TWO n-N mechanisms,
these LINKn-N digis can also support some WIDEn-N and LANn-N cross traffic.
But extreme care must be taken if WIDEn-N is also supported so that no more
than only every-other digi has WIDEn-N enabled. This way, for example if
the LINKn-N is going East and West, then still some WIDEn-N traffic can go
north and south through the occassional LINKn-N WIDEn-N digis (as long as
they cannot hear each other). Also local smaller LANn-N areas can be
supported along the chain.
I think too many people totally missunderstand the new paradigm and think
that it will reduce the effectiveness of WIDEn-N. When in fact, it will
INCREASE its UTILITY, and its RELIABILITY, and decrease its QRM.
de WB4APR
----------------------------------------------------------------------
Subject: DigiTraveler to PalmIIIxe
From: Robbie <mwrobertson@comcast.net>
Date: Sun, 05 Oct 2003 01:47:30 -0500
X-Message-Number: 3
Hi all,
Well, I thought I was in good shape. Using pins 2, 3 and 5 on the DB-9 does
not seem to get it done.. I am beginning to believe there needs to be
CTS-RTS jumpered or something else..
The GPS works into the Kenwoods.. Works into normal mapping programs using
the RS-232. The PalmIIIxe turns on the GPS, but after about 2 minutes or
less, (outside clear view), it complains about NO GPS... All three of the
cables that I cut the PDA end off, has one form of jumper or another, but
still only the 3 wires going into the RJ connector for the GPS..
Reversing pins 2 and 3 will not allow the receiver to "turn on".
Open for suggestions, or being pointed to sources for finishing this cool
little setup for aprs....
Thanks in advance,
Robbie, wa9inf
----------------------------------------------------------------------
Subject: APRS - related PERL programming
From: "Andrew Rich" <vk4tec@hotmail.com>
Date: Sun, 05 Oct 2003 20:38:23 +1000
X-Message-Number: 4
Added a whole lot of code samples.
Hope this help those learning
http://www.tech-software.net/index.php
Andrew VK4TEC
----------------------------------------------------------------------
Subject: Re: DigiTraveler to PalmIIIxe
From: "Mike Yetsko" <myetsko@insydesw.com>
Date: Sun, 5 Oct 2003 06:43:29 -0400
X-Message-Number: 5
>The GPS works into the Kenwoods.. Works into normal mapping programs
>using the RS-232. The PalmIIIxe turns on the GPS, but after about 2
>minutes or less, (outside clear view), it complains about NO GPS... All
>three of the cables that I cut the PDA end off, has one form of jumper
>or another, but still only the 3 wires going into the RJ connector for
>the GPS..
>
I had this on my Palm IIIc.
The software on the Palm does NOT default to the Digitraveler.
Start the XMapHH software. Bring down the 'pull down' menus.
Go to GPS change the 'settings' to the DigiTraveler.
Mike
----------------------------------------------------------------------
Subject: DigiTraveler w/ MFJ1270C?
From: "Matthew Stennett" <wa4tkg@iwon.com>
Date: Sun, 5 Oct 2003 11:06:29 -0400 (EDT)
X-Message-Number: 6
Is it possible to plug the DigiTraveler into a MFJ-1270C to make a
tracker?, can't I simply wire it direct into the tnc and have a mobile
tracker ?
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
