Hi, Kirk could be on the right track. You could try PPP using this site. You will need to create a user name and password. Then, you upload the Rinex file. I am 99% sure you can process point from outside of Canada.
https://webapp.geod.nrcan.gc.ca/geod/tools-outils/ppp.php?locale=en Nicolas Cadieux https://gitlab.com/njacadieux > Le 9 mars 2021 à 07:32, kirk <k...@nortekresources.com> a écrit : > > > Hi Springer > > I just looked up the marine beacon specs and they are designed for 10m > accuracy. This may explain why your non dgps data is closer to your survey > corner. > > > > Sent from my Galaxy > > > -------- Original message -------- > From: Springfield Harrison <stellar...@gmail.com> > Date: 2021-03-08 3:17 p.m. (GMT-04:00) > To: Nicolas Cadieux <njacadieux.git...@gmail.com> > Cc: kirk <k...@nortekresources.com>, Jorge Gustavo Rocha <j...@geomaster.pt>, > qgis-user@lists.osgeo.org, Greg Troxel <g...@lexort.com>, Dan > <19dm...@gmail.com> > Subject: Re: [Qgis-user] Trimble GeoXT 2005 Accuracy > > I'm resending this without the map as there is a size limit. The moderator > may let it through, I hope . . . . > > Hi Nicolas, thanks for your observations. I'll try to answer your questions, > please see the attached map, especially Map A: > > Note that my previous email contained information for Map B; Map A is based > on the Municipal Cadastre (NAD83 UTM zone 10N) and illustrates the problem as > well. Other locations based on Provincial Monuments and/or the Municipal > cadastre (not illustrated here) have yielded similar results. > > How many “known” points have you tested? > 2 in this case, Maps A and B > Also several other locations with similar results > How where those point position calculated. > From the Municipal cadastre, visible in Map A > Make sure the coordinates are in the right CRS > NAD 83 UTM 10N used throught. See workflow in previous email > When converting from the monument’s CRS to NAD83 UTM zone 10N, are you using > the correct grid files? > [No monuments in this example] These were brought into QGIS from the > Municipal GCM database CSV (NAD83(CSRS) 3.0.0.BC.1.CRD) and reprojected by > QGIS to EPSG:26910 - NAD83 / UTM zone 10N > Presumably QGIS would choose the correct grid files > Municipal Cadastre is NAD83 UTM zone 10N > Find a geodesic point that is in the middle of a field or on the side of a > highway with no obstacles. > Map A is open sky > Make sur your observations will be done when the constellation is well > distributed in the sky > As you probably know, TerraSync provides for PDOP, HDOP, SNR and Horizon > masks to preclude collecting poor quality positions. These were set towards > the "Precision" end of the scale > What post processing techniques are you using? How far is the base station > from your unit? > Real time was SBAS or RTCM; Post processing using the Pathfinder Office > differential correction engine, baseline about 30 km > How long are the observations? Have you tried other methods of post > processing like PPP? > Logging interval is 5 sec; 33 to 2037 positions per point > Did not use PPP. This is a test of mapping best practices, not geodesy > Have you contacted Trimble? > Yes, no response > Have you looked on there site to see if there is a software update (firmware) > for the unit or the post processing software? > Yes, receiver firmware is the latest, PFO and Terrasync are older but > compatible > Thanks Nicolas. If I have missed something, I hope someone can point it out, > I've tried to cover all the bases based on my training and experience. > > ----- > Cheers, Spring > > > > On 08/Mar/2021 06:40, Nicolas Cadieux wrote: >> Hi Harrison, >> >> How many “known” points have you tested? How where those point position >> calculated. They could be off. If you are using state geodesic monuments, >> try to find the documented precision of the monument. States have different >> types of monuments, some are very old and have different standards. Make >> sure the geodesic point is not the problem. Make sure the coordinates are >> in the right CRS. As an example, if the coordinates are published in NAD83 >> original but you are assuming NAD83(CSRS), then you have a problem. When >> converting from the monument’s CRS to NAD83 UTM zone 10N, are you using the >> correct grid files? What is the published precision for this reprojection? >> >> You say you have houses and trees. This could be the problem. Find a >> geodesic point that is in the middle of a field or on the side of a highway >> with no obstacles. Make sur your observations will be done when the >> constellation is well distributed in the sky. I believe Trimble has a >> observation planing software that can help you figure out the best time for >> observation. This could explain why the GEoTX are to the east unless the >> observations where made at the same time and same conditions (ex leaf off). >> >> What post processing techniques are you using? How far is the base station >> from your unit? If you are using a state correction service, can you select >> more stations? How long are the observations? Have you tried other methods >> of post processing like PPP? >> >> Have you contacted Trimble? Have you looked on there site to see if there >> is a software update (firmware) for the unit or the post processing >> software? >> >> >> Nicolas Cadieux >> https://gitlab.com/njacadieux >> >>> Le 8 mars 2021 à 05:24, Springfield Harrison <stellar...@gmail.com> a écrit >>> : >>> >>> >>> Hi Kirk, >>> >>> Thanks again for the ideas. >>> >>> Re "I assume your raw data files are being converted to gpx on a computer >>> since the raw terrasync files are proprietary binary files". Not sure why >>> you would make this assumption - PFO does not export GPX files, only GIS >>> files of many kinds, although one could create a custom format I suppose. >>> >>> I have always avoided non-GIS formats (Garmin, GPX, GDB, KML, KMZ, >>> GoogleEarth, iPad/Tablet "mapping", etc.). I'm in the process of >>> re-mapping a tablet based tree inventory using SW Maps with a Total Station >>> survey as many of the trees are near the property boundary. Some of the >>> tablet errors are quite large. Due to the tree canopy, GPS quality is >>> variable. >>> >>> I know that many people use tablets and hiking GPS as mapping tools but I >>> have little faith in them for that purpose. >>> >>> For many years my work flow has been: Trimble Receiver + RTCM/SBAS -> >>> Pathfinder Office [+ RINEX Post Processing] -> SHP files -> GIS (QGIS or >>> Manifold GIS). The CRS is NAD83 UTM 10N throughout, for my home area at >>> least. >>> >>> 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. >>> >>> 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: >>> >>> Average distance from "Known" point (m) >>> >>> Location >>> >>> Receiver Correction Corner IP NW Grand Total >>> GeoXT Post 1.44 1.44 >>> SBAS 1.37 1.26 1.33 >>> Uncorr 0.73 >>> 0.73 >>> GeoXT Total 1.34 1.26 1.32 >>> ProXR RTCM 0.38 0.61 0.49 >>> ProXR Total 0.38 0.61 0.49 >>> Grand Total 1.17 0.97 1.12 >>> >>> >>> Location Data >>> >>> >>> >>> Count of Feature Points and Positions >>> >>> Corner IP NW Total Count of Point_ID Total Sum of >>> Filt_Pos >>> Receiver Correction Count of Point_ID Filt_Pos Count >>> of Point_ID Filt_Pos >>> GeoXT Post 9 1492 9 1492 >>> SBAS 8 1280 5 905 13 2185 >>> Uncorr 2 2836 >>> 2 2836 >>> GeoXT Total 19 5608 5 905 24 6513 >>> ProXR RTCM 4 2541 4 683 8 3224 >>> ProXR Total 4 2541 4 683 8 3224 >>> Grand Total 23 8149 9 1588 32 9737 >>> Corrected test Points and separation from the antenna location. >>> >>> <malbiblkchcpcpdh.png> >>> As above but with 2 uncorrected GeoXT points overlaid, including the >>> individual positions that were averaged. >>> >>> <jpbjaanipeilbbgo.png> >>> Notes and findings: >>> >>> Site is open sky but with house and trees adjacent >>> Antenna is static, occupation periods long (5 sec logging interval) >>> 32 observations averaged from 9737 positions >>> some observations are with the GeoXT internal antenna, others are with a >>> Trimble aircraft antenna (intended for SBAS) >>> Work flow as outlined above >>> The GeoXT uncorrected results are better than either of the corrected >>> results!? >>> The corrected ProXR results are better than any of the GeoXT results, >>> although biased to the east >>> The uncorrected GeoXT readings exhibit the NW bias but to a lesser extent >>> which seems to indicate that the correction does not create the problem but >>> may exacerbate it, if that makes any sense. >>> I have probably missed something but my reaction remains that the receiver >>> may be defective (?) >>> Thanks again for your help and patience . . . . . >>> >>> ----- >>> Cheers, Spring >>> >>> >>> On 07/Mar/2021 03:54, kirk wrote: >>>> Hi Springer. >>>> >>>> I assume your raw data files are being converted to gpx on a computer >>>> since the raw terrasync files are proprietary binary files. If you are >>>> using trimble pathfinder, you can post process differentialy correct the >>>> data if you have access to base station logged at the same time you >>>> captured your field data. Having a base station 100 miles away will not >>>> improve your results as the baseline is too long. >>>> >>>> I do not know if you can write a gpx file directly from pathfinder but I >>>> would not bother. I would write a shapefile which will contain the >>>> coordinate system you specify. Simply open in qgis and you should be good >>>> to go. If your older unit works better, I would expect it may be an issue >>>> with the setup within pathfinder or perhaps the software version. >>>> >>>> I think your consistent offset is a direct result of how you are >>>> converting your data from trimble to gpx. >>>> >>>> As I mentioned in my previous comments, there are many issues which affect >>>> accuracy. Just because the box says it is accurate you will rarely >>>> replicate that in the field. >>>> >>>> In terms of WAAS dataframes, these are processed internally on your field >>>> unit. >>>> >>>> Kirk Schmidt >>>> >>>> >>>> >>>> Sent from my Galaxy >>>> >>>> >>>> -------- Original message -------- >>>> From: Springfield Harrison <stellar...@gmail.com> >>>> Date: 2021-03-07 5:57 a.m. (GMT-04:00) >>>> To: kirk <k...@nortekresources.com>, Jorge Gustavo Rocha >>>> <j...@geomaster.pt>, qgis-user@lists.osgeo.org, Greg Troxel >>>> <g...@lexort.com>, Dan <19dm...@gmail.com>, Nicolas Cadieux >>>> <njacadieux.git...@gmail.com> >>>> Subject: Re: [Qgis-user] Trimble GeoXT 2005 Accuracy >>>> >>>> Hello All, Thanks for the comments, I'll reply more fully tomorrow. The >>>> receiver is Trimble mapping grade: "The GeoExplorer 2005 series consists >>>> of: • The GeoXH™ handheld, providing subfoot (30 cm) accuracy, or even >>>> 8-inch (20 cm) accuracy with the optional Zephyr™ antenna. • The GeoXT™ >>>> handheld offering submeter accuracy for GIS data collection and data >>>> maintenance. • The GeoXM™ handheld with 1–3 meter GPS accuracy for mobile >>>> GIS applications." "Post processed carrier accuracy: 1-30cm". This >>>> receiver was probably $5-8000 (?) new. >>>> >>>> Data collection was stationary, open sky, good satellite coverage, several >>>> minutes of 5 sec observations, good PDOP >>>> SBAS and/or post processed >>>> The concern is not the accuracy as such, but the systematic NW shift. >>>> This has been observed over several months, consistently. My old Trimble >>>> ProXR (1994?, $20K new!) is actually better in this regard than the GeoXT! >>>> The Trimble manuals make no mention of the SBAS CRS, implying "turn it on >>>> and go, the receiver will integrate the SBAS into the rover file." More >>>> tomorrow, thanks . . . . . >>>> >>>> ----- >>>> Cheers, Spring >>>> >>>> >>>> >>>> On 06/Mar/2021 15:56, kirk wrote: >>>>> A few notes. >>>>> >>>>> sbas which is waas in north America is based on equatorial satellites >>>>> which will get you in the 1 m range in southern Canada. >>>>> >>>>> you can achieve sub decimeter accuracy consistently using rtk ,either >>>>> through a ntrip caster (base station) broadcasting over the intenet or >>>>> with your own base station and a radio link. there are a few chip sets >>>>> and break out boards that you acquire and assemble your own system. This >>>>> is a very inexpensive option. >>>>> >>>>> Another option in Canada is to use precise point positioning (PPP) which >>>>> requires 6 to 12 hours of observation data using L1, L2 or L1 and L2 data >>>>> and rinex log files. This comes in handy if you need to establish a >>>>> remote base station. >>>>> >>>>> A proper antennae with a metal ground plane is also critical to getting >>>>> quality results. >>>>> >>>>> Observing under a forested canopy is difficult especially in summer under >>>>> leaf on conditions, after a rain which creates multiparth mayhem. >>>>> >>>>> There is a reason survey grade equipment is relatively expensive. If you >>>>> require repeatably accurate results in a variety of conditions this is an >>>>> option. >>>>> >>>>> Kirk Schmidt >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Sent from my Galaxy >>>>> >>>>> >>>>> -------- Original message -------- >>>>> From: Jorge Gustavo Rocha <j...@geomaster.pt> >>>>> Date: 2021-03-06 6:41 p.m. (GMT-04:00) >>>>> To: qgis-user@lists.osgeo.org >>>>> Subject: Re: [Qgis-user] Trimble GeoXT 2005 Accuracy >>>>> >>>>> Hi, >>>>> >>>>> I just jump in this thread to say I'm really impressed with Ardusimple. I >>>>> have a RTK Handheld Surveyor Kit [1] for +- 400 € and it works really >>>>> well. >>>>> >>>>> I use the national NTRIP service and I have consistently precisions >>>>> around 10 cm with just one receiver. >>>>> >>>>> I use a free Android application called SW Maps [2]. My survey points, >>>>> tracks and photos are collect in a geopackage that I can read in QGIS. I >>>>> use it mostly to collect ground control points for my drone flights. >>>>> >>>>> Regards, >>>>> >>>>> Jorge Gustavo >>>>> >>>>> [1] https://www.ardusimple.com/product/rtk-handheld-surveyor-kit/ >>>>> >>>>> [2] https://play.google.com/store/apps/details?id=np.com.softwel.swmaps >>>>> >>>>> Às 20:12 de 06/03/21, Greg Troxel escreveu: >>>>>> Springfield Harrison <stellar...@gmail.com> writes: >>>>>> >>>>>>> Thanks Dan. See my relies to Kirk and Greg. The Emlid sounds >>>>>>> interesting, will have a look. >>>>>> I have an earlier Emlid Reach (not RS or RS2), which has L1 only, and I >>>>>> never got it to work well. >>>>>> >>>>>> Also look at the Ardusimple unit -- but it's more a parts kit than a >>>>>> system. You need a way to get RTK reference data in, and a good >>>>>> antenna. One approach is Vespucci (OSM editor for Android) as a >>>>>> datalogger, and the Ardusimple WiFi NTRIP master to get corrections over >>>>>> the phone's hotspot. >>>>>> >>>>>> https://www.ardusimple.com/product/simplertk2b/ >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Qgis-user mailing list >>>>>> Qgis-user@lists.osgeo.org >>>>>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-user >>>>>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user >>>>> -- >>>>> >>>>> Geomaster >>>>> Jorge Gustavo Rocha | Software Engineer >>>>> e: j...@geomaster.pt | m: +351 910 333 888 >>>>> g: 41.54094,-8.40490 | v: 510 906 109 >>>>> a: Rua António Cândido Pinto, 67, 4715-400 Braga >>>>> >>>>> >>>>> _______________________________________________ >>>>> Qgis-user mailing list >>>>> Qgis-user@lists.osgeo.org >>>>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-user >>>>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
_______________________________________________ Qgis-user mailing list Qgis-user@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-user Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
