<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi Greg,</p>
<p>Comments inserted below -<br>
</p>
<pre class="moz-signature" cols="72">-----
Cheers, Spring</pre>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">On 08/Mar/2021 08:36, Greg Troxel
wrote:<br>
</div>
<blockquote type="cite" cite="mid:rmiczw9r4am.fsf@s1.lexort.com">
<pre class="moz-quote-pre" wrap="">
[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.]</pre>
</blockquote>
You're right but I took my que from other GPS related threads and
lack of response from Trimble.
<blockquote type="cite" cite="mid:rmiczw9r4am.fsf@s1.lexort.com">
<pre class="moz-quote-pre" wrap="">
Springfield Harrison <a class="moz-txt-link-rfc2396E" href="mailto:stellargps@gmail.com"><stellargps@gmail.com></a> 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).</pre>
</blockquote>
I'm familiar with the docs and no help from Trimble.
<blockquote type="cite" cite="mid:rmiczw9r4am.fsf@s1.lexort.com">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">For many years my work flow has been:
Trimble Receiver + RTCM/SBAS ->
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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.</pre>
</blockquote>
<p>Yes! I use SBAS because Trimble does in TerrasSync but it does
mean WAAS in southern BC, I think. They don't use WAAS because
the SBAS may use a different correction source elsewhere in the
world. I enable carrier measurements in TerraSync most of the
time.<br>
</p>
<p>Again, following Trimble terminology, RTCM in this case is a
marine beacon. I have no source for RTK.</p>
<blockquote type="cite" cite="mid:rmiczw9r4am.fsf@s1.lexort.com">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Pathfinder Office [+ RINEX Post Processing] -> SHP files -> GIS (QGIS
or Manifold GIS).
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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.</pre>
</blockquote>
I use the Pathfinder Office Post Processing engine which looks after
the technical details. I select a base station from their provided
list, sorted by distance and it fetches the (RINEX?) files and
applies the corrections. I think the distance was about 30km. PFO
makes no provision for specifying or modifying the base station
CRS. It is encoded in the RINEX files. It will utilize carrier
phase data if it available in the rover file.<br>
<blockquote type="cite" cite="mid:rmiczw9r4am.fsf@s1.lexort.com">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap=""> The CRS is NAD83 UTM 10N throughout, for my home area at least.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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.</pre>
</blockquote>
My concern is not the absolute error but the systematic shift of all
the points to the NW; the precision seems quite good, it is the
accuracy that I question. I think the different flavours of NAD83
UTM zone 10N differ by centimeters at most (?)
<blockquote type="cite" cite="mid:rmiczw9r4am.fsf@s1.lexort.com">
<pre class="moz-quote-pre" wrap="">If you are in an area with ground motion (e.g. Pacific Plate) then you
have a lot more to do.</pre>
</blockquote>
I am but how is this relevant, this is mm per year?
<blockquote type="cite" cite="mid:rmiczw9r4am.fsf@s1.lexort.com">
<pre class="moz-quote-pre" wrap="">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).</pre>
</blockquote>
Datum transformations where? Their post processing process is
"under the hood", QGIS datum transformations are much the same. I
have some faith (but not total) that they are being handled
correctly. This is supposed to be mapping, not geodesy.
<blockquote type="cite" cite="mid:rmiczw9r4am.fsf@s1.lexort.com">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap=""> 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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
I think it's necessary to understand what's going on inside the software.</pre>
</blockquote>
Maybe, but that would be Trimble proprietary stuff, presumably.
Their intent is to provide a streamlined workflow that incorporates
all the myriad technical gymnastics but only exposes me to the
NECESSARY details. I'm sure that research grade differential
software would reveal most of the operating parameters.
<blockquote type="cite" cite="mid:rmiczw9r4am.fsf@s1.lexort.com">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap=""> 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:
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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.</pre>
</blockquote>
I'm sorry but the presentation is complex and not overly clear.
This was not intended for presentation so lacks certain clarity. I
can't give it much more time but do appreciate the time that you and
others have spent. Both MAP B and Map A are referencing one point
(each). Positioning of the known source for Map B is from the
orthophoto which is not always reliable, although I think it is in
this case. However, Map A uses the property cadastre for reference
which does fit the orthophoto very well (actually the other way
around). Both situations are very comparable. <b>The thing to
note is that the GeoXT points are all clumped closely together
implying precision but are removed from the actual point implying
lack of accuracy. </b> This is the puzzle. Truly imprecise
results would be more scattered.
<blockquote type="cite" cite="mid:rmiczw9r4am.fsf@s1.lexort.com">
<pre class="moz-quote-pre" wrap="">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.</pre>
</blockquote>
<p>Uncorrected means just that, no real time corrections or post
processing. Wherever I have control over the CRS, (receiver, PFO
export to SHP and QGIS) I specify NAD83 UTM zone 10N. Beyond
that, the translation is not in my hands. I don't know exactly
what PFO or QGIS are doing under the hood but make the best
choices wherever they give me an option.</p>
<p>Thanks very much for these questions, a good learning experience
for sure . . . .</p>
<p><br>
</p>
<blockquote type="cite" cite="mid:rmiczw9r4am.fsf@s1.lexort.com">
</blockquote>
</body>
</html>