| |
ZL3AI > APRDIG 08.05.04 23:05l 256 Lines 9186 Bytes #999 (0) @ WW
BID : 3193-ZL3AI
Read: GUEST
Subj: TAPR Digest, Apr 19, 3/5
Path: DB0FHN<DB0RGB<OK0PPL<DB0RES<ON0BEL<7M3TJZ<JL1ZND<JK1ZRW<WB0TAX<KB2TXP<
ZL2BAU<ZL3VML
Sent: 040508/1921Z @:ZL3VML.#80.NZL.OC #:23605 [Chch-NZ] FBB7.00i $:3193-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: APRS version2.0 spec, was Re: APRS greater precision
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Mon, 19 Apr 2004 17:40:35 -0400
X-Message-Number: 15
Thanks Jeff.
I am actually excited if I can get people to buy off on this !XYZ! idea
that both gives us better precision AND includes the DATUM to go with it,
and still lets older stuff decode the original precision... But I fear it
might get burdened down with all other kinds of stuff and again we make no
progress....
----------------------------------------------------------------------
Subject: Re: APRS greater precision
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Mon, 19 Apr 2004 17:53:16 -0400
X-Message-Number: 16
>>>"Scott Miller" <scott@opentrac.org> 4/19/04 4:36:03 PM >>>
>So we're talking about another four or five bytes,
>and more obfuscation of the spec and the parsers
>that have to implement it, for how much of a gain in precision?
To the nearest foot and a half or so. I would think that that resolution
is good enough for SAR unless they are looking for lost jewelry...
>OpenTRAC only takes 10 bytes to indicate position with
>a resolution of 1 cm.
Yes, and if I had it to do all over again, that would be a good approach. I
just worry about obsoleting 10,000 users of the ONLY mobile radio that does
display APRS for a few bytes of advantage and precision to 1cm that is not
of much value to the mobile or SAR operator...
>Backward compatibility is a worthwhile goal, but you've
>got to draw the line somewhere.
Yep, and other than adding a few bytes of precision I still have not seen
the need for crossing that line... yet...
You have borught great creativity to APRS, and I do truely appreciate that.
I sure wish you had been around earlier, because then we would be further
ahead now...
Thanks
Bob
----------------------------------------------------------------------
Subject: Re: APRS greater precision
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Mon, 19 Apr 2004 17:56:46 -0400
X-Message-Number: 17
>>>"Scott Miller" <scott@opentrac.org> 4/19/04 4:45:08 PM >>>
>3) Too many people confuse precision and will use
>it wrongly since precision is useless without knowing
>the DATUM.
>
>So why wasn't it indicated in the spec?
>The easy solution is to do what we did in the OpenTRAC spec
>- it explicitly states that all positions are in WGS84.
Thats exactly what APRS did. But it was in error. I wrongly assumed that
the NMEA data remained in WGS84 even if the viewer selected a different
datum for dissplay. That was a mistake.
I like Roger's suggestion, (since APRS is supposed to be a LOCAL thing) is
to assume the dataum is the LOCAL default unless told otherwise...
People snooping in on the Internet may see errors, but then APRS was not
designed to service the global community... with the accuracy inteended for
local applications.
Bob
----------------------------------------------------------------------
Subject: Re: APRS greater precision
From: "Scott Miller" <scott@opentrac.org>
Date: Mon, 19 Apr 2004 15:12:04 -0700
X-Message-Number: 18
>>The easy solution is to do what we did in the OpenTRAC spec
>>- it explicitly states that all positions are in WGS84.
>
>Thats exactly what APRS did. But it was in error. I wrongly
>assumed that the NMEA data remained in WGS84 even if the
>viewer selected a different datum for dissplay. That was a
>mistake.
I don't think there's an easy answer for this. It's certainly easier to do
datum conversion on the client end if you're dealing with PCs. Including a
datum specifier is going to cost you a couple of bytes, though, and it's not
going to help any for anti-trackers and HamHUDs.
Ideally, everyone would run dedicated GPS receivers for their APRS needs,
and leave them set to WGS84. That's not likely to happen, though. I've got
to deal with the issue myself, since our SAR team uses NAD27 and any
tracking solution I deploy in the near term is likely to use the team eTrex
receivers, which also need to be used manually.
Next time, we need to make sure we get a spherical planet. This irregular
oblate spheroid thing just isn't cutting it.
Scott
N1VG
----------------------------------------------------------------------
Subject: Icom mobile APRS van thing???
From: Earl Needham <needhame1@yucca.net>
Date: Mon, 19 Apr 2004 16:19:53 -0700
X-Message-Number: 19
Anybody remember what that Icom mobile van was called a few years
ago? The one that toured the country giving out door prizes and stuff...
Thanks,
Earl
Earl Needham, KD5XB, Clovis, New Mexico DM84jk
SETI@Home: 11461WU/7.43yrs
http://www.findu.com/cgi-bin/find.cgi?call=kd5xb-2
----------------------------------------------------------------------
Subject: Re: APRS greater precision
From: David VanHorn <dvanhorn@cedar.net>
Date: Mon, 19 Apr 2004 17:28:38 -0500
X-Message-Number: 20
>Next time, we need to make sure we get a spherical planet. This irregular
>oblate spheroid thing just isn't cutting it.
Cubes work..
----------------------------------------------------------------------
Subject: Re: APRS greater precision
From: "Scott Miller" <scott@opentrac.org>
Date: Mon, 19 Apr 2004 15:36:54 -0700
X-Message-Number: 21
>To the nearest foot and a half or so. I would think that
>that resolution is good enough for SAR unless they are
>looking for lost jewelry...
I've talked to a local archaeologist who needs precision down to about 1
cm, but I don't think it's a major issue for most people.
>Yes, and if I had it to do all over again, that would be a
>good approach. I just worry about obsoleting 10,000
>users of the ONLY mobile radio that does display APRS
>for a few bytes of advantage and precision to 1cm that
>is not of much value to the mobile or SAR operator...
I haven't used the Kenwood rigs myself. How well do they deal with the
extra extensions? If they're just displaying everything, it seems to me
that you're still going to impact the usability of the device if you keep
tacking things on. A major focus of the OpenTRAC protocol has been data
tagging, so you know what's what and what you can ignore. User interface is
always going to be difficult on a small device, and providing some meta-data
gives you a little more flexibility in how you present the information.
I understand why APRS is the way it is. I probably would have made many of
the same design decisions myself a dozen years ago, without the benefit of
hindsight. I'm not advocating an immediate switch, I just want to develop
an alternative and spend some time getting things 'right' as much as
possible.
There's a lot of cool stuff that could be done with a pervasive UI-frame
network that's just not going to fit well in the existing APRS schema. I
really want to pursue the auto-programming ideas some more - being able to
have radios learn local repeaters, BBSes, and so on automatically, having
flags to trigger icons on the radio display like 'net in progress',
'emergency use only', 'on backup power', 'autopatch available', 'IRLP
enabled', and so on. Pull into town and your radio beeps and pops up with a
new channel labelled 'Hamfest talk-in', or 'Disaster health and welfare
net', or whatever.
Certainly there's still stuff that can be done to make APRS better. But in
maintaining backward compatibility, we're going to reach a point of
diminishing returns when you consider the added utility vs. the continued
convolution of the standard.
>Yep, and other than adding a few bytes of precision
>I still have not seen the need for crossing that line...
>yet...
I should probably take a break from programming and do some powerpoint
slides on what I see the whole thing eventually doing. See above for
starters, though.
>You have borught great creativity to APRS, and I do
>truely appreciate that. I sure wish you had been around
>earlier, because then we would be further ahead now...
Thanks. Just trying to make up for lost time, now. Though at the moment,
the hurrier I go, the behinder I get.
SAR training yesterday, SAR meeting tonight, GP-B launch tomorrow morning,
EMT recert tomorrow night, firmware revisions to write, spec document
corrections to make, and so on. Got a new 'scope and logic analyzer coming
in today and I don't even know when I'll get to play with the new toys.
What a hobby. =]
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: APRS greater precision
From: "Spider" <spider@rivcom.net>
Date: Mon, 19 Apr 2004 15:48:40 -0700
X-Message-Number: 22
----- Original Message -----
From: "Robert Bruninga" <bruninga@usna.edu>
To: "TAPR APRS Special Interest Group" <aprssig@lists.tapr.org>
Cc: <aprssig@lists.tapr.org>
Sent: Monday, April 19, 2004 1:04 PM
Subject: [aprssig] Re: APRS greater precision
>>>>Jeff King <jeff@aerodata.net> 4/19/04 3:25:57 PM >>>
>
>>Every APRS GUI application on the market today,
>>will display Base91 compressed posits?
Well, which ones do and which ones don't?
Will:
UI-View32
Xastir
Won't:
Hamhud
Kenwood
Who else?
Jim, WA6OFT
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
