<div dir="ltr">
<div>Kirk is spot on. That unit is for GIS use and cannot receive RTK GNSS corrections. You will need a survey grade receiver, with RTK corrections (or post processed) for better accuracy.</div><div><br></div><div>Budget option for cm accuracy is the Emlid Reach RS or RS2<br></div>

</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 6 Mar 2021 at 23:53, Greg Troxel <<a href="mailto:gdt@lexort.com">gdt@lexort.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Springfield Harrison <<a href="mailto:stellargps@gmail.com" target="_blank">stellargps@gmail.com</a>> writes:<br>
<br>
> I recently acquired a Trimble GeoXT 2005 Series and am puzzled by the<br>
> results it produces:<br>
><br>
> 1. Compared to a variety of "known" points, it consistently records<br>
>    positions that appear to be in error by 1.2 - 1.5 m NW from the<br>
>    known point.<br>
> 2. Points are collected and then mapped in QGIS as NAD83, UTM Zone 10 N.<br>
> 3. The known points include property survey pins, Government control<br>
>    survey monuments, Total Station survey points derived from the<br>
>    above, other GPS results (Trimble ProXRS) and identifiable points on<br>
>    orthophotos.<br>
> 4. I'm using SBAS correction in the GeoXT.<br>
><br>
> It appears to be adding a consistent offset to the GPS result although<br>
> no offset has been set in TerraSync.<br>
><br>
> Many thanks for any thoughts on this situation . . . . .<br>
<br>
I'm really not clear on what this particular receiver is purporting to<br>
do, but a consistent meter-ish offset smells like an incorrect datum.<br>
<br>
If you are using SBAS and in the US, that means WAAS.  So you are<br>
getting results that in some CRS that the list hasn't figured out what<br>
it is, but "ITRF2008 current epoch" is my best guess.  That's<br>
essentially equal to "WGS84(G1762) current epoch".<br>
<br>
Those frames are definitely not equal to any flavor of NAD83.<br>
<br>
qgis, via proj, will treat "WGS84"  and "NAD83" both as datum ensembles<br>
and because each ensemble has a low-accuracy member treat them as equal,<br>
and thus choose a null transform.  IMHO this is the wrong thing to do,<br>
as WGS84(G1762) and NAD83(2011) are both datums with high intrinsic<br>
accuracy and are definitely not  equivalent.<br>
<br>
Converting from ITRF2014 to NAD83(2011) will apply a datum shift.<br>
<br>
Advice 1 is to shift your project CRS from NAD83 to ITRF2014 and see if<br>
the relative position of the observations and controls changes.   If so,<br>
you have datum transform trouble.<br>
<br>
My real advice 2 is to take the data file from the unit and label it as<br>
ITRF2014, and then see how things line up.  If you are talking about a<br>
meter you need to really pay very close attention not only to datum<br>
labeling but also in understanding the transformations your software is<br>
making.<br>
<br>
Greg<br>
_______________________________________________<br>
Qgis-user mailing list<br>
<a href="mailto:Qgis-user@lists.osgeo.org" target="_blank">Qgis-user@lists.osgeo.org</a><br>
List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-user" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-user</a><br>
Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-user" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-user</a><br>
</blockquote></div>