OpenBCM V1.07b12 (Linux)

Packet Radio Mailbox

DB0FHN

[JN59NK Nuernberg]

 Login: GUEST





  
ZL3AI  > APRDIG   10.05.04 08:25l 230 Lines 9192 Bytes #999 (0) @ WW
BID : 3183-ZL3AI
Read: GUEST
Subj: TAPR Digest, Apr 20, 12/17
Path: DB0FHN<DB0FOR<DB0MRW<DB0SON<DB0SIF<DB0EA<DB0RES<ON0AR<7M3TJZ<JK1ZRW<
      WB0TAX<ZL2TZE<ZL3VML
Sent: 040510/0647Z @:ZL3VML.#80.NZL.OC #:23701 [Chch-NZ] FBB7.00i $:3183-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To  : APRDIG@WW

Subject: Re: APRS greater precision
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Tue, 20 Apr 2004 16:56:44 -0400
X-Message-Number: 65

APRS is nice for voyers on the Internet, but its fundamental purpose must
remain to serve the LOCAL users first. Now that APRS has gone global, I do
support the concept that local DATUM overrides the WGS84 default for local
use.  In the USA, let the default remain WGS84.  In the UK let it be
OSGB-36.  Are there any other areas that want to declare a country wide
default?  If so, Ill add them to the SPEC errata page...  de WB4APR, Bob

----------------------------------------------------------------------

Subject: Re: APRS greater precision
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Tue, 20 Apr 2004 17:10:31 -0400
X-Message-Number: 66

>Note that even in the proposal from Bob the ASCII 
>doesn't have to be human readable,... So the only 
>reason for using ASCII it to be able to run TNC's in 
>converse mode (instead of KISS).

No, I also would probably define it so that  !X34! would mean the next
digit of precision is 3 in Latitude and 4 in longitude.  That would get the
position to 6 feet and BE READABLE and USABLE on even a handheld Kenwood if
needed. 

Bob

----------------------------------------------------------------------

Subject: Lynching plans...
From: Steve Dimse <k4hg@tapr.org>
Date: Tue, 20 Apr 2004 17:12:57 -0400
X-Message-Number: 67

On 4/20/04 at 4:42 PM Robert Bruninga <bruninga@usna.edu> sent:

>If Kenwood users want to protect their investment
>in a radio that can display just about ANYTHING they
>need to know while moble they better speak up, or the
>XASTIR and OPEN_TRACK people plan on obsoleting
>them as soon as they can...

Can you give us their addresses so we can form a mob and lynch them? I'll
bring the torches. Or maybe we could just scare them by burning globes into
their lawns!

Geez Bob, while I agree 100% with your premise, I think you are a little
far out on the limb trying to rouse the rabble.

There is nothing wrong with what these people are doing. My personal
opinion is it will go nowhere, for the very reasons you and I argue against
these things when people try to incorporate them into APRS, namely that the
changes are of marginal benefit to 95% of APRS users, and this does not
justify the effort required to upgrade the entire system.

Even though it does not belong in APRS, there is nothing wrong with letting
them try to build their own system. If we are right, their efforts will not
attract a significant following, if they are right, it will be because
their product is better than APRS. Either way, amateur radio wins...

I do think that it is wrong to refer to any project as "APRS 2.0" as I have
heard some people do. APRS is a registered trademark owned by Bob, and that
legal right must be respected by everyone.  I also think it is encombant on
anyone working on a new system to avoid disruptions of the working APRS
system. Other than that, I wish the best of luck to those that would try.

Steve K4HG

----------------------------------------------------------------------

Subject: Re: APRS Kenwood Radios
From: "Scott Miller" <scott@opentrac.org>
Date: Tue, 20 Apr 2004 14:15:14 -0700
X-Message-Number: 68

Ok, let's back up a bit.  I'm not saying anyone should ditch their
TM-D700's.  By all accounts, they're great mobile rigs and they do a lot of
cool stuff.

On the other hand, I'm not going to limit development of new capabilities to
what can be done with that one radio.  If someone else wants to shoehorn
everything into that platform, go for it.  You can turn all of APRS into the
Kenwood Content Delivery Network.  Whatever.

But we can't count on commercial vendors to innovate in this area.  And they
certainly aren't going to be interested in innovating if all we do is use
what they've already given us - there's no incentive to improve things.  For
the record, I don't EXPECT users to be anything but appliance operators - I
design my stuff around that assumption.  BUT, I also make provisions for
those who want to tinker, experiment, and extend.  THIS is what's missing
from most commercial offerings.

