| |
ZL3AI > APRDIG 10.05.04 19:44l 251 Lines 9648 Bytes #999 (0) @ WW
BID : 3204-ZL3AI
Read: GUEST
Subj: TAPR Digest, Apr 21, 8/10
Path: DB0FHN<DB0FOR<DB0SIF<DB0EA<DB0ACC<DB0GOS<ON0AR<ON0AR<WB0TAX<ZL2TZE<
ZL3VML
Sent: 040510/1814Z @:ZL3VML.#80.NZL.OC #:23734 [Chch-NZ] FBB7.00i $:3204-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Introduction
From: "Michael J. Pawlowsky" <mikejp@videotron.ca>
Date: Wed, 21 Apr 2004 19:21:33 -0400
X-Message-Number: 37
I might as well introduce myself, might change the tone for a little while.
I've been interested in APRS mostly for simple vehicle positioning for
about 2-3 years now. My wife likes the fact that she can keep tabs on me! ;-)
I've also use APRS on amateur UAVs to track the vehicles while they are in
flight for the past year or two.
I'm now starting to use APRS for weather. Basically reporting the weather
from a remote solar powered weather station that is kept in a field where I
fly the UAV.
More recently I've been developping a type of ground tracking station for
amateur UAVs. I added APRS support to it as a easy way to start using the
ground station. Basically you could add a TT3 and a TX to the plane and
recieve some telemetry and positioning. It is not an optimal solution since
the refresh rate of APRS is not really adequate for meaningful telemetry
readings (i.e. decent rate) but it's simple and inexpensive. I will add
here that I beacon on 2,4Ghz and not the usual 144.39 as to not get tons of
people mad at me!
Lastly, one of the reasons I joined this list was to try and find out who
takes care of maintaining AX.25. I was told that it lies in the hands of
the same people as APRS. Is this the case?
Basically I have written (with the help of a couple of people) an RFC to
add a new frame type to AX.25 that would be called the "Private Unumbered
Information Frame". Basically it removes the addresses and a few other bits
that reduce the size of the frame to allow for a quicker on air refresh
rate.
It looks like:
Flag Control Info FCS Flag
01111110 8 Bits N*8 Bits 16 Bits 01111110
The only problem that I have now is that I'm not sure of the appropriate
forum to submit the RFC.
Would this be the place?
If not can anyone tell me where?
Thanks,
Mike
----------------------------------------------------------------------
Subject: Re: Introduction
From: "Scott Miller" <scott@opentrac.org>
Date: Wed, 21 Apr 2004 16:32:18 -0700
X-Message-Number: 38
I don't know that there's much benefit in calling it AX.25, since it's more
HDLC with a control byte. A lightweight frame would certainly be useful,
though. OpenTRAC for example can handle radio ID'ing on its own and can
save bandwidth by not having to ID every frame.
One suggestion - consider making the FCS the 1's complement of the standard
AX.25 FCS (CRC-CCITT). This would ensure that the frame would never be
mistaken for a valid AX.25 frame by an older device. Otherwise it'd always
have a valid FCS and could cause problems for protocol stacks trying to
parse out the address and control fields.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: [ui-view] Ambiguity?
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Wed, 21 Apr 2004 19:54:48 -0400
X-Message-Number: 39
>>>"Scott Miller" <scott@opentrac.org> 4/21/04 6:54:35 PM >>>
>Ok, I'm not even debating this anymore.
>The system is flawed. Let's say I know I'm about midway
>between 34 and 35 degrees North.
Then of course you enter 34.5 . that is about as close to half as you are
implying.
>If I say 34_ or 35_, that implies an entire degree of ambiguity,
>centered half a degree from my estimated position.
Yes, so don't use that degree of inprecision since clearly as you have
stated, you know it better than that.
>If I say I'm at 34 3_, that implies I know where I am
>within 1/6 degree, which isn't true.
Why is it not true? You already said you are about half way. and 30
minutes plus or minus 10 minutes surely seems to me to be the better
indication of about HALF of 60 than anything else...
And it is surely a LOT BETTER than sending 3430.00 which is what SOME
software does... Placing you EXACTLY to the nearest 60 feet when you
actually arent that sure...
You are not making sense. Either you are about half or you are not. If
you ar about half, then 30 out of 60 seems about right...to the nearest 10.
If you are somewhat less than about half, then 20 seems like a reasonable
fraction of 60. Or if you feel you are somewhat more than half, the 40 out
of 60 would seem about right.
So if you have digits, use them. But if you dont know what a digit should
be, DONT put 0. Put a SPACE character which in APRS means, I DONT KNOW
THIS DIGIT.
And that is what APRS ambiguity is all about. It means DELIVERING to the
receipient what the SENDER intended. If he doesnt know the digit, then it
does not exist. It is NOT ZERO!!!
Bob
----------------------------------------------------------------------
Subject: Re: [ui-view] Ambiguity?
From: "J. Lance Cotton" <joe@lightningflash.net>
Date: Wed, 21 Apr 2004 19:02:07 -0500
X-Message-Number: 40
Robert Bruninga wrote:
>>Are you saying then that ... when an APRS user uses
>>position ambiguity by not entering all of the digits in
>>the coordinate fields, the displaying program should
>>assume that those "digits that aren't there" are zeros
>
>**** Absollutely not. That is the whole point. If the sender
Excellent. This is the right answer here.
>>If not: why would you use a circle to indicate the
>
>Why not use a circle? When the circle is defined
>to mean: "this position is not known to a position
>any more accurate than the approximate radius
>of this circle".
When you use a circle you are decreasing the amount of information shown to
the user because the APRS method of indicating position ambiguity does not
inherently provide a radius from which to produce a circle. If, however,
the circle does not indicate a particular degree of ambiguity but simply
that there exists ambiguity, then doesn't a rectangle representing the
whole gamut of where a reporter REALLY IS (they must exist somewhere; if
they exist over a large area, then an area object would be preferred to
using position ambiguity) provide more information to the viewer of the
APRS screen?
Simplicity is nice, but using a circle instead of a rectangle doesn't
simplify the interface, it removes information.
>Whoaa!
>But why not?!! That is exactly why APRS has the ambiguity
>format. To CLEARLY and UNAMBIGUOUSLY transmit
>this LACK of digis from the SENDER to the RECEIVER.
>Problem is so many of the follow-on-authors just ignored
>this critical basis of APRS...
And a rectangle clearly an unambiguously indicates to the viewer that there
is a lack of digits and over what range all possible values of the TRUE
LOCATION could be.
>>That means a rectangle would best define the
>>area in which such a reporter (who is being ambiguous)
>>REALLY is.
>
>No, a rectangle with straight sides and precise corners
>is not a good display of ambiguity in my opinion because
>such a geometric shape implies a PRECISE ambiguity
>and that is an oxymoron.
If you want to indicate IMPRECISE ambiguity then some error factor should be
transmitted. A real error factor, not just a lack of digits. Also, isn't a
circle a precise geometric shape? Would it be better to indicate position
ambiguity by drawing a little cloud around the symbol whose shape varies all
the time to indicate that the position shown is not precise?
>>Your own APRS text file ... says... thats what... you do
>>when a position report uses gridsquares rather than
>>lat/long. Why would it be any different for "digits
>>that aren't there" in a lat/long?
>
>SImple. Grid Sqaures are *precisely defined".
>If you are 30 feet into one and wrongly
>report it, then that is not good practice...
If sending fewer digits is the APRS way of indicating an imprecise position
in such a different conceptual way than grid squares, then I think it is
flawed.
In the end this is all about how to indicate to the viewer that a position
shown may not (and probably is not) where the symbol is drawn. My opinion
is that the argument that a circle is a less precise-looking indicator of
unknown data than a rectangle is not a valid argument.
If you allow the reporter to define how imprecisely they know their own
position, but do not pass that same information on to the viewer, what good
is it?
In the grand scheme of things, who uses position ambiguity anyway? What
percentage of folks out there use it? Probably less than should, given that
many people trust either GPSs or their ability to locate themselves on a
map too much for what they're (the gps or map, not the person!) worth.
-Lance KJ5O
--
J. Lance Cotton, KJ5O
joe@lightningflash.net
http://map.findu.com/kj5o-14
Three Step Plan: 1. Take over the world. 2. Get a lot of cookies. 3. Eat the
cookies.
----------------------------------------------------------------------
Subject: Re: [ui-view] Ambiguity?
From: "Scott Miller" <scott@3xf.com>
Date: Wed, 21 Apr 2004 17:20:29 -0700
X-Message-Number: 41
>If you want to indicate IMPRECISE ambiguity then some error factor should be
>transmitted. A real error factor, not just a lack of digits. Also, isn't a
>circle a precise geometric shape? Would it be better to indicate position
>ambiguity by drawing a little cloud around the symbol whose shape varies all
>the time to indicate that the position shown is not precise?
My thoughts exactly, since the error presented by the current scheme isn't
appropriately a circle at those coordinates. What you want is more of a
probability cloud.
Reminds my of some physics graffiti I once saw:
"Heisenberg might have been here."
Scott
N1VG
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
