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.

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.

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.