I'm not advocating integration of OpenTRAC with the APRS spec.  I'd rather
keep it separate, use the lessons learned in APRS, and work on making it as
good as it can be.  Think of it more like the Internet2 project.  It's not
replacing the original, but it's shaping what we're going to see in the
future.

Back on the subject of new APRS formats for a minute.  If you're going to
introduce any new format and push for wide adoption, whether it's Kenwood
compatible or not, PLEASE consider some sort of tagged format where we can
extend it in a consistent manner in the future.  That is the #1 advantage
OpenTRAC has over APRS.  All data elements are tagged, and a radio shipped
knowing how to display only position and comment elements will still be able
to display them years later when everyone's sending who-knows-what
information in their packets.

Scott
N1VG

----------------------------------------------------------------------

Subject: Re: APRS Kenwood Radios
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Tue, 20 Apr 2004 17:24:02 -0400
X-Message-Number: 69

>>>"Scott Miller" <scott@opentrac.org> 4/20/04 5:15:14 PM >>>
>Back on the subject of new APRS formats for a minute.  
>If you're going to introduce any new format and push for wide 
>adoption, PLEASE consider some sort of tagged format..

That is what the !xyz! format was intended to be.  If  you see the two "!"
bytes, then that is a tag that indicates it contains the datum and
additional precision...

Bob

----------------------------------------------------------------------

Subject: Re: [ui-view] Ambiguity?
From: "Curt, WE7U" <archer@eskimo.com>
Date: Tue, 20 Apr 2004 14:27:04 -0700 (PDT)
X-Message-Number: 70

On Tue, 20 Apr 2004, Robert Bruninga wrote:

>>>>"Curt, WE7U" <archer@eskimo.com> 4/20/04 12:10:55 PM >>>
>On Sun, 18 Apr 2004, Robert Bruninga wrote:
>Agree.  But in once sense the Circle (or rectangle) implies TOO
>muck knowledge.  The purpose of the circle or rectangle is to
>SIGNAL the viewer to not trust the symbol location.  It was not
>intended as a specific indicator of precise ambiguity...
>
>Bob
> In that
>interpretation then circle, square rectangle, anything does the
>job...

Well, you'd _think_ so, but in reality you're just chopping off
significant digits from a lat/long location, so the net result is
that you are somewhere within the described rectangle.

As the GPS crosses that rectangle boundary, it jumps to a new
rectangle until you cross the next boundary.  I realize that's not
what you intended when you put ambiguity into the spec, but that's
the net result you get by chopping off digits.

--
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: [ui-view] Ambiguity?
From: "Curt, WE7U" <archer@eskimo.com>
Date: Tue, 20 Apr 2004 14:30:10 -0700 (PDT)
X-Message-Number: 71

On Tue, 20 Apr 2004, Robert Bruninga wrote:

>The use of a circle or rectangle or anything else to
>indicate an ambiguous position was not intended to
>be a "precise" indication of "ambiguity".  It is only
>intended to "SIGNAL" the user not to trust the
>position below the ambiguity indicated.
>
>So using a square or a rectangel or a circle is OK with
>me.  Trying to claim it as a precise measur of ambiguity
>I find counterproductive and missleading...

I see chopping off significant digits from a position as a way to represent
position ambiguity to be misleading.

What we need instead is a normal position report plus a new parameter which
specifies the ambiguity.  That makes more sense mathematically, as it can
them be represented as a circle around the position.

--
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: APRS Kenwood Radios
From: "Scott Miller" <scott@opentrac.org>
Date: Tue, 20 Apr 2004 14:31:26 -0700
X-Message-Number: 72

>That is what the !xyz! format was intended to be.  If  you see the two
>"!"
>bytes, then that is a tag that indicates it contains
>the datum and additional precision...

By a tagged format, I mean look at all the other bits of information we keep
wanting to squeeze into the comment field and extensions, and figure out a
consistent way to put it all in there so it's easy and unambiguous to parse.
You ought to be able to express the whole thing in BNF notation so there's
no question of which part means what.

Scott
N1VG

----------------------------------------------------------------------




Read previous mail | Read next mail


 26.11.2025 04:11:32lGo back Go up