[Xastir-dev] Position accuracy

[Jack Twilley]

WARNING: Unsanitized content follows.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>>>>> "Gerry" == Gerry Creager <N5JXS <gerry.creager at tamu.edu>> writes:

Gerry> I've read this twice and my brain now hurts...  Generally, one
Gerry> works in milliseconds for the OnCore, but that's not burned in
Gerry> stone. Conversions are conversions.  Mind the rounding error.

Generally.  SynTac is outputting numbers like this:

38.0124733 -122.1346611

Now, it's quite possible that the decimal representation of whatever
the Oncore's using internally is whacked.  I'm ignoring that
possibility because I don't see how to answer that question.

Gerry> Are you asking what unit to work in?  I'd do it in
Gerry> milliseconds.  Or more precisely, I'd end up transforming to a
Gerry> cartesian system and working meters.  And then back.

This is what the xastir configuration file uses:

STATION_LAT:3800.749N
STATION_LONG:12208.024W

This is also what the configure window uses, although the configure
window is slightly prettier.

This is *not* what xastir uses internally for maps and the like.

The point of my post is that we're using different units at different
times and that it might be easier and nicer to use the same units at
all times if at all possible.

Gerry> For the sake of accuracy, make sure the following are
Gerry> happening...

Gerry> 1.  Datum should be set to WGS84.  I don't care what map you're
Gerry> using now, that reduces the chances of rounding error on the
Gerry> OnCore.

I haven't changed the datum, I've left it at the default.

Gerry> 2.  I'd be collecting a position no more frequently than ever
Gerry> 15 sec. and more likely, I'd do so every 30 sec.  Don't bother
Gerry> collecting it every second.  You will add more noise to the
Gerry> equation than you need. GPS data are strongly autocorrelated in
Gerry> the time domain anyway.  Any decoupling you can do helps the
Gerry> statistics.

I'm using SynTac, the software that came with the M12, to perform the
site survey.  ntpd does it the way you describe it should be done, but
ntpd won't do it for the M12 for a reason which isn't clear to me.

Gerry> 3.  Make sure no data are collected unless HDOP is less than 4,
Gerry> and preferentially, GDOP is less than 4.  Using PDOP is also
Gerry> acceptable.

Mmm.  I've been unable to examine or change these settings.

Gerry> 4.  I'd want some multiple of 1024 samples for the average.
Gerry> This should help smooth some of the noise out as you're looking
Gerry> at the chipping rate for L1 C/A code at that point.

The software recommends setting the sample average to 86400.

Gerry> "Surveys" done with a single code-phase receiver with nothing
Gerry> sitting simultanelously on _NEARBY_ geodetic control to act as
Gerry> a QC mechanism are frought with peril, and performed
Gerry> daily... often by folks who are not pessimistic enough.

That's all well and good for those who can afford a Leica AT-504 and
the like, but for the rest of us, this is the best we can do.

I'm aware that I won't get a rock-solid location of my GPS antenna
down to the meter with 100% reliability.  I would like to get the best
possible position, because that combined with DGPS should permit me to
create a pretty darned accurate time source.

Gerry> 73, gerry

Jack.
- -- 
Jack Twilley
jmt at twilley dot org
http colon slash slash www dot twilley dot org slash tilde jmt slash
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQE/0n3iGPFSfAB/ezgRAl6tAJ4t0nNsZ1zWZK6EuDCNG1mp4KL6QACaAreK
jO9JEUtnCoCrOdoXNSoiADI=
=g5Ah
-----END PGP SIGNATURE-----