I am currently testing least-squares adjustment software and have encountered issues when combining GNSS coordinates from a Trimble rover with MicroSurvey STAR*NET. During testing, I observe systematic centimeter-level discrepancies, in some cases up to 10–11 cm, which I have not yet been able to fully explain.
Context
Measurements
-
GNSS RTK observations using a Trimble rover
-
Corrections via FLEPOS (Flemish Positioning System), mountpoint FLEPOSVRS32GREC (RTCM 3.2, MSM, CMRx)
-
Static measurements on control points (typically ~5 minutes per point)
- The site is only 80 m long in a flat area
Coordinate systems
-
Observations are made in ETRS89
-
Converted to Lambert 72 (BD72 / LB72) in Trimble Access
Software
-
Trimble Access (field software)
-
Trimble GNSS processing
-
MicroSurvey STAR*NET (least-squares adjustment with a network obtained from an S7)
Workflow
-
GNSS measurements and GPS vectors are exported from the Trimble controller using the STAR*NET-compatible format and imported directly into STAR*NET.
- After performing the least-squares adjustment, I noticed that the GNSS coordinates differed by several centimeters (up to 11 cm) compared to the GNSS coordinates obtained from Trimble Access. The least-squares adjustment itself was reviewed and verified by STAR*NET support.
Observed issue
When comparing:
-
GNSS-derived coordinates from Trimble Access
vs. -
Adjusted coordinates computed by STAR*NET
I observe systematic offsets, typically several centimeters and in extreme cases up to ~11 cm. Interestingly:
-
GNSS coordinates from a previous surveyor align well with my own GNSS observations in Trimble access.
-
Once the same dataset is adjusted in STAR*NET, those discrepancies appear.
This suggests the issue is not random GNSS noise, but rather something systematic in the coordinate transformation or datum realization.
Findings so far / hypothesis
From discussions with MicroSurvey STAR*NET support, the leading hypothesis is a mismatch in the BD72 ↔ ETRS89 transformation:
-
FLEPOS confirmed that they do not provide LB72 coordinates directly; they provide ETRS89, which is then converted to Lambert 72 inside the controller (Trimble Access).
-
STAR*NET applies its own BD72 ↔ ETRS89 transformation, potentially using:
-
an older grid shift file, or
-
a different realization/epoch of the transformation.
-
-
According to MicroSurvey support, a newer realization of the BD72 ↔ ETRS89 transformation may exist, typically implemented via a .gsb grid shift file. We tested the latest grid shift file from the National Geographic Institute, but this did not improve the results.
-
A mismatch between the grid shift models used by Trimble Access and STAR*NET could explain the centimeter-level systematic offsets. I’m therefore curious if others have experienced similar issues.
Other potential causes have largely been ruled out:
-
Tilt compensation: not used
-
Gross GNSS measurement error: unlikely, given internal consistency and agreement with previous surveys
Questions to the community
-
Does anyone have experience combining Trimble GNSS data with STAR*NET, specifically in Belgium?
-
Have you encountered systematic centimeter-level discrepancies caused by different grid shift files or datum realizations?
-
Would you recommend using Trimble Business Center (TBC) instead of STAR*NET for GNSS-heavy projects to avoid these issues?
Any technical feedback, real-world experience, or authoritative references are very welcome. Corrections to my understanding are also appreciated, my goal is to understand both what is technically correct and what is commonly done to solve these kind of issues.
I have already worked with STAR*NET support, but we have not yet identified the definitive cause. Trimble has not responded so far, which is why I am turning to this forum.
Thank you in advance for your insights.
Try turning off “ Use Time Dependent Translations “ in Access. Trimble sets Yes to the default and this extra translation happens in the background without any notice to you.
Please help me understand what you are doing. What is “Trimble GNSS processing “ you refer to?
trimble access does a site calibration but it don’t do least square adjustments, it also fits not process static data files.
When you say static measurements on control points are you really processing static baselines or is this just five minutes of RTK occupation. If static baselines what are you using to process those baselines and the resulting network?
@stevenmartin Thanks! I'll try it out. Is it possible that that time dependent translation isn't supported in my country/region? And I'm also wondering why my Trimble rep wouldn't mention this, would you have any idea? https://community.trimble.com/blogs/erin-johnson1/2021/02/12/tip-139
@robertusa , thanks for your reply! Sorry for being unclear. I shouldn’t have mentioned GNSS processing since I just take the coordinates straight from the controller, which were determined by the 5 minute measurement with RTK corrections.
@lurker , thanks for your reply! It is just five minutes of RTK occupation.
I have verified the Trimble Access coordinates in Trimble Business Center, and after consultation with STAR*NET support we concluded that the primary difference between the products is the epoch of the grid shift file.
Does anyone have a solution for this, or are there any STARNET users in Belgium working with Trimble equipment?
@surveyor14785 single 5 minutes RTK observations per control point isn’t a great method. If you are receiving at least 3 constellations of satellites, it’s better to make 30 second observations, reset satellite tracking and make another 30 second observation using the same point name. Have 3 or 4 observations this way is notably better than just 1 observation. Then use network adjustment in TBC
In the initial post @surveyor14785 states that the site is only 80 m long. IMHO that is too small for accurate GPS work which is only accurate to +/-0.03' or +/-10mm creating the possibility of a 2cm or more error in just 80m. This small site needs to be surveyed with a total station if accuracy is required.
Also there may be something wrong with the static data. The OP states he used a rover connected to a RTK Network with a Mount Point and took a 5 minute shot per control point. That shot is not static data. The OP must set the rover to start logging "Raw Data" or "Static" in their software at a minimum of 20 minutes and then saved to be processed later.
You must be sure you're comparing apples to apples throughout the entire process. The exact datum, the exact controlling coordinates for each program. My guess from what the STARNET is telling you is that your basis of coordinates are different.
If you can use the same basis and recalculate does that bring them together. And are you finding that the figure you're surveying has different interior angles and distances after the final calculations, or are they the same?
https://rpls.com/member/christ-lambrecht/
He is in Belgium. Might try shooting him a message?
Just because I'm paranoid, doesn't mean they aren't out to get me.