| |
ZL3AI > APRDIG 08.05.04 20:50l 276 Lines 9548 Bytes #999 (0) @ WW
BID : 3192-ZL3AI
Read: GUEST
Subj: TAPR Digest, Apr 19, 2/5
Path: DB0FHN<DB0FOR<DB0MRW<OK0PKL<OK0PPL<DB0RES<ON0AR<ZL2TZE<ZL3VML
Sent: 040508/1921Z @:ZL3VML.#80.NZL.OC #:23604 [Chch-NZ] FBB7.00i $:3192-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: APRS greater precision
From: Jeff King <jeff@aerodata.net>
Date: Mon, 19 Apr 2004 14:25:57 -0500 (CDT)
X-Message-Number: 7
Quoting Robert Bruninga <bruninga@usna.edu>:
>>Think about it (or tell me which ones will display it)
>
>All of them...
Every APRS GUI application on the market today, will display Base91
compressed posits?
If so, sorry then, I thought only a few would do this... at least on the
last survey that was the case.
>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 16:01:00 -0400
X-Message-Number: 8
Jeff,
You are missing the topic here. No one is talking about compresesd
position reports. We are talking about adding precision to *any* existing
APRS position report format so as not to cause any existing application (or
the Kenwoods) not to still see the position.
>>>Jeff King <jeff@aerodata.net> 4/19/04 3:22:16 PM >>>
>
>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.
That's why I have resisted and still discourage anyone from using the
compressed format.
>>The added precision is just added for those stations
>>that can use it...
>
>Right, where do we disagree here?
Just as you quoted in my next sentence:
>>Ignoring positions on APRS is not something
>>I would encourage.
and that is why I do not encourage the use of the compressed position
report on APRS... and why I am working to come up with a workable
alternative that adds precision but without causing any existing
application not to still be able to use the position.
Bob
----------------------------------------------------------------------
Subject: Re: APRS greater precision
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Mon, 19 Apr 2004 16:04:58 -0400
X-Message-Number: 9
>>>Jeff King <jeff@aerodata.net> 4/19/04 3:25:57 PM >>>
>Every APRS GUI application on the market today,
>will display Base91 compressed posits?
>
>If so, sorry then, I thought only a few would do this...
>at least on the last survey that was the case.
You are correct. They won't and that is why I do not recommend the
compresessed format to anyone. Many reasons:
1) it was not implemented by many applications.
2) It was intended for compression, not precision
3) Too many people confuse precision and will use it wrongly since
precision is useless without knowing the DATUM.
So for the sake of standard comunications protocol that will have a good
chance of proper interpretation at the "other end of a comuniations
network" one should not use the compressed format...
Bob
----------------------------------------------------------------------
Subject: Re: APRS greater precision
From: Jeff King <jeff@aerodata.net>
Date: Mon, 19 Apr 2004 15:14:18 -0500 (CDT)
X-Message-Number: 10
Quoting Robert Bruninga <bruninga@usna.edu>:
>Jeff,
>
>You are missing the topic here. No one is talking about
>compresesd position reports.
You started a new topic.... I wasn't following the old, and the new one was
"greater precision".
So, once again, this is one of those rambling topics that jumps from
subject to subject but the end result is how to fit 20lbs into a 5 lbs box?
Count me out then and sorry I stepped into it. I (mistakenly) thought we
might be making progress here.
73
Jeff
----------------------------------------------------------------------
Subject: APRS version2.0 spec, was Re: APRS greater precision
From: Jeff King <jeff@aerodata.net>
Date: Mon, 19 Apr 2004 15:22:44 -0500 (CDT)
X-Message-Number: 11
Hey Bob:
Changed the topic so this thread would make some sense.
Quoting Robert Bruninga <bruninga@usna.edu>:
>>>>Jeff King <jeff@aerodata.net> 4/19/04 3:25:57 PM >>>
>
>>Every APRS GUI application on the market today,
>>will display Base91 compressed posits?
>>
>>If so, sorry then, I thought only a few would do this...
>>at least on the last survey that was the case.
>
>You are correct. They won't and that is why I do not
>recommend the compresessed format to anyone.
I saw the base91 stuff and thought we where talking about the compressed
format. Sorry for the misunderstanding.
Many
>reasons:
>1) it was not implemented by many applications.
>2) It was intended for compression, not precision
>3) Too many people confuse precision and will use
>it wrongly since precision is useless without knowing
>the DATUM.
Since you admit to the above, it makes sense to drop it from the spec.
Replace it with OpenTrack for that subsection. It gives the compression as
well as the precision here. We certainly would be no worse off then with
the compressed format in the spec, and since it is easier to implement, we
could end up ahead with a larger buy in, in particular with the embedded
trackers.
I think it would be the right thing to consider in light of what you just
said.
73's
Jeff wb8wka
----------------------------------------------------------------------
Subject: Re: APRS greater precision
From: "Scott Miller" <scott@opentrac.org>
Date: Mon, 19 Apr 2004 13:36:03 -0700
X-Message-Number: 12
>and that is why I do not encourage the use of the
>compressed position report on APRS... and why
>Iam working to come up with a workable alternative
>that adds precision but without causing any existing
>application not to still be able to use the position.
So we're talking about another four or five bytes, and more obfuscation of
the spec and the parsers that have to implement it, for how much of a gain
in precision?
I'm not saying OpenTRAC is the answer to everything, but to use it as an
example - even with the element overhead it only takes 10 bytes to indicate
position with a resolution of 1 cm. If bandwidth is critical, you could
allocate another PID for a fixed-field position report and get a position to
2.5 meters using only 6 bytes of payload.
Backward compatibility is a worthwhile goal, but you've got to draw the line
somewhere. Remember a few years ago when every peripheral you bought wanted
to plug into your printer port? I had a printer, zip drive, scanner, and
webcam that all wanted to use that one port, that wasn't designed for it.
They all tried to maintain compatibility, but it just ended up being a
nightmare. USB has meant a lot of investment in new hardware and drivers,
but it's a vast improvement over what came before, and it couldn't have been
done without a break with the past.
Scott
N1VG
----------------------------------------------------------------------
Subject: BalloonSat VII recovery
From: "Tim Cunningham" <tim_cunningham@mindspring.com>
Date: Mon, 19 Apr 2004 13:28:15 -0500
X-Message-Number: 13
BalloonSat VII was actually BalloonSat VIII. Somehow we got off track with
the numbers.
The payload landed 2.9 miles northeast of Guntersville State Park in
Alabama. The GPS system encountered a power failure around 41,000 feet on
the ascent and no further position beacons were transmitted. The telemetry
data and status beacons continued to perform throughout the flight.
The secondary CW ID beacon also stopped operation about the same time of
the GPS power failure. It is believed that it was not properly insulated
and simply got too cold. It started operating as the payload was descending
in warmer air. This was good news because it was the only way to find the
payload. When the payload landed the Fox Hunt started. Since it landed in
some very hilly terrain, access to the landing site was limited.
The team has learned the KPC3+ MX unit is not very easy to get the position
beacon started. During the setup of last two flights the TNC had to be
remotely reset for the position beacons to start transmitting.
WB4FAY and the team from Birmingham found the payload again this weekend.
Thanks for all the reports.
73's de Tim - N8DEU
----------------------------------------------------------------------
Subject: Re: APRS greater precision
From: "Scott Miller" <scott@opentrac.org>
Date: Mon, 19 Apr 2004 13:45:08 -0700
X-Message-Number: 14
>3) Too many people confuse precision and will use
>it wrongly since precision is useless without knowing
>the DATUM.
So why wasn't it indicated in the spec? The easy solution is to do what we
did in the OpenTRAC spec - it explicitly states that all positions are in
WGS84.
On a more practical level, most people don't know or care. They start up
their mapping program, and it draws the stations as accurately as it can
manage. Should we have little 5-meter circles around each station to
indicate error? Your average APRS user probably won't even notice that the
position format is compressed, Mic-E, or other.
>So for the sake of standard comunications protocol
>that will have a good chance of proper interpretation
>at the "other end of a comuniations network" one
>should not use the compressed format...
So why is it Mic-E is OK, but compressed format is not? Mic-E introduces
unprintable characters, subverts the TOCALL field, and generally makes life
miserable for software authors, but it's used everywhere while the more
straightforward compressed format is shunned.
Scott
N1VG
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
