| |
ZL3AI > APRDIG 12.05.04 10:06l 254 Lines 9741 Bytes #999 (0) @ WW
BID : 3215-ZL3AI
Read: GUEST
Subj: TAPR Digest, Apr 22, 9/10
Path: DB0FHN<DB0FOR<DB0SIF<DB0EA<DB0RES<ON0AR<ZL2BAU<ZL2BAU<ZL3VML
Sent: 040512/0738Z @:ZL3VML.#80.NZL.OC #:23793 [Chch-NZ] FBB7.00i $:3215-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: Additional thoughts on the great debate....
<LYR36507-195826-2004.04.22-12.06.35--mike
From: "Scott Miller" <scott@opentrac.org>
Date: Thu, 22 Apr 2004 15:13:34 -0700
X-Message-Number: 51
>The intelligent stuff will be at base only, but might be multiple
>copies of same. Perhaps one for OPS, one for Planning, one for
>Mapping, maybe even a separate one for incoming teams to gaze at.
This is something that we're also trying to address in the OpenTRAC spec.
Besides having the ability (someday) to pass real GIS objects between
systems, it can all be done over UDP port 3855 broadcast to the local
network. That way, you'll be able to plug in your laptops (or better yet,
use wifi) with no special configuration. One machine would serve as the
gateway to the local RF network.
Scott
N1VG
----------------------------------------------------------------------
Subject: Balloon schedule e-mail list
From: "Mark Conner" <n9xtn@cox.net>
Date: Thu, 22 Apr 2004 17:29:37 -0500
X-Message-Number: 52
There is currently an e-mail list at Yahoo for scheduled balloon flights -
you can find it at http://groups.yahoo.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
| |
