| |
ZL3AI > APRDIG 08.05.04 20:53l 263 Lines 10391 Bytes #999 (0) @ WW
BID : 3169-ZL3AI
Read: GUEST
Subj: TAPR Digest, Apr 18, 3/4
Path: DB0FHN<DB0RGB<OK0PPL<DB0RES<ON0AR<ZL2TZE<ZL3VML
Sent: 040508/1921Z @:ZL3VML.#80.NZL.OC #:23601 [Chch-NZ] FBB7.00i $:3169-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: [aprssig] Re: Balloon Launch WIKI page needed`
:I added WIKIServer to my web site.
:
:There is a Balloon Event page started as well as an APRS event page started.
:I am not a wiz at web pages but these pages allow a vistor to edit the pages
:to add their events, etc.
:Hopefully, the Ballon people will use it to add balloon events from all
:over, so that when there is an event, people can have a one stop location to
:find out. Same goes for APRS events.
:If it's used, I'll stick it on a real server!
:http://www.wa6oft.com:84
:
:Enjoy!
:
:----- Original Message -----
:From: "Kurt A. Freiberger" <kurt@badgers-hill.net>
:To: "TAPR APRS Special Interest Group" <aprssig@lists.tapr.org>
:Sent: Saturday, April 17, 2004 9:29 PM
:Subject: [aprssig] Re: Balloon Launch WIKI page needed`
:
:>As I remember, most balloons I've seen had wiki baskets that people rode in.
:>Oh, that's wicker....
----------------------------------------------------------------------
Subject: Re: [ui-view] Ambiguity?
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Sun, 18 Apr 2004 16:00:58 -0400
X-Message-Number: 14
>>>"Robert Bruninga" <bruninga@usna.edu> 4/18/04 3:52:20 PM >>>
>Its very simple. Each of these latitudes has more and more
>accuracy:
> 38__.__ is good to the nearest 60 miles
> 385_.__ is good do the nearest 10 miles
> 3859.__ is good to the nearest mile
> 3859.1_ is good to the nearest tenth of a mile
> 3859.13 is good to the nearest 60 feet or so
> YYYY is a compressed position good to the nearest foot or so.
>
>How do you use this in APRSDos? I am trying to think why I would need this.
Because as everyone learned in Middle School, any number that is used to
represent a measureable quantity MUST also convey the precision to which
that number is known.
APRS is a system that frequently transmits positions and therefore IT MUST
CONVEY THE DEGREE to which the SENDER knows the precision of the
measurement. In many MANY cases in APRS, positions are not known to the
accuracy of GPS and they MUST NOT BE CONFUSED with other positions that
do...
Thus APRSdos and ther resulting spec INSITSTS that positions only be
TRANSMITTED to the precision that the SENDER can guarantee and similarly
that the RECEIVER MUST NEVER display a position to a higher precision than
intended by the SENDER. Thus my never-ending battle over this issue. where
everyone assumes that a position transmitted as 38 deg 59 minutes north is
the same as 38.983333333. IT IS NOT!
It is 38 degrees and 59 minutes plus or minus a half mile...
Nothing else...
Remember, when APRS came out, we still used LORAN and we still ESTAIMATE
positions of Storms and objects on APRS...
Bob
----------------------------------------------------------------------
Subject: Re: [ui-view] Removal of the UI-View message extensions from UI-View32
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Sun, 18 Apr 2004 16:01:47 -0400
X-Message-Number: 15
>>>wb4apr@amsat.org 4/18/04 3:58:49 PM >>>
>I would be able to see the same with compressed posits
>... I do not know how on earth anyone can argue that.
Its easy, we have argued over and over on this SIG that it is just plain
WRONG to transmit a position with precision to ONE FOOT if the position is
NOT known to that accuracy. And to my knowledge NONE of the existin g
common mapping programs in use on APRS have anywhere near that kind of
precision.
Compressed posit format is in the SPEC for use in special CLOSED systems
where you can GUARANTEE that the precision transmitted has that precision,
otehrwise you are doing everyone a disservice by transmitting WRONG data.
SO many people raised on calculators think that precision is GOOD. The
more digits the better. This is just plain WRONG and is dangerous when
used in the hands of people that dont know the difference...
When there is an APRS mapping system that is used in a closed system (and
can be guaranteed to be used in that closed system and not used elsewhere)
then that is where the compressed position report should be used...
Bob
----------------------------------------------------------------------
Subject: APRS greater precision
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Sun, 18 Apr 2004 17:47:36 -0400
X-Message-Number: 16
The only way I would support greater precision in APRS is
if the following conditions are met:
1) Backwards compatible with ALL existing systems
2) Must contain the DATUM in every such position
3) Sending PC only will use it if DATUM and precision are KNOWN
4) Users cannot just manually insert it
Here is a possibility: !XYZ! inserted in the COMMENT field
where: !...! is the format identifier
X is the Datum (1 of 90 possible) One is user assigned.
Y and Z are the added precision in Lat and Long.
X,Y and Z are base 91. Thus this is printible ASCII and fully backwards
compatible. Base 91 will get us to 91% of .xxxx minutes which is what most
GPS's do. Thats about a foot. But ALSO I would want to see the sending
software implement these restrictions:
a) If manually entered, the user must verify a datum, must VERIFY that he
knows it to that precision AND must read a WARNING not to use
precision where it does not exist
b) No object will be inserted into APRS to any greater precision than
the size of the ICON on the given map currently in use. APRS dos
does this. If you put an object on the map at the 8 mile scale using
only the mouse, it automatically leaves the hundredths blank. At the
64 mile scale, it only gives the object a 1 mile precision... etc...
If you know it more precise, then you either have to type it in
manually, or zoom to a highest resolution map that will make the ICON
no larger than the uncertainty of the position reported.
c) On receipt, the presence of position ambiguity MUST be conveyed to
the end user. I leave this up to the author, but it must be clear
and undeniable to any casual user that a given ICON is not being
displayed to a greater precision than the sender intended. Two easy
ways, 1) Either blow up the ICON to cover the area of ambiguity on
very high zooms, or draw a circle of ambiguity around it...
d) if the Sendres MAP and the receipients MAP are not identical, or or
not tot he same datum, then the RECEIVING software must ASSIGN a
large enough ambiguity to the ICON to cover the diffrences in datums.
If it does not know the difference, then it should stick with the
existing hundredths or less precisinos...
Or something like that.
Anyway, I am not against higher precisinos, but it must be done carefully
and correctly or it will only make matters WORSE.
Bob
----------------------------------------------------------------------
Subject: Re: APRS greater precision
From: Jeff King <jeff@aerodata.net>
Date: Sun, 18 Apr 2004 19:31:21 -0400
X-Message-Number: 17
On Sun, 18 Apr 2004 17:47:36 -0400, Robert Bruninga wrote:
>The only way I would support greater precision in APRS is if the
>following conditions are met:
>1) Backwards compatible with ALL existing systems
Bob:
Do realize that immediately says you won't support it, because none of the
existing systems will display some as yet undefined standard.
Think about it (or tell me which ones will display it)
-Jeff
p.s.
>X,Y and Z are base 91. Thus this is printible ASCII and
>fully backwards compatible. Base 91 will get us to 91%
>of .xxxx minutes which is what most GPS's do.
Computers eventually moved beyond C/PM and TTY terminals and maybe it is
time for APRS to do the same? Printable ascii is all well and good, but we
are a long long way from the standalone TNC and terminal program, or at least
one would hope. My 2 cents.
----------------------------------------------------------------------
Subject: fourth.aprs.net
From: Gerry Creager N5JXS <gerry.creager@tamu.edu>
Date: Sun, 18 Apr 2004 18:42:36 -0500
X-Message-Number: 18
After some hacking and attempts to improve performance, while
supervising a pair of 6-year-olds (or, maybe they were supervising me),
fourth.aprs.net appears to have been successfully updated and upgraded.
I apologize to anyone who was inconcenienced by the unplanned and
unannounced maintenance window.
Gerry N5JXS
--
Gerry Creager -- gerry.creager@tamu.edu
Network Engineering -- AATLT, Texas A&M University
Cell: 979.229.5301 Office: 979.458.4020 FAX: 979.847.8578
Page: 979.228.0173
Office: 903A Eller Bldg, TAMU, College Station, TX 77843
----------------------------------------------------------------------
Subject: Re: APRS greater precision
From: Tim Cwik <tcwik@stnhbr.com>
Date: Sun, 18 Apr 2004 19:53:44 -0400
X-Message-Number: 19
On 2004.04.18 19:31, Jeff King wrote:
>
>On Sun, 18 Apr 2004 17:47:36 -0400, Robert Bruninga wrote:
>>The only way I would support greater precision in APRS is if the
>>following conditions are met:
>>1) Backwards compatible with ALL existing systems
>
>Bob:
>
>Do realize that immediately says you won't support it, because none of the
>existing systems will display some as yet undefined standard.
>
>Think about it (or tell me which ones will display it)
It would appear Bob suggested backwards compatible. This does not mean
that the older systems must display the format, it means that using the
greater precision must not break the older systems. By including the
greater precision information as a comment, the older systems can ignore it.
>-Jeff
>
>p.s.
>
>>X,Y and Z are base 91. Thus this is printible ASCII and
>>fully backwards compatible. Base 91 will get us to 91%
>>of .xxxx minutes which is what most GPS's do.
>
>
>Computers eventually moved beyond C/PM and TTY terminals and maybe it is
>time for APRS to do the same? Printable ascii is all well and good, but we
>are a long long way from the standalone TNC and terminal program, or at least
>one would hope. My 2 cents.
but one of the best ways to debug interfaces in software and hardware is
to be able to look at the data. Printable ascii makes this a lot easier.
--
Tim Cwik
tcwik@stnhbr.com spamtrap: tjc123@stnhbr.com
Voice: 609-368-2482 Fax: 609-368-3695
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
