Trimble Business Center

After over 25 years of depending on Starnet, I'm being told that I need to use TBC for network adjustments. I got a trial version of Starnet so I could run comparisons and generate some confidence in my TBC solutions but the variations are concerning. Since the same dataset is being used on both solutions, the adjusted positions should be nearly identical. Vertically, I'm getting up to 0.05' difference in my total station network. It's a tight network with 95% confidence of around 0.02'. TBC and Starnet seem to agree on the confidence level. It's also interesting that 100% of the 168 compared points show TBC's solution to be higher than Starnet's. The average is 0.03'. That's quite a lot considering the confidence level. Any suggestions on possible causes would be welcome.

Also, in Starnet, there's an option to specify centering error at instrument and target. I can't find anything like that in TBC. I have a couple of short observations triggering red-flags from a 40 second error when the prism was less than 50' away. That would be tolerated if the tribrach error could be set at 0.005'.

I'm a little confused about the terminology for Flagged Objects. What does this mean: "This point is out of tolerance. V = 0.299 ft exceeds the computational settings for vertical point tolerances."? 
I'm getting that error message on two critical control points.

I've run comparisons on two projects with similar results. 

we made this transition years ago. at the time i was not a real expert at starnet but i have the general idea and maybe we do things a little different than you. but i can try to give a couple tips. 
if you go into the settings cog(looks like a gear) this brings up all the settings for a project. make sure to run through all of these. there should be centering errors that you can tell tbc for your total station. off the top of my head i don t remember any for the backsight so not positive there. i don t have tbc open in front of me, but i think the setting is under computations and then total station. these settings can then be saved as a template for future projects with the same parameters. 
for most flags that come up when i process a data set i will right click on the flag or the point associated with the flag and select point derivation report. the observation that is flagged will show highlighted. sometimes it is just a check observation and i don t think that these are used in an adjustment but to be cautious you could delete or disable the observation. otherwise it could be a clue to a blunder so it is usually worth investigating. clicking on the hyperlink should highlight the observation in tbc either in the plan view or if you have the total station spreadsheet open. this makes it easier to find.
one thing to watch out for are as-staked points. points observed using the stakeout routine. these will not move with any shift or adjustment to your network. these are usefully to verify work on days after a project has been adjusted. but on a day prior to adj they should be highlighted, then right click and convert as staked points. this puts them up into the regular observations and they will behave normally. the ones in the as staked menu can then be deleted. 
the other thing that comes to mind is what is being held in your project. what are your control points and are they being given the same constraints in both softwares? 
hope this helps a little. 
starnet is a great program and it is a bit of a challenge to make tbc do what you want, but tbc has a lot of strengths and hopefully you can get it doing what you want. 

After over 25 years of depending on Starnet, I'm being told that I need to use TBC for network adjustments. I got a trial version of Starnet so I could run comparisons and generate some confidence in my TBC solutions but the variations are concerning. Since the same dataset is being used on both solutions, the adjusted positions should be nearly identical. Vertically, I'm getting up to 0.05' difference in my total station network. It's a tight network with 95% confidence of around 0.02'. TBC and Starnet seem to agree on the confidence level. It's also interesting that 100% of the 168 compared points show TBC's solution to be higher than Starnet's. The average is 0.03'. That's quite a lot considering the confidence level. Any suggestions on possible causes would be welcome.

Also, in Starnet, there's an option to specify centering error at instrument and target. I can't find anything like that in TBC. I have a couple of short observations triggering red-flags from a 40 second error when the prism was less than 50' away. That would be tolerated if the tribrach error could be set at 0.005'.

I'm a little confused about the terminology for Flagged Objects. What does this mean: "This point is out of tolerance. V = 0.299 ft exceeds the computational settings for vertical point tolerances."? 
I'm getting that error message on two critical control points.

I've run comparisons on two projects with similar results. 

