| |
ZL3AI > APRDIG 12.05.04 10:00l 404 Lines 16057 Bytes #999 (0) @ WW
BID : 3214-ZL3AI
Read: GUEST
Subj: TAPR Digest, Apr 22, 8/10
Path: DB0FHN<DB0FOR<DB0SIF<DB0EA<DB0RES<ON0AR<ZL2BAU<ZL2BAU<ZL3VML
Sent: 040512/0738Z @:ZL3VML.#80.NZL.OC #:23792 [Chch-NZ] FBB7.00i $:3214-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: Additional thoughts on the great debate....
From: "Curt, WE7U" <archer@eskimo.com>
Date: Thu, 22 Apr 2004 14:33:26 -0700 (PDT)
X-Message-Number: 46
On Thu, 22 Apr 2004, Robert Bruninga wrote:
>>>>"Curt, WE7U" <archer@eskimo.com> 4/22/04 11:47:27 AM >>>
>>Ambiguity:.. I suspect it will get dropped again.
>>Perhaps there's a good reason that this one keeps
>>popping up every few years Bob?
>
>Yep, those people who were asleep in their middle
>school science class when they were supposed to
>learn about precision, accuracy, and significant digits
>will never get it... So we have to go over it again and again...
I was talking about the "ambiguity" thread, not the precision "thread". I'm
going to drop that thread for now 'cuz there's no progress being made on
the issue.
>I have proposed the !XYZ! format which is backwards compatible
>solution for all existing clients and gives precision to one foot
>for all future APRS applications..
I'm still stuck on the fact that the APRS spec has compressed
posits/objects/items in it, but you're proposing that we add yet another
thing to the protocol.
Please answer one question directly: Do the Kenwoods support the Base-91items.
>
>I simply dont receommend it because it is not FULLY
>implemented and therefor UNUSABLE in a standard
>communications system where the lack of complete
>implementation in ALL end users would mean some
>people see the info and some dont... It is impossible
>to do comunications planning with come-as-you are
>stations without having a standard that is properly
>implemented.
In the SAR world, we're most interested in _receiving_ posits/info from the
roving stations, and in being able to place objects at finely-spaced
positions on the map. If I can send the position of base out to the
mobiles so that the Kenwoods can understand, and send messages to/fro,
that's all I need. As far as the finely-placed objects, if we can have
multiple displays in planning that all show the same info, we're good. We
don't need to send that info to the Kenwoods in the field.
If the Kenwoods can decode compressed objects/items/positions, that would
be a bonus, but it's not critical for our uses.
>>Xastir fully supports Base-91 compressed posits, objects,
>>and items, exactly as specified in the APRS Spec. I can
>>do useful things with those during SAR missions, and
>>cannot do those things at all without the compressed mode.
>
>Yes, you can, but only with the other handful of XASTIR
>users (out of 23,000 total other users)...
Our user-base is growing. We won't always be a handful. Also, see the
specs above for other clients that support partial or full Base-91 uses.
>>Perhaps it is an advantage after all, as I can
>>create compressed objects/items at will and post them on the map,
>>and few others can see them/manipulate them.
>
>Yes, very few... So it does not seem that this is something
>that you would want to force on APRS, and that is known
>incompatibilities?
It's per the spec, what more can I say? Am I forcing it on APRS if it's in
the spec and has been since the spec was ratified?
--
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: Ambiguity?
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Thu, 22 Apr 2004 17:47:16 -0400
X-Message-Number: 47
>>>"KC2MMi" <kc2mmi@verizon.net> 4/22/04 2:58:42 PM >>>
>My question then becomes, if the APRS information is
>going to be plotted, drawn, or marked on a map or
>chart....How does the APRS spec ensure that these two
>different positions will indeed be shown differently?
I have posted at least 4 times the answer to this question in just the last
week. I dont have time to explain it again...
>I see your point [about ambiguity] and the current spec
>apparently leaves all of this as "pilot error" for the user.
No, APRS has recognized the fundamental *requirement* to preserve position
ambiguity from the sender to the receiver since day one (1992) and it has
been in the spec from the day it was drafted. The problem is that
follow-on authors IGNORED it even after I raised the issue and had this
same BATTLE with everyone of them. Many still do not recognize it...
So there is nothing wrong with the spec in this regard. (other than I wish
I was able to strengthen the wording to INSIST that it be implemented by
everyone...)
>I'd probably show a circle with a 1 minute radius, centered
>about that position, preferably gradient shaded fading
>outwards, as a starting point.
That is EXACTLY what APRSdos has been doing since 1995. In addition,
APRSdos randomizes it a bit so that if there are multiple objects or
stations reporting the same measure of ambiguity, then they all appear
slightly offset and can be resolved.
But we could not put it in the spec, because the display technique was
considered UNIQUE to APRSdos and none of the authors even accepted the
concept of AMBIGUITY, much less how to implement it or display it. Whenever
I tell them "how to do it" they rile with "we can do it anyway we want
to"... So I have given up on repeatedly offering advice...
And as you know, nothing could go in the spec unless accepted by all the
new authors at the time. That is why the SPEC is the ***lowest common
denominator*** of the most minimalist implementation at the time. It
clearly did not represent the total functionality of APRS implemented in
APRSdos at the time...
That is why it is so frustrating that so much of what is fundamental to the
original APRS just never gets implemented by some follow-on authors.
That is also why I then prepared my APRS SPEC errata page so that all these
nuances are not lost that were omitted by some others for the sake of
simplicity...
Bob, WB4APR
----------------------------------------------------------------------
Subject: Re: Kenwood MObile APRS
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Thu, 22 Apr 2004 17:51:17 -0400
X-Message-Number: 48
You cant toggle alternating status TEXT in APRS because by definition, any
station can only have one status at a time. Just lke they can only have
one position at a time.....
Bob
>>>"KC2MMi" <kc2mmi@verizon.net> 4/22/04 3:22:40 PM >>>
>>>"KC2MMi" <kc2mmi@verizon.net> 4/21/04 2:09:47 PM >>>
>With APRS now even a TT3 can support sending a status
>string once every ## transmissions. And both a primary
>and secondary configuration, with totally separate parameters.
----------------------------------------------------------------------
Subject: Re: Ambiguity?
From: "Scott Miller" <scott@opentrac.org>
Date: Thu, 22 Apr 2004 14:53:21 -0700
X-Message-Number: 49
>And as you know, nothing could go in the spec unless accepted
>by all the new authors at the time. That is why the SPEC is the
>***lowest common denominator*** of the most minimalist
>implementation at the time. It clearly did not represent the total
So we're fine with Base-91 positions as ratified in the spec, right?
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: Additional thoughts on the great debate....
<LYR36507-195826-2004.04.22-12.06.35--mike
From: "Curt, WE7U" <archer@esko.com/groups/Balloon_Sked . This is a
relatively low-volume list for announcing upcoming flights.
Speaking of which, NSTAR has one scheduled for 1230 UTC this Sunday morning
(25th). See www.nstar.org for more.
73 de Mark N9XTN
----------------------------------------------------------------------
Subject: Re: Additional thoughts on the great debate....
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Thu, 22 Apr 2004 21:11:52 -0400
X-Message-Number: 53
>>>"Scott Miller" <scott@opentrac.org> 4/22/04 5:10:20 PM >>>
>>That... is ... what the "position comment field" was
>>originally intended for ... as a variable length and
>>un-formatted field,... for... adding "additional modifiers"
>
>You're missing my point. We keep adding !xxx!, /A=, and
>whatever other items we've now got to hunt for to figure
>out what is what. I'm saying start with what the Kenwoods
>can understand, and build something consistent.
Too late. /A= and {xx} has been in there since 1995. Looking for these is
trivial. Here is the code in BASIC for finding these additions in the C$
Comment string:
IF INSTR(C$,"/A=") THEN (then go do altitude)
IF INSTR(C$, "{") THEN (then go do a sign post)
IF INSTR(C$, "!") THEN (then go do this new precision thing...
I cant see how it can be any easier...
Sure, if back in 1995 I knew that we would be having this debate, I'm sure
we could have come up with something better. But we didnt...
de WB4APR, Bob
----------------------------------------------------------------------
Subject: Re: Additional thoughts on the great debate....
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Thu, 22 Apr 2004 21:21:22 -0400
X-Message-Number: 54
>>>"Curt, WE7U" <archer@eskimo.com> 4/22/04 5:33:26 PM >>>
On Thu, 22 Apr 2004, Robert Bruninga wrote:
>Please answer one question directly: Do the Kenwoods
>support the Base-91 compression?
Yes and no. They will do compression for STATIONS, but they dont for
OBJECTS. And since OBJECTS is what the SAR folks need to place so
accurately, then those are exactly the ones that will be lost to all
Kenwood users...
>Is there any good reason that we cannot implement full Base-91
>compression across the other clients?
SImply the fact that most of many of them dont. And what's the point. SOme
authors are no longer updating their code and even if you did, then the
4700 Kenwood users would still never see them. That's just guaranteeing
failure....
>Another important compatibility check would be for
>mixed-case object/item names. We need some more
>experiments on that to see how big the problem really is.
Yes, this MUST be fixed.
Bob
----------------------------------------------------------------------
Subject: Re: Additional thoughts on the great debate....
From: "Scott Miller" <scott@3xf.com>
Date: Thu, 22 Apr 2004 19:32:24 -0700
X-Message-Number: 55
>Too late. /A= and {xx} has been in there since 1995.
>Looking for these is trivial. Here is the code in BASIC
>for finding these additions in the C$ Comment string:
IF INSTR(C$,"/A=") THEN (then go do altitude)
IF INSTR(C$, "{") THEN (then go do a sign post)
IF INSTR(C$, "!") THEN (then go do this new precision thing...
Wow, I hope that's not how APRSdos is coded. How many people do you think
have exclamation points in their comments? I'll save you the trouble - at
the moment, 840 are listed in aprsworld. And some have several - enough to
get caught even if you're looking for !???!.
By just randomly overloading characters, not only do things get harder to
parse, but you can't even plan ahead to avoid conflicting with future
additions.
Keep the /A= and { if you want. But if you're going to add another special
value, think BEYOND this one addition. We WILL want to add more stuff
later. So next time it'll be QX=, or maybe &xxx&, or #text#. Why not plan
ahead and make UNIFORM provisions for those?
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: The APRS-WG and spec improvements.
From: Jim Duncan <jdbandman@earthlink.net>
Date: Thu, 22 Apr 2004 21:35:25 -0500
X-Message-Number: 56
Bob:
As I see it, APRS is still a proprietary format that belongs to you. As
long as it remains that way then there will always be the perception that
you are the APRS "dictator" and that there is no way to get anything
changed regardless of the existence (?) of the APRS-Working Group.
I think it is ludicrous to continue to worry about those few users that are
still using outdated computers, GPS's, etc. It's the law of diminishing
returns from where I sit. If you still want to write code for those
machines that is certainly your privilege.
I'm no longer certain that the APRS format can continue to support all of
the things that people want to get APRS to do. Consequently, I would
suggest re-thinking the protocol where the ONLY required elements are the
location/course/speed data and object type and leave the rest of the packet
as "user definable".
By doing so, everyone can still SEE every object plot but it also allows
enough open-ended flexibility to be 100% adaptable to any particular
hardware- or software-specific applications which the end-user or
manufacturer can envision.
So, my solution to the whole thing is this:
===========
APRS 2.0 -- a fixed format definition which specifies a specific format for
the display of any object. This portion of an APRS packet is a maximum of
55 characters, encoded and transmitted in compressed format, which contains
the latitude, longitude, course, speed, direction, altitude, and object
type. The last character of the format (regardless of the character count)
is a tilde (~) which indicates the end of standardized object data. The
remaining characters contained in the packet may be freely modified as
deemed appropriate for the individual software or hardware engineer to
format to satisfy the requirements of the end application.
The packet may be fully compressed at the option of the application
designer provided that the compression format is compatible with the
compression format used in the standardized portion of the APRS packet.
Effective with APRS 2.0, previous formats are no longer supported beyond
the extent of an agreement to maintain the standard APRS format specified
in paragraph 1 to allow "heritage" equipment to continue to decode APRS
formatted packets until December 31, 2005.
============
Folks, as I see it, this is the most serious debate we've seen in APRS
since the Great QSY.... Let's make the best of it and make FORWARD
progress!
--
"Father Marin"
Jim Duncan, KU0G
----------------------------------------------------------------------
Subject: Re: Additional thoughts on the great debate....
From: Curt Mills <archer@eskimo.com>
Date: Thu, 22 Apr 2004 19:45:25 -0700 (PDT)
X-Message-Number: 57
On Thu, 22 Apr 2004, Robert Bruninga wrote:
>>>>"Curt, WE7U" <archer@eskimo.com> 4/22/04 5:33:26 PM >>>
>On Thu, 22 Apr 2004, Robert Bruninga wrote:
>>Please answer one question directly: Do the Kenwoods
>>support the Base-91 compression?
>
>Yes and no. They will do compression for STATIONS, but
>they dont for OBJECTS. And since OBJECTS is what
>the SAR folks need to place so accurately, then
>those are exactly the ones that will be lost to all Kenwood
>users...
I'll update my Client Capabilites list to show that. Good info to have on
there. I refer to it often myself.
>>Is there any good reason that we cannot implement full Base-91
>>compression across the other clients?
>
>SImply the fact that most of many of them dont. And what's
>the point. SOme authors are no longer updating their code
>and even if you did, then the 4700 Kenwood users would
>still never see them. That's just guaranteeing failure....
Over time, the others will go away if they're not updated.
Attrition will solve that problem.
>>Another important compatibility check would be for
>>mixed-case object/item names. We need some more
>>experiments on that to see how big the problem really is.
>
>Yes, this MUST be fixed.
Jim and I will do some more tests between UI-View32 and Xastir I'm sure.
Perhaps some people with a few of the other clients can join us for the
fun.
--
Curt, WE7U. archer at eskimo dot com
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
| |
