| |
ZL3AI > APRDIG 11.02.04 12:15l 271 Lines 9299 Bytes #999 (0) @ WW
BID : 2817-ZL3AI
Read: GUEST
Subj: TAPR Digest, Feb 09, 1/5
Path: DB0FHN<DB0RGB<DB0AAB<F6KFT<LX0PAC<DB0GH<F6KMO<7M3TJZ<ON0AR<VK6HGR<
VK3AVE<ZL2BAU<ZL2BAU<ZL3VML
Sent: 040211/0936Z @:ZL3VML.#80.NZL.OC #:18866 [Chch-NZ] FBB7.00i $:2817-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
TAPR APRS Special Interest Group Digest for Monday, February 09, 2004.
1. UIDWAIT must be OFF on APRS
2. Re: No more RELAY,WIDE defaults for fixed stns
3. Re: TRACE in the FLOOD parameter???
4. Questions one digi setup
5. New n-N paradigm
6. APRS objects
7. Questions one digi setup [answered]
8. Re: Questions one digi setup
9. Re: APRS objects
10. Re: APRS objects
11. Repeater Objects [WAS: APRS objects]
12. Re: APRS objects
13. Re: APRS objects
14. Re: Repeater Objects [WAS: APRS objects]
15. RE: Repeater Objects [WAS: APRS objects]
16. Re: APRS objects
17. Re: APRS objects
18. Garmin GPS-2+ Power/Data Cable
19. Fw: Re: APRS objects
20. Re: APRS objects
21. Re: APRS objects
22. RE: Repeater Objects [WAS: APRS objects]
23. Very early prototype of APRS Map Manager
24. Re: Repeater Objects [WAS: APRS objects]
25. Re: Repeater Objects [WAS: APRS objects]
26. Re: Repeater Objects [WAS: APRS objects]
27. ISS APRS status?
28. Re: Repeater Objects [WAS: APRS objects]
29. Re: ISS APRS status?
30. RE: APRS objects
31. APRS protocol for auto QSY
32. Re: Garmin GPS-2+ Power/Data Cable
33. Weather & OS Query.
34. Has any one talked to Microsoft ?
35. Re: Weather & OS Query.
36. Re: Has any one talked to Microsoft ?
37. Re: Weather & OS Query.
----------------------------------------------------------------------
Subject: UIDWAIT must be OFF on APRS
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Mon, 09 Feb 2004 09:01:57 -0500
X-Message-Number: 1
It has come to my attention that some digi owners are mistakenly setting
UIDWAIT to ON. This is not correct. The default is OFF and should be OFF
on 144.39 everywhere.
With UIDWAIT OFF (the default, and way the system was deisgned), a DIGI
will seize the channel first and all other stations will wait. The DIGI
has priority. Packets will propagate rapidly.
With it ON, then the digis are just like all other users and have to wait
for the channel to completely clear befoer they can send on a packet. From
their HIGH locations, the channel rarely clears and this just drastically
slows down the entire network.
Example of a 2 hop packet that hits first one digi, and and then its 3 next
tier neighbors:
With UIDWAIT OFF (as designed), after the first digi digipeats a packet, we
want its 3 neighbor digis to all digipeat the result at the SAME time
(since they are all going in threee different directions, there is no
collisions in the directions of each of these digis.)
With UIDWAIT ON (as is being wrongly done in some areas), the channel
throughput will be drastically cut by 3 to 4 times because each of these 3
digis will wait just like all other users for the channel to be completely
clear before each one of them (in turn) digipeats. This is disasterous to
APRS throughtput!
APRS was designed with FRATRICIDE as a fundamental part of the system. That
is, ALL digis at the same tier outward from the source are supposed to all
digi at the same time for maximum channel efficiency and for also killing
off most of the dupes.
Please note, that the ONLY place that this fratricide kills packets is in
the area where the packet originated in the first place! Yet, the digi in
that area has ALREADY digipeated the packet once BEFORE. SO again UIDWAIT
must be OFF for maximum channel efficiency, and for eliminating some dupes.
Having it ON will triple or quadruple channel overload.
de WB4APR, Bob
----------------------------------------------------------------------
Subject: Re: No more RELAY,WIDE defaults for fixed stns
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Mon, 09 Feb 2004 09:11:37 -0500
X-Message-Number: 2
>>>"Scott Miller" <scott@3xf.com> 2/8/04 2:03:44 PM >>>
>What's the current guidance on default settings for standalone
>trackers?
>The latest firmware for the OpenTracker defaults to RELAY,WIDE.
In my opinion, that remains the universal standard for mobiles... and
HT's...
Thanks
Bob
----------------------------------------------------------------------
Subject: Re: TRACE in the FLOOD parameter???
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Mon, 09 Feb 2004 09:16:38 -0500
X-Message-Number: 3
Sounds like your local digi has set UIFLOOD to TRACE instead
of UITRACE to TRACE... Bob
----------------------------------------------------------------------
Subject: Questions one digi setup
From: John Kraus <flyfisher452@cox.net>
Date: Mon, 09 Feb 2004 11:33:22 -0500
X-Message-Number: 4
Who is the UIDIGI guru on the list?
Below is a portion of a UIDIGI setup file for a digi to be installed in
N-Georgia (near Jasper). I have a few questions on the settings which I
will comment on with ## preceding them in the file. I am not sending the
whole thing only the key areas. I can send the whole thing (minus any
secret data like passwords) if you need it.
//-----------------------------------------------------------------------
//-----------------------------------------------------------------------
// UI Generic Calls (up to 8)
// Calls recognized by digi to repeat
// Default (RELAY, WIDE, TRACE)
// Uidigi [calls]
UIDigiCall = RELAY, WIDE, TRACE, ATL, GA
//-----------------------------------------------------------------------
//-----------------------------------------------------------------------
// UI Flood Call (up to 6 characters)
// Default (WIDE)
// UIFlood [call]
UIFloodCall = WIDE
##Is this the correct setting? Or should it be Trace?
//-----------------------------------------------------------------------
//-----------------------------------------------------------------------
// UI Trace Call (up to 6 characters)
// Default (TRACE)
// UITrace [call]
UITraceCall = TRACE
//-----------------------------------------------------------------------
//-----------------------------------------------------------------------
// UIFLOOD Algorithm flag (default 0)
// bit 0 make call substitution after the last WIDEn-n digied
// bit 1 insert callsign before WIDEn-n
// UIFLDfl [n]
UIFLOODOptions = 0
## Is this "0" the same as NOID?
//-----------------------------------------------------------------------
//-----------------------------------------------------------------------
// UITRACE Algorithm flag (default 0)
// bit 0 makes call substitution after the last TRACEn-n digied
// bit 1 Disables
// UITRFl [n]
UITRACEOptions = 0
//-----------------------------------------------------------------------
//-----------------------------------------------------------------------
// Make call substitution when repeat frames addressed to UIDIGI Callsign
// default (1)
// Enables (1) or Disables (0) UIDIGI callsign substitution for UIDIGI calls
// UIDCsb [n]
UIDIGICallSubstitution = 1
## Is this "1" the same as NOID?
+++++++++++++++++++++
Does anyone have a correct UIDIGI setup file for the newest suggestions Bob
has made that I can use when people ask questions about setting up a
digi? I am using Digi_Ned so the UIDIGI syntax is unfamiliar.
----------------------------------------------------------------------
Subject: New n-N paradigm
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Mon, 09 Feb 2004 11:36:55 -0500
X-Message-Number: 5
Some areas of APRS in the USA have reasonable SYSOP cooperation over many
digis, etc, and local planning groups. It would be nice if we could
identify those major areas. I'd like to make a list for my main APRS web
page:
1) APRS Group Name
2) Point of contact: (will not list if requested)
3) Number of digis
4) List of digi calls
5) Recommended Paths:
Fixed: WIDE,WIDE
Mobile: RELAY,WIDE
Boonies: WIDE,WIDE2-2
6) Fundamentals for this group: (for example)
UIdigi: RELAY,WIDE,STATE,SAR
UIFLOOD WIDE,NOID,33
UITRACE TRACE,
6) New N-N implementations: (example)
CITYn-N is a FLOOD LAN address supported in the city only
NSn-N is a north south FLOOD LINK address along I-95
MIATPAn-N is a Miami/Tampa FLOOD LINK
Etc...
Bob
----------------------------------------------------------------------
Subject: APRS objects
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Mon, 09 Feb 2004 11:56:26 -0500
X-Message-Number: 6
There were some questions comments about APRS objects...
Please, if you are generating LOCAL Objects for your club repeater or
events, please do NOT put decimal points in for frequencies. An Object
with the name of 146.525 locks up everyone's Garmin GPS with a display:
"Revceived Invalid Waypoint, Press ENTER to resume"...
Every time it is sent. This is very frustrating for mobiles...
Instead, just list 145535 including the Khz digit whether it is a 5 or 0,
and everyone will understand: 156520 for example.
de WB4APR, Bob
----------------------------------------------------------------------
Subject: Questions one digi setup [answered]
From: John Kraus <flyfisher452@cox.net>
Date: Mon, 09 Feb 2004 12:06:51 -0500
X-Message-Number: 7
I found the answers I was looking for here. It has been updated since the
last time I looked. The settings are correct in the snip I sent. Thanks to
all who replied.
http://www.qsl.net/n8deu/uidigi_eprom_settings.htm
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