That's helpful. I found the settings under Computations and didn't look further. Turns out, the Network Adjustment and Default Standard Errors folders have some settings that matter. The Centering Errors are there. Thanks for the help.

we made this transition years ago. at the time i was not a real expert at starnet but i have the general idea and maybe we do things a little different than you. but i can try to give a couple tips. 
if you go into the settings cog(looks like a gear) this brings up all the settings for a project. make sure to run through all of these. there should be centering errors that you can tell tbc for your total station. off the top of my head i don t remember any for the backsight so not positive there. i don t have tbc open in front of me, but i think the setting is under computations and then total station. these settings can then be saved as a template for future projects with the same parameters. 
for most flags that come up when i process a data set i will right click on the flag or the point associated with the flag and select point derivation report. the observation that is flagged will show highlighted. sometimes it is just a check observation and i don t think that these are used in an adjustment but to be cautious you could delete or disable the observation. otherwise it could be a clue to a blunder so it is usually worth investigating. clicking on the hyperlink should highlight the observation in tbc either in the plan view or if you have the total station spreadsheet open. this makes it easier to find.
one thing to watch out for are as-staked points. points observed using the stakeout routine. these will not move with any shift or adjustment to your network. these are usefully to verify work on days after a project has been adjusted. but on a day prior to adj they should be highlighted, then right click and convert as staked points. this puts them up into the regular observations and they will behave normally. the ones in the as staked menu can then be deleted. 
the other thing that comes to mind is what is being held in your project. what are your control points and are they being given the same constraints in both softwares? 
hope this helps a little. 
starnet is a great program and it is a bit of a challenge to make tbc do what you want, but tbc has a lot of strengths and hopefully you can get it doing what you want. 

After over 25 years of depending on Starnet, I'm being told that I need to use TBC for network adjustments. I got a trial version of Starnet so I could run comparisons and generate some confidence in my TBC solutions but the variations are concerning. Since the same dataset is being used on both solutions, the adjusted positions should be nearly identical. Vertically, I'm getting up to 0.05' difference in my total station network. It's a tight network with 95% confidence of around 0.02'. TBC and Starnet seem to agree on the confidence level. It's also interesting that 100% of the 168 compared points show TBC's solution to be higher than Starnet's. The average is 0.03'. That's quite a lot considering the confidence level. Any suggestions on possible causes would be welcome.

Also, in Starnet, there's an option to specify centering error at instrument and target. I can't find anything like that in TBC. I have a couple of short observations triggering red-flags from a 40 second error when the prism was less than 50' away. That would be tolerated if the tribrach error could be set at 0.005'.

I'm a little confused about the terminology for Flagged Objects. What does this mean: "This point is out of tolerance. V = 0.299 ft exceeds the computational settings for vertical point tolerances."? 
I'm getting that error message on two critical control points.

I've run comparisons on two projects with similar results. 

After over 25 years of depending on Starnet, I'm being told that I need to use TBC for network adjustments. I got a trial version of Starnet so I could run comparisons and generate some confidence in my TBC solutions but the variations are concerning. Since the same dataset is being used on both solutions, the adjusted positions should be nearly identical. Vertically, I'm getting up to 0.05' difference in my total station network. It's a tight network with 95% confidence of around 0.02'. TBC and Starnet seem to agree on the confidence level. It's also interesting that 100% of the 168 compared points show TBC's solution to be higher than Starnet's. The average is 0.03'. That's quite a lot considering the confidence level. Any suggestions on possible causes would be welcome.

Also, in Starnet, there's an option to specify centering error at instrument and target. I can't find anything like that in TBC. I have a couple of short observations triggering red-flags from a 40 second error when the prism was less than 50' away. That would be tolerated if the tribrach error could be set at 0.005'.

I'm a little confused about the terminology for Flagged Objects. What does this mean: "This point is out of tolerance. V = 0.299 ft exceeds the computational settings for vertical point tolerances."? 
I'm getting that error message on two critical control points.

I've run comparisons on two projects with similar results.