| |
ZL3AI > APRDIG 12.05.04 09:52l 242 Lines 9288 Bytes #999 (0) @ WW
BID : 3210-ZL3AI
Read: GUEST
Subj: TAPR Digest, Apr 22, 4/10
Path: DB0FHN<DB0FOR<DB0SIF<DB0EA<DB0RES<ON0AR<ZL2BAU<ZL2BAU<ZL3VML
Sent: 040512/0738Z @:ZL3VML.#80.NZL.OC #:23788 [Chch-NZ] FBB7.00i $:3210-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: The APRS-WG and spec improvements.
From: "Curt, WE7U" <archer@eskimo.com>
Date: Thu, 22 Apr 2004 09:58:23 -0700 (PDT)
X-Message-Number: 19
On Thu, 22 Apr 2004, Robert Bruninga wrote:
>As the technical chair for the APRS-WG, I try to make sure
>that the on-air protocol remains compatible. And document
>the improvements since publication.
Somebody I know very well did rather a lot of effort to help you initially
in this effort. The Errata page. That took a lot of hours of looking
through old e-mail to collect the information.
>This is important
>for a service where multiplle authors bring multiple ideas to
>the table. The last thing we want is multiple incompatibilities.
Which is why we're all working on this and so passionate about doing so.
>I also strive to incorporate new needs into the protocol but
>it is hard when I cannot get agreement from the individual
>authors. If we cannot get agreement, then we cannot put
>it in the spec. This is as frustrating to me as it is to you...
Agreed. I'm frustrated.
Frustrated because the Base-91 Compressed posits that you worked so hard to
get included in the spec, worked hard to impress upon me that I should
implement and use, both in my original 68HC11 tracker and later in Xastir,
is now being poo-pooed by you.
You wanted me to use it on the air so that other authors would support it,
yet now you are asking that it not be used? If only that were implemented
across-the-board we'd have support for higher resolution. We'd need it
implemented for normal posits and for objects/items. I don't even think
most of the APRS clients support items yet. All of these things I describe
are fully defined in the spec!
>In response to the demand for more precision, for example,
>I immediately made a working proposal for the !XYZ!
>construct that gives precision to 1 foot and also includes
>the DATUM information AND is fully backwards compatible
>with all existing applications. Yet, it was ignored... and
>there were no alternatives offered other than:
I have no problem with the datum thing, although I'd rather see WGS84 used
across the air in all cases. I'll go with the transmitted datum though, as
I _did_ propose that some years ago when I discovered that the GPS'es were
sending out NMEA streams in other datums and informed you of that fact.
The extra precision thing I see as a hack, but it does fit with the rest of
the protocol (that sounds bad!). What I mean is that it is
backwards-compatible with the fixed-firmware Kenwoods.
Are you reversing your position on Base-91 merely because of the Kenwoods,
or for some other reason?
>"my software can do it better..." Mine has precision to 1 cm,
>"Mine can do anything"..
Never saw any of that. Read the e-mails more objectively and you won't see
that either. You'll see honestly concerned people talking about issues
that are important to them.
>Lets abandon the kenwoods...
>"We must abandon the protocol"... "Radios that cost $475 are too
>expensive..."
>etc. You see why it is so hard to get ANY change to the APRS
>protocol?
I did see all of that! Things get out-of-hand on this SIG. For somre
reason that's the nature of this SIG, and always has been.
>Many people that could make it work
>are only in it for themselves... instead of working as a
>group for the best for all of us..
That is most certainly an incorrect generalization. I know you're talking
about a lot of people here, not just me, but I can't speak for them.
As for me, I'm genuinely interested in all of these topics, and am in a
position to do something about it, and quickly. Once we have answers that
people can live with, I'll implement them. Period.
--
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: Additional thoughts on the great debate....
<LYR36507-195826-2004.04.22-12.06.35--mikejp#videotron.ca@lists.tapr.org>
From: wes@johnston.net
Date: Thu, 22 Apr 2004 13:00:27 -0400 (EDT)
X-Message-Number: 20
On Thu, 22 Apr 2004 12:42:52 -0400, "Michael J. Pawlowsky" wrote:
>So instead of starting with ! or / start it with another byte for the
"Extended
>Precision" format or whatever you will call it.
>
>New software coming out should be able to recognize which format is used and
>handle either one of them.
And what of the poor kenwood users who can't upgrade to "new software"?
They will be obsolete, the crux of this argument. ;-)
Wes
ham callsign: kd4rdb
find me: http://wesvan.zapto.org
----------------------------------------------------------------------
Subject: Re: Additional thoughts on the great debate....
From: "Scott Miller" <scott@opentrac.org>
Date: Thu, 22 Apr 2004 10:01:33 -0700
X-Message-Number: 21
>I don't have the APRS spec fresh in my head at all at the moment.
>But why not simply have another format type.
>
>That way applications/people that want to use it can.
>Other's that do not will not.
For exactly the same reason that we've been stuck witih ugly kludges for
everything else - a new format won't work with the Kenwoods. We're even
discouraged from using the existing ratified Base91 format for that same
reason. If the ability to represent ambiguity was the real deficiency, we
could just add a single character as a logarithmic scale error value and
we'd still be ahead.
I say if we're going to add another kludge to the existing position format,
let's think a little bit beyond this particular extension. Provide a
mechanism to add more fields in a consistent manner, so next time we want
to add something we've already got a place to put it.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: Additional thoughts on the great debate....
<LYR36507-195826-2004.04.22-12.06.35--mikejp#videotron.ca@lists.tapr.org>
From: "Curt, WE7U" <archer@eskimo.com>
Date: Thu, 22 Apr 2004 10:06:01 -0700 (PDT)
X-Message-Number: 22
On Thu, 22 Apr 2004, Michael J. Pawlowsky wrote:
>I somewhat have to agree with what a kludge.
>
>Personally whenever I read all these specs it looks like this kind of stuff
was done and seems like a quick fix to a problem.
>A bit like altitude.
>
>I don't have the APRS spec fresh in my head at all at the moment.
>But why not simply have another format type.
>
>That way applications/people that want to use it can.
>Other's that do not will not.
We don't _NEED_ another format type, as the Base-91 Compressed format gives
us what we need, and it is in the ratified spec. The problem is that it
does not work with the Kenwoods, so that Kenwoods would not decode it, or
show a '?' or something. Right?
Personally I wouldn't mind if some of the fixed-firmware units out there
didn't decode a few packets. It's not the end of the world.
We could stick to the published spec, perhaps add the new DATUM thing that
Bob proposed, and call it good.
>New software coming out should be able to recognize which format
>is used and handle either one of them.
And regularly-updated software. Yes. The rest will fall behind and then
fall out of favor.
--
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: Additional thoughts on the great debate....
From: "Curt, WE7U" <archer@eskimo.com>
Date: Thu, 22 Apr 2004 10:10:35 -0700 (PDT)
X-Message-Number: 23
On Thu, 22 Apr 2004, Scott Miller wrote:
>For exactly the same reason that we've been stuck witih ugly kludges for
>everything else - a new format won't work with the Kenwoods. We're even
>discouraged from using the existing ratified Base91 format for that same
>reason. If the ability to represent ambiguity was the real deficiency, we
>could just add a single character as a logarithmic scale error value and
>we'd still be ahead.
Perfect. Simple yet effective, and actually conveys the information
properly, instead of the method used in the current spec.
The ambiguity is a minor point though, perhaps not worth further heated
discussions at this time. I do like your suggestion though.
>I say if we're going to add another kludge to the existing position format,
>let's think a little bit beyond this particular extension. Provide a
>mechanism to add more fields in a consistent manner, so next time we want to
>add something we've already got a place to put it.
User-defined data format anyone?
--
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!"
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
