| |
ZL3AI > APRDIG 10.04.04 13:09l 306 Lines 11445 Bytes #999 (0) @ WW
BID : 3126-ZL3AI
Read: GUEST
Subj: TAPR Digest, Apr 07, 1/1
Path: DB0FHN<DB0FOR<DB0SIF<DB0EA<DB0RES<ON0AR<ON0AR<F6KMO<EA5DVS<ED1ZAC<
ZL2TZE<ZL3VML
Sent: 040410/1047Z @:ZL3VML.#80.NZL.OC #:22166 [Chch-NZ] FBB7.00i $:3126-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
TAPR APRS Special Interest Group Digest for Wednesday, April 07, 2004.
1. RE: AX.25 Address field question?
2. RE: AX.25 Address field question?
3. RE: AX.25 Address field question?
4. Re: [ui-view] KPC-3 v8.2 digi setup questions
5. Re: [ui-view] KPC-3 v8.2 digi setup questions
6. Re: [ui-view] KPC-3 v8.2 digi setup questions
7. RE: AX.25 Address field question?
8. Packet Status Register wants your input
----------------------------------------------------------------------
Subject: RE: AX.25 Address field question?
From: "KC2MMi" <kc2mmi@verizon.net>
Date: Wed, 7 Apr 2004 12:43:37 -0400
X-Message-Number: 1
If you're going to consider new specifications at all, PLEASE consider
extending the lat/lon information in ALL modes to allow DDD.MM.mmm
precision. That last digit on the minutes is standard in maine and gps
navigation systems and equipment. We can argue over whether it is
granularity, or accuracy, but with WAAS GPS being field validated within 3
meters of best known position, it is time that APRS joined the rest of the
club.
ISO calls for the same accuracy by using DDD.dddd (?I think) but aside
anyone "required" to use that format, I don't see anyone wanting to touch
it.
----------------------------------------------------------------------
Subject: RE: AX.25 Address field question?
From: "Curt, WE7U" <archer@eskimo.com>
Date: Wed, 7 Apr 2004 09:56:09 -0700 (PDT)
X-Message-Number: 2
On Wed, 7 Apr 2004, KC2MMi wrote:
>If you're going to consider new specifications at all, PLEASE consider
>extending the lat/lon information in ALL modes to allow DDD.MM.mmm
>precision. That last digit on the minutes is standard in maine and gps
>navigation systems and equipment. We can argue over whether it is
>granularity, or accuracy, but with WAAS GPS being field validated within 3
>meters of best known position, it is time that APRS joined the rest of the
>club.
>
>ISO calls for the same accuracy by using DDD.dddd (?I think) but aside
>anyone "required" to use that format, I don't see anyone wanting to touch
>it.
The latest TinyTrak-III firmware went to DD MM.MMMM in the NMEA-type
transmitted posits, so Byon figured out a way around it while
keeping within the APRS protocol. That format results in long
sentences though, so there's a price to be paid for using it.
The only other way currently to get greater accuracy than DD MM.MM
is to use compressed posits, which are also in the spec.
I'd very much like to see us go to at least DD MM.MMM, but while
we're at it, we might as well add a fourth digit. There may be GPS
enhancement opportunities in the (far?) future that will get us
there.
Even for relative positioning using APRS client-placed objects/items
(we're not talking GPS here at all), you need to go to compressed
posits in order to get the accuracy we need for SAR missions. See
the writeup about this at:
http://www.findewe.com/nwaprs/SearchAndRescue
--
Curt, WE7U archer at eskimo dot com
Arlington, WA, USA http://www.eskimo.com/~archer
"Lotto: A tax on people who are bad at math." -- unknown
"Windows: Microsoft's tax on computer illiterates." -- WE7U
"The world DOES revolve around me: I picked the coordinate system!"
----------------------------------------------------------------------
Subject: RE: AX.25 Address field question?
From: "Scott Miller" <scott@opentrac.org>
Date: Wed, 7 Apr 2004 10:03:36 -0700
X-Message-Number: 3
OpenTRAC uses a 32 bit binary format for latitude and longitude. With the
diameter of the Earth being about 40076 km at the equator, that's
40076000/2^32 = 0.93 centimeters resolution. A lat/lon fix takes 8 bytes
total in this format.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: [ui-view] KPC-3 v8.2 digi setup questions
From: "Christensen, Eric" <CHRISTENSENE@MAIL.ECU.EDU>
Date: Wed, 7 Apr 2004 13:26:57 -0400
X-Message-Number: 4
I was just testing some items on a Kantronics 9612+ with Version 8.2
firmware.
I am trying to figure out how to setup a Kantronics Digipeater for LANn-N
use with multiple LAN addresses but it doesn't appear that the firmware will
take more than one using UIFLOOD. I can do it on the UIDIGI setting but
that would not support the n-N protocol. Does anyone know if any of the
updated firmware will support this? And while we are on the subject of
updated firmware, did they fix the ID problem?
For those that are trying to figure out what I'm doing, I'm testing LAN
settings for digipeaters. I am hoping to have multiple LANs to support
various types of areas.
NC = North Carolina area
ENC = Eastern North Carolina (East of I-95???)
MHX = Morehead City/Newport National Weather Service Area
Some digipeaters in the area would actually need more than these LANs as the
cover multiple NWS areas.
73s,
Eric KF4OTN
-----Original Message-----
From: Robert Bruninga [mailto:bruninga@usna.edu]
Sent: Tuesday, April 06, 2004 08:56
To: TAPR APRS Special Interest Group
Cc: aprssig@lists.tapr.org
Subject: [aprssig] Re: [ui-view] KPC-3 v8.2 digi setup questions
>>>James Smith <k9apr@tawg.org> 4/5/04 7:48:44 PM >>>
>
>We currently have just about every digi in Indiana set this way,
Great work, but... Shoot me now, or shoot me later...
Under the new n-N paradigm, I recommended, and you set:
UIFLOOD WIDE,28,NOID
UITRACE SS,28
This is a good starting point, as it introduced the SSn-N concept with no
impact to current operations and allowed users to learn the use of SSn-N
with no change to WIDEn-N support. But it doesnt really help encourage a
change in how users use WIDEn-N nor "manage" the improper use of WIDEn-N.
After that recommendation, I think the new n-N paradigm
evolved to a later recommendation to reverse the two as:
UIFLOOD SS,28,NOID
UITRACE WIDE,28
This works identically to end users, but it puts the full
trace on WIDEn-N to 1) provide full traceability on all paths,
2) discourage the use of LONG paths where not needed,
3) to help identify good or bad usage, and 4) to help
identify possible locations for WIDEn-N Firewalls if needed..
Also, then, since the SSn-N is SELF-LIMITING to only
the range of the SS digis, the value of N is less important
and less damaging and so the recommended user path
is WIDE,SSn-N. This still allows the path to indicate the starting point
for the packet.
Thus, both WIDEn-N and WIDE,SSn-N users and paths
are traceable to their source, and SYSOPS can see full
traces on all abusively long WIDEn-N packets. In this
area, then the receommended user settings would be:
WIDEn-N for travelers in and out of area
WIDE,SSn-N (or RELAY,SSn-N) for all local use
Anyway, something to think about. The change
has little impact on users except that in the SSn-N
case you would be asking them to use WIDE,SSn-N.
and there is no longer a need for WIDE,WIDEn-N
since WIDEn-N now becomes traceable independent
of the user setting...
Just some ideas...
de WB4APR, Bob
----------------------------------------------------------------------
Subject: Re: [ui-view] KPC-3 v8.2 digi setup questions
From: Sean Jewett <sean@rimboy.com>
Date: Wed, 7 Apr 2004 10:11:15 -0500 (CDT)
X-Message-Number: 5
On Wed, 7 Apr 2004, Christensen, Eric wrote:
>For those that are trying to figure out what I'm doing, I'm testing LAN
>settings for digipeaters. I am hoping to have multiple LANs to support
>various types of areas.
>
>NC = North Carolina area
>ENC = Eastern North Carolina (East of I-95???)
>MHX = Morehead City/Newport National Weather Service Area
>
>Some digipeaters in the area would actually need more than these LANs as the
>cover multiple NWS areas.
We looked at doing this but after getting conflicting reports on the KPC's
we decided we could live doing something like OHX,OHX as the path for NWS
packets (OHX being the NWS watch area for Middle Tennessee). While we
were confident we could do something like OHX2-2 w/ our UIDIGI rom'd TNC's
the question of the KPC's made it such it was easier to live with that
path. As it stands, the igate going up to gate NWS packets will run with
WIDE,OHX since one of the digi's close to it not set to act on OHX yet...
better yet it's so misconfigured we don't hold out any hope of it being
fixed anytime soon. And the callsign on that digi works for the NWS!
The few relay only stations we have are also setup to act on the OHX path.
Our thinking is that if they're filling in a gap in coverage then it's
important to make sure that the area is covered when an NWS statement is
issued. We only have one or two relay digi's so it should not be too much
of a problem.
Sean...
--
The punk rock will get you if the government don't get you first.
--Old 97's
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
KG4NRC http://www.rimboy.com Your source for the crap you know you need.
----------------------------------------------------------------------
Subject: Re: [ui-view] KPC-3 v8.2 digi setup questions
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Wed, 07 Apr 2004 15:15:35 -0400
X-Message-Number: 6
>>>"Christensen, Eric" <CHRISTENSENE@MAIL.ECU.EDU> 4/7/04 1:26:57 PM
>
>I am trying to figure out how to setup a Kantronics Digipeater
>for LANn-N use with multiple LAN addresses...
>NC = North Carolina area
>ENC = Eastern North Carolina (East of I-95???)
>MHX = Morehead City/Newport National Weather Service Area
You are correct that you only have two choices for two LANn-N names and 4
more LAN names. But under the new paradigm where hopefully all packets are
no more than 2 RF hops from where they need to go, this is not a
significant shortcoming.
All 6 of the above types will all arrive with about 2 digi fields used
whether you use n-N or UIDIGI type hopping. So I would stick with using
the four UIDIGI fields for those overlaping WX areas and keep UITRACE for
auto-path tracing of WIDEn-N and then UIFLOOD for the center of your city
area...
just some thoughts...
Bob
----------------------------------------------------------------------
Subject: RE: AX.25 Address field question?
From: Jeff King <jeff@aerodata.net>
Date: Wed, 07 Apr 2004 14:44:28 -0500 (CDT)
X-Message-Number: 7
One word:
OpenTrac
http://www.opentrac.org/
Quoting KC2MMi <kc2mmi@verizon.net>:
>If you're going to consider new specifications at all, PLEASE consider
>extending the lat/lon information in ALL modes to allow DDD.MM.mmm
>precision. That last digit on the minutes is standard in maine and gps
>navigation systems and equipment. We can argue over whether it is
>granularity, or accuracy, but with WAAS GPS being field validated within 3
>meters of best known position, it is time that APRS joined the rest of
>the club.
>
>ISO calls for the same accuracy by using DDD.dddd (?I think) but aside
>anyone "required" to use that format, I don't see anyone wanting to
>touch
>it.
----------------------------------------------------------------------
Subject: Packet Status Register wants your input
From: Stan Horzepa <stanzepa@earthlink.net>
Date: Wed, 07 Apr 2004 18:35:07 -0400
X-Message-Number: 8
The Spring issue of Packet Status Register (PSR), TAPR's quarterly
newsletter, is now in the works. If you have anything to contribute to PSR,
now is the time to do so. The deadline for PSR is April 25, so please send
me your input as soon as you can.
Thank you,
Stan Horzepa, WA1LOU
PSR Editor
---
END OF DIGEST
Read previous mail | Read next mail
| |
