[Qgis-user] Trimble GeoXT 2005 Accuracy

[Greg Troxel]

[I'm not sure how on-topic this is for qgis-user, but I'm guessing it's
relevant enough, at least until a Moderator comment otherwise.]

Springfield Harrison <stellargps at gmail.com> writes:

To figure out what's going on this description needs to be tightened up,
which is probably going to require trimble documentation or support to
clearer (maybe the docs are fine; I haven't looked).

> For many years my work flow has been:
> Trimble Receiver + RTCM/SBAS ->

This is unusual phrasing.  SBAS is a class of things, not a particular
corrections source.  I'm guessing you are in North America and this
really means WAAS.

RTCM is a family of protocols for transporting corrections.  I am
unclear on whether the WAAS format uses RTCM but I don't remember seeing
it.  Within RTCM there is RTCM2, usually used for pseuorange
corrections, and RTCM3, usually used for carrier phase reference data.

So I wonder if the ProXR is doing RTK, what the correction source is,
and what the distance to the base station is (or if it's VRS).

To me the most important thing to be precise about is pseudorange
solutions (often called navigation solutions) vs carrier phase solutions
(post processed or RTK).  Then, there's PPP which is harder to
understand.

So I think you mean that while you were collecting points the receiver
was calculating pseudorange solutions and using the pseudorange
corrections delivered by WAAS.

> Pathfinder Office [+ RINEX Post Processing] -> SHP files -> GIS (QGIS
> or Manifold GIS).

You say "RINEX Post Processing" but that leaves out a ton of important
details.   I am guessing you mean that the receiver records carrier
phase observables, and then there was a double-differenced carrier phase
solution for each ooccupation.   The obvious question is where the
reference station data is coming from, how far away it is (or is it some
VRS), and what datum the reference station coordiantes are in.

Or maybe this is doing PPP.  There, similar questions apply about where
the orbit data is coming from and what frame that is in.

>  The CRS is NAD83 UTM 10N throughout, for my home area at least.

There are many realizations of NAD83.  Anything you did last year is
likely in "NAD83(2011) epoch 2010.0" if you are in the US and firmly on
the North American plate, and in Canada likely in NAD83(CSRS) apparently
in a province-dependent epoch.  The recent realizations are close enough
that neglecting this won't hurt too much, but if you are going to call
1m an error rather than a match, you should be careful about this.

If you are in an area with ground motion (e.g. Pacific Plate) then you
have a lot more to do.

The other big thing that's missing is what the trimble software is doing
about datum transformations (or not, if the reference station
coordinates are in NAD83(2011) as I'd expect).


>     None of these steps offer any option to choose or modify the Base
>       Station CRS so I don't think that would be the culprit in my NW
>       data offset, although maybe I've missed something.

I think it's necessary to understand what's going on inside the software.

>     Last fall I collected quite a few points in an attempt to
>       quantify the problem, if that's what it is.  Here are some
>       summaries:

As Nicolas said, you are talking about "known" but have not explained
where those coordinates came from and their expected errors.   I also
can't figure out your color scheme, and whether you are measuring 2
marks or one, etc.

Data from the receiver in no-differential pseudorange solutio mode (not
sure what "uncorrected" means) is going to be in WGS84(G1762), probably
labeled as WGS84, which is different than NAD83(2011), and that needs a
datum transform.  In QGIS, that often ends up with a null transform,
which is wrong.  So there's a good question about what is going on
within Pathfinder Office with datum transforms, which you need to find
out from Trimble docs or support.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/qgis-user/attachments/20210308/e9e4d492/attachment-0001.sig>