| |
ZL3AI > APRDIG 08.05.04 20:50l 250 Lines 9550 Bytes #999 (0) @ WW
BID : 3191-ZL3AI
Read: GUEST
Subj: TAPR Digest, Apr 19, 1/5
Path: DB0FHN<DB0THA<DB0ERF<DB0FBB<DB0GOS<DB0EEO<DB0RES<ON0AR<ZL2TZE<ZL3VML
Sent: 040508/1921Z @:ZL3VML.#80.NZL.OC #:23603 [Chch-NZ] FBB7.00i $:3191-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
TAPR APRS Special Interest Group Digest for Monday, April 19, 2004.
1. Re: [ui-view] Removal of the UI-View message extensions fromUI-View32
2. Re: APRS greater precision
3. Re: APRS greater precision
4. Re: APRS greater precision
5. Re: APRS greater precision
6. Re: APRS greater precision
7. Re: APRS greater precision
8. Re: APRS greater precision
9. Re: APRS greater precision
10. Re: APRS greater precision
11. APRS version2.0 spec, was Re: APRS greater precision
12. Re: APRS greater precision
13. BalloonSat VII recovery
14. Re: APRS greater precision
15. APRS version2.0 spec, was Re: APRS greater precision
16. Re: APRS greater precision
17. Re: APRS greater precision
18. Re: APRS greater precision
19. Icom mobile APRS van thing???
20. Re: APRS greater precision
21. Re: APRS greater precision
22. Re: APRS greater precision
23. Re: Icom mobile APRS van thing???
24. Re: APRS greater precision
25. Re: APRS greater precision
26. Re: APRS greater precision
27. Re: APRS greater precision
28. Re: APRS greater precision
29. Re: APRS greater precision
30. Re: APRS greater precision
31. Re: Icom mobile APRS van thing???
----------------------------------------------------------------------
Subject: Re: [ui-view] Removal of the UI-View message extensions fromUI-View32
From: "Scott Miller" <scott@3xf.com>
Date: Sun, 18 Apr 2004 21:40:44 -0700
X-Message-Number: 1
>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.
Just because you learned in grade school that you should write numbers a
certain way to indicate precision, doesn't mean you should apply the same to
internal storage formats intended for computers to read.
In a binary format like OpenTRAC or Garmin's interface, or quasi-binary
format like compressed APRS, you've got a certain number of bits allocated
to try to represent a position. There's no implication or expectation that
the number format indicates the actual precision.
Some GPS receivers report position in radians using IEEE double-precision
floating point format. I don't care to figure out at the moment what degree
of resolution that would allow, but it's orders of magnitude greater than
the 1 cm or so you can get with a 32-bit number. The point is, that's
RESOLOUTION, not PRECISION.
If you care about making the precision known (and you probably should), you
can devote extra bits to that information. In OpenTRAC it's done with a
positional ambiguity element. At the moment it allows you to specify an
ambiguity of between 1m and ~65km. There's some concern right now that
sub-meter values would be necessary, so the element may be expanded.
If you're really serious about data quality, OpenTRAC also lets you report
HDOP, VDOP, and PDOP. Remember, the number Garmin gives you for estimated
position error is just derived from these values. I'm sure Gerry could
provide us with a lesson in GPS math to explain what these values really
mean, if anyone's interested. A few minutes of that variance-covariance
matrix stuff and my eyes start to glaze over, though.
>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.
First, where does it say in the spec that it's not intended for general use?
Second, name one existing piece of software or hardware that monitors the
GPS signal quality and passes that information through to APRS.
Further reading on GPS dilution of precision, for those with a longer
attention span than me:
http://www.pobonline.com/CDA/ArticleInformation/features/BNP__Features__Item
/0,2338,72407,00.html
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: APRS greater precision
From: "Scott Miller" <scott@3xf.com>
Date: Sun, 18 Apr 2004 21:44:46 -0700
X-Message-Number: 2
>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.
True. That's one of the objections I've heard to OpenTRAC. Yet AX.25, IP,
and countless other protocols work quite well despite this.
I've got no problem debugging something in a hex editor. What's really a
pain is dealing with something like APRS's Base 91 where it's trying to
squeeze binary data into a printable format.
It mostly just comes down to having the right tools for the job.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: APRS greater precision
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Mon, 19 Apr 2004 09:15:21 -0400
X-Message-Number: 3
On Sun, 18 Apr 2004 17:47:36 -0400, Robert Bruninga wrote:
>The only way I would support greater precision in APRS is...
>1) Backwards compatible with ALL existing systems
>>>Jeff King <jeff@aerodata.net> 4/18/04 7:31:21 PM >>>
>Do realize that immediately says you won't support it,
>because none of the existing systems will display
>some as yet undefined standard.
Not true. Adding !xyz! into the comment field of an APRS position does
not-break-anything and will be decoded and properly displayed on any
existing APRS system. Yet it allows people that have the need to transmit,
and the MAPS to support it, to send it and those that can accurately
receive it to plot it..
>Think about it (or tell me which ones will display it)
All of them...
Bob
>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.
----------------------------------------------------------------------
Subject: Re: APRS greater precision
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Mon, 19 Apr 2004 09:21:42 -0400
X-Message-Number: 4
>>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
>>>Jeff King <jeff@aerodata.net> 4/18/04 8:44:42 PM >>>
>The older systems can also ignore binary precision formats.
It is not "ignoring" that my proposal does, it still lets ANY existing APRS
compliant user see still the original precision. The added precision is
just added for those stations that can use it...
Ignoring positions on APRS is not something I would encourage.
Bob
----------------------------------------------------------------------
Subject: Re: APRS greater precision
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Mon, 19 Apr 2004 09:39:57 -0400
X-Message-Number: 5
This is exactly why I am concerned:
>If my GPS says it has me within 10 feet, then by golly don't
>show me somewhere else! I know that my software
>might be a limitation, but that will only get better if the protocol
is
>better! If the protocol isn't better then why should the software?
This shows that people will -blindly- accept the numbers coming out of
their GPS device and act on it, becuse they have no clue as to the limits
of such accuracies. That is why we have people that still run-aground, on
boats, because they think that because the GPS says I am "here" then they
must be "here" when in fact no two GPS's will even give the same answer,
much less the GPS and the chart, AND MUCH LESS that the ROCKS know where
they are supposed to be relative to either one of them.
Incorrect use of "precision" versus "accuracy" is one of the most
frustrating things to teach. My kids just went through it in middle
school... If the teacher asks, "The train is going at 20 MPH and it was
asked to slow to 1/3rd of its speed, how fast should it fo?"
The correct answer is 6 MPH. The wrong answer is 6.3333333 becasue it
shows that the student does not understand the limits of accuracy on the
original problem.
Written Numbers convey two things, not only the VALUE, but also and
indication of the DEGREE of precision to which they are known. The
Calculator generation just never seems to get this....
Bob
----------------------------------------------------------------------
Subject: Re: APRS greater precision
From: Jeff King <jeff@aerodata.net>
Date: Mon, 19 Apr 2004 14:22:16 -0500 (CDT)
X-Message-Number: 6
Quoting Robert Bruninga <bruninga@usna.edu>:
>>>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
>
>>>>Jeff King <jeff@aerodata.net> 4/18/04 8:44:42 PM >>>
>>The older systems can also ignore binary precision formats.
>
>It is not "ignoring" that my proposal does, it still lets ANY existing
>APRS compliant user see still the original precision.
I've a mapping application can't display a Base91 compressed posit, what
would you call that? You call it tomato I call it tomatoe? If it doesn't
display it, it effectively ignores it.
>The added
>precision is just added for those stations that can use it...
Right, where do we disagree here?
>Ignoring positions on APRS is not something I would encourage.
The proper place to address this is with APRS certification of applications.
BTW, I guess Scott should be the one asking this, but how do we go about
getting OpenTrak adopted for inclusion in the APRS spec?
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
