Trimble Business Center

We have a project that captures static baselines between 8-10 receivers with occupation durations of 2-8hrs depending on baseline length and deployment logistics.  After download, the following day we import static data from 2-3 local CORS sites - this data being the daily (24hr) occupations from each CORS.

When processing the data in TBC (v2023.10) we ensure the project Baseline Processing settings are changed from "automatic" to "10secs to force the processing interval match the capture rate of the units deployed.  This follows previous posts and the white paper that reports that TBC v4.xx and beyond is so smart that it automatically applies all sorts of things to ensure that the optimum baseline solution results.  (see:  TBC_Modernized Approaches for GNSS Baseline Processing_WHP_USL_0818.pdf )

I am reasonably happy to let TBC do all the work and generate the best baseline for me (I export the dX, dY, dZ vectors as per client requirements and do a network adjustment within a bespoke application).  As I need to report baseline occupation times, I can manipulate the export file with a start/end time and subtract one from the other to get the duration. 

But what I am intrigued with - and would like an explanation for if there is one - is that when I review the processed baselines, the vectors between the CORS stations (usually 10-30km apart) that have 24hr baseline data duration, have a PP vector reported duration of much less - one example is from 2hrs to 7hrs or so.   Changing back to the  "automatic" Baseline Processing interval results in the same outcome.

Anyone with a comment or explanation? Thanks.

I disable baselines between CORS, because they are control points and there's no need to involve them in computations for points that have values that won't be adjusted.

Loop closures are a valuable analysis tool and having those vectors provides additional loops.

Thanks Robert.  I get that the CORS stations values/coordinates won't be adjusted (when a subsequent adjustment happens).  But with my issue, I was processing with just one CORS stations as a CONTROL QUALITY coordinate, and all other stations - including the other CORS - as UNKNOWN QUALITY coordinate.  I was just using TBC to process and output dX, dY, and dZ vectors for export out of TBC, to be used in a client specified Survey Network Adjustment Programme (SNAP).  In this case, I would have thought that the processing an observed 23:59hr vector would still have reported a post-processed vector of the same duration.

I'll put it down to another TBC "querk"... ;-)