[aprssig] Re: The best resolution of position from APRS

[KC2MMi]

Bob-
 I asked:
>How is a D7 going to decode what NMEA format to give
>6" position rsolution, when the display physically is only
>doing DDD.MM.mm due to the available display digits?

And you replied:
<It is going to display it the same way it always has.
<Whereas it wont display ANYTHING if someone uses
<the high precision obsolete compressed object format.

Which makes me think you didn't understand the question. The D7 has a physical
limit to the number of characters it can use to display a position. That is, in
conventional form, expressed as DDD.MM.mm meaning three digits of degrees, two
digits of minutes, and two more digits of decimal minutes.  The D7 is physically
incapable of displaying more than seven digits, and AFAIK the display can only
display them as DDD.MM.mm it can't even change that to the alternative
convention of DDD.dddd which would be three digis of degrees, followed by four
decimal points of fractional degrees, which is less conventional but actually
more granular. In fact, on reading the extended manual, that seems to state
pretty expressly that the D7 only reads GPS strings that are formatted as
DDD.MM.mm, so that the D7 can't accept GPS information with any greater
granularity (MM.mmm) in any case. I wasn't aware of that, but pages 90/91 of my
manual say it only reads $GPRMC and $GPGGA for location, in the format of
"LLLL.LL" i.e., DD.MM.mm. Which makes sense, to match the Mic-E limitations of
the D7.

But you say:
<Which would you rather have?
<a) Nothing ...b) at least as good as you always had?
<That is the debate.

And again, you are missing my question. If you change to position to ANYTHING
except the DDD.MM.mmm format, the D7 would appear incapable of displaying it.
Your very personal and apparently unique convention of DDD.MM.HH is not used by
anyone, anywhere, else that Google can find, and I've never seen it referenced
in navigation. On reading the sole explanation of your format--on your web
page--there's no real explanation of what you mean by .HH and there's no reason
to expect it to mean hundredths of a minute, since there already is the existing
convention of MM.mm to indicate minutes and hundredths.

So I ask you again, what do you mean by this? Do you mean that DDD.MM.HH is a
position *concatenated* by new software, where the DDD.MM portion and the .HH
portion are to be sent separately in the new APRS format? So that older software
(like the D7's) would only display DDD.MM and never pick up the *normal* ".mm"
portion?

I'm sorry, but what your forays into a new and unexplained "HH" format are
confusing the issue for me.

You say:
>Now, you say, but you want the precision down to
>6" on your D7?  What on earth are you going to do
>with it?

I never said that I wanted 6" precision. I'm not surveying. What I do want is
the normal precision (or rather, granularity) displayed by a normal consumer
grade GPS or even a LORAN-C, in DDD.MM.mmm form or equivalent. Right now, in my
limited experience, I don't see any way, using any of your APRS conventions,
that a D7 can display a location other than DDD.MM.mmm which translates into a
nominal 60-foot position circle. Not six inches.

Now, since my GPS often hits a 25' position circle, and my WAAS-GPS often
tightens that to well under 20', why shouldn't I want APRS to do better than a
circle roughly three times the radius of the real data I'm using?! Not six
inches, but six meters.

See, now here's how you confuse me, and I certainly HOPE everyone else:
<DD is degrees.  MM is minutes and HH is hundredths of
<a minute.
 That's unique to you. The rest of the world says DDD.MM.mm to say that. Every
nav program, eery GPS document, every other source I have found. None use ".HH"
for this purpose, as best I can find.

<You are not understanding it.
Right. That's what I said, and why I asked for clarification.

You say:
<1) When XASTIR sends a compressed object NO ONE USING
<A KENWOOD WILL SEE IT.  That is the problem.
And that's exactly what I understand. The D7 is limited to APRS-MicE for
displays, isn't it? Since there are some software programs that apparently also
have the DDD.MM.mm limitation in them...I'm not certain if, or how, anyone can
extort that MM.mmm information out of a D7 regardless of how it is being sent.
Would you mind explaining this, that is, what you think a D7 can display
internally, and externally (to what software), when what APRS standard is sent
to it? Talking about DDD.MM.HH means nothing here, because that's just DDD.MM.mm
which is the normal default display--good only to 60'. (One hundredth of one
minute, one minute nominally being one nautical mile, one nautical mile
nominally being 6000 feet, so one hundreth of one minute is nominally 60 feet if
my numbers are right?)

<<2) But, When anyone who must have 1 foot resolution for
objects sends the new APRS 1.2 !DAO! format, everyone
including all kenwoods and any old software they may have
lying around WILL SEE the object the same way they always
have. >>
 See now, here's where you confuse me again. You're suggesting the !DAO! format
is going to work some magic with that DD.MM.HH format...and we've yet to
establish why or how that differs from the DDD.MM.mm format. It *sounds* like
you mean to say that the new format will provide extra information, which the
old softwares will throw out as junk, and new softwares (or humans) can use TO
REPLACE the decimal minute information. And if that's so, then just adding
hundredths won't help. If you want to extend DDD.MM.mmm (the norm that D7's
can't display anyway) with more precision, that would be DDD.MM.mmmm or .mmmmm
in a conventional expression.

Is that what you're trying to do? Send the normal position, then add a "package
of extra decimal digits" that are most definitely not "hundredths" in any
conventional sense? Which would simply be truncated as junk by the older
software?