| |
ZL3AI > APRDIG 12.05.04 09:55l 256 Lines 9463 Bytes #999 (0) @ WW
BID : 3213-ZL3AI
Read: GUEST
Subj: TAPR Digest, Apr 22, 7/10
Path: DB0FHN<DB0FOR<DB0SIF<DB0EA<DB0RES<ON0AR<ZL2BAU<ZL2BAU<ZL3VML
Sent: 040512/0738Z @:ZL3VML.#80.NZL.OC #:23791 [Chch-NZ] FBB7.00i $:3213-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: "Robert Bruninga" <bruninga@usna.edu>
Date: Thu, 22 Apr 2004 16:06:18 -0400
X-Message-Number: 37
>>>"Michael J. Pawlowsky" <mikep@mikeathome.net> 4/22/04 12:42:52 PM
>>>
>I don't have the APRS spec fresh in my head...
>But why not simply have another format type.
Because the thousands of mobile APRS users (70% of all mobiles) with
Kenwoods and HAMhuds would never see the new data. It seems un-wise to do
communications planning when you instantly obsolete the majority of your
volunteers...
>If you are part of a select group of individuals that use
>all the same equipment etc. you can all decide to use
>the new format.
Exactly and the APRS spec allows for exactly that.
But again, unless you are truely a closed group this falls apart quickly
in an all volunteer situation...
>New software coming out should be able to recognize
>which format is used and handle either one of them.
Yep, thats what my !XYZ! format is all about. All existing mobiles will
still see the object to their existing precision to at least know that it
exists and those new softwares can also then plot it to the nearest foot...
AND know the correct DATUM to use...
Bob, WB4APR
----------------------------------------------------------------------
Subject: Re: Pocket Tracker Question for the group
From: Jeff King <jeff@aerodata.net>
Date: Thu, 22 Apr 2004 16:12:20 -0400
X-Message-Number: 38
Hi Allan:
Mine just got shipped yesterday, so I'll need to speak from reading the
data sheets.
It appears to me, looking at the schematic, the PTT controlls the PMOS part
Q2 on the right hand side. This in turn puts the voltage on the
microcontroller (12F6529) and PLL chip. Once the Micro comes up, and loads
the registers of the PLL chip, the PLL chip reports back to the micro (or
it waits a certain amount of time for the register to load) and then it
enables the final TX chain via Q3.
--
Jeff King, jeff@aerodata.net on 4/22/2004
----------------------------------------------------------------------
Subject: Re: APRS greater precision
From: Jeff King <jeff@aerodata.net>
Date: Thu, 22 Apr 2004 16:12:25 -0400
X-Message-Number: 39
On Thu, 22 Apr 2004 12:49:40 -0700 (PDT), Curt, WE7U wrote:
>On Thu, 22 Apr 2004, Robert Bruninga wrote:
>
>>>>>"KC2MMi" <kc2mmi@verizon.net> 4/22/04 11:39:25 AM >>>
>>>Look on the bright side: A radio like the THD7 is already
>>>obsolete, it DOES NOT support the existing APRS capabilities.
>>
>>Interesting comment from someone who doesnt own one. And by that
>>kind of tight definition, anything that leaves the factory is
>>instantly obsolete the day the first one comes off the assembly
>>line.
>>
>>sigh...
>
>Anything with fixed-firmware is pretty close to that, unfortunately.
Doesn't matter. The APRS-WG certification program is very clear on this
issue:
"Certification holders will be expected to keep the Product in compliance
with the protocol – both through protocol changes, and product changes."
(from page 6 of the APRS-WG charter and bylaws),
ftp://ftp.tapr.org/aprssig/aprsspec/announcements/APRSWG_charter.pdf
So the product being discussed will never be able to attain "APRS
certification" if the bylaws are properly followed.
That document (the charter) is actually fairly well written and might be a
good basis for any follow-up efforts.
----------------------------------------------------------------------
Subject: Re: Additional thoughts on the great debate....
From: Jeff King <jeff@aerodata.net>
Date: Thu, 22 Apr 2004 16:12:57 -0400
X-Message-Number: 40
>>>>"Curt, WE7U" <archer@eskimo.com> 4/22/04 11:47:27 AM >>>
>>Precision: Bob has changed his mind with respect to promoting
>>Base-91 Compressed posits (which are in the ratified spec), so that
>>only leaves us NMEA posits with more digits after the decimal point
>>to support higher precision,
....
>>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?
WOW Curt. Your forcing the ratified spec on APRS! The horror!
----------------------------------------------------------------------
Subject: Pocket Tracker Question for the group
From: "Sadowski, Allan" <allan.sadowski@ncshp.org>
Date: Thu, 22 Apr 2004 16:16:57 -0400
X-Message-Number: 41
Yet again... Thanks Jeff
Interesting way to do it. Keeps the power to a trickle...
ALOHA
AH6LS
----------------------------------------------------------------------
Subject: Re: Additional thoughts on the great debate....
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Thu, 22 Apr 2004 16:18:10 -0400
X-Message-Number: 42
>>>"Scott Miller" <scott@opentrac.org> 4/22/04 1:01:33 PM >>>
>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.
That, sir, is exactly what the "position comment field" was originally
intended for back 12 years ago. In that variable length and un-formatted
field, which applies to all positions and objects is exactly where ANYTHING
new was to be placed that was needed to add "additional modifiers" to the
original format which we KNEW would need such modifiers.
Since it was invented, there have been additions, such as altitude, text on
signposts, and now added precision. The neat thing about the variable
length comment field is that it is NOT pre-formatted such that EVERY
position report has to carry empty baggage. You only add the added
"comment info" if it is needed. Thus. only the HANG GLIDER users (for
example) need to add altitude. And in this case of precise objects, only
those needing precision need to add it.
Just as originally intended, sir, the comment field is exactly the intended
extensible field for such modifications. And adding the !XYZ! flag to
provide that is in keeping with that kind of extensible language...
de WB4APR, Bob
----------------------------------------------------------------------
Subject: Re: Additional thoughts on the great debate....
From: "Scott Miller" <scott@opentrac.org>
Date: Thu, 22 Apr 2004 14:10:20 -0700
X-Message-Number: 43
>That, sir, is exactly what the "position comment field" was
>originally intended for back 12 years ago. In that variable
>length and un-formatted field, which applies to all positions
>and objects is exactly where ANYTHING new
>was to be placed that was needed to add "additional
>modifiers" to the original format which we KNEW would
>need such 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.
Maybe |x to separate fields, where | is the delimiter and x is the field
identifier. For example:
>Comment |a3500|dW|tg(
And I've got altitude (3500 meters), datum (WGS84), and thousandths (base 91
encoded ). It's still ugly and kludgy, but now it's a consistent and
extensible kludge.
Or make it all Base 91. Set aside a couple of bytes to give us a 12 bit
bitmap indicating what fixed-length fields follow, and then pack those
fields in the following Base 91 encoded bytes.
It's still going to be nasty looking text that the Kenwoods just show with
the comment, but we're going to get that anyway. Let's do the most we can
within those constraints.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: Additional thoughts on the great debate
From: Steve Jones <s.jones@rogers.com>
Date: Thu, 22 Apr 2004 17:15:55 -0400
X-Message-Number: 44
on 4/22/04 4:06 PM, Robert Bruninga at bruninga@usna.edu wrote:
>Because the thousands of mobile APRS users
>(70% of all mobiles) with Kenwoods and HAMhuds
>would never see the new data.
Kind of curious as to why you lump the Hamhud in with the Kenwood products?
I've upgraded my hamhud several times to fix bugs and add features.
I'd venture a guess that the hamhud could easily be upgraded to accommodate
new data formats. The last message on the hamhud group indicated that only
50% of the program flash had been used. Still lots of room left.
--
Steve <s.jones@rogers.com>
----------------------------------------------------------------------
Subject: Re: compatibility question
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Thu, 22 Apr 2004 17:15:31 -0400
X-Message-Number: 45
>>Heck even DOS APRS is to the point that if anything new
>>is to be added, something must be taken away...
>
>That is only because Bob wants it to fit on a single floppy.
>I, personally, don't see that as a valid requirement any longer.
That choice has nothing to do with the protocol and is not a llimit in any
way on that protocol. There have been several inferences to the
"limitations" of dos as being a limit to the protocol. Those viewpoints
are simply uninformed. There is nothing in the spec that is tied to DOS.
de WB4APR, Bob
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
