Please educate me on the need for TBC

I use it to generate machine control files.

If there was another way, I'd gladly use it instead.

Carlson allows you to do it for both topcon and trimble control files.

Are you putting all of your eggs in one basket relying exclusively on a VRS network? I don't have that luxury and use TBC routinely for post processing static data and doing QC on my RTK work. But, that's just me. You know your needs better than anyone else.

If your business model doesn't take you outside of the service area of your VRS or require post-processing of data, you have no need. I personally don't publish anything without running the data through one of our packages (LGO, Topcon Magnet or StarNet).

If you hope to do static work, you will need it.

Even though we do work out of the VRS areas and do run a base/rover/static on jobs I do not see the necessity of it.

Meaning, if you can check to a published monument wouldn't that show acceptable responsibility?

Our data collectors now are possible of doing just about all the adjusting needed. Why use an ancillary program if it can be field verified?

Everyone has "their" survey programs, I get it. But, TBC isn't cheap and the ROI is much less when you have to upgrade. (I won't throw in the pay for Trimble support here)

edit* thank you for the input

> Gents,
> Please help me see the reason TBC is useful. In Missouri we are spoiled with a solid VRS network that does check into 99% of published monuments w/in +/- 0.02 most of the time. (So no need to split the atom more than once)
>

I find it hard to believe that 99% of a very rapidly aging passive monument system matches anything (even itself) for +/- .02'.

Even scarier is that MoDot VRS (if that's what your using) broadcasts in NAD8(CORS96) Epoch 2002.0 while NGS publishes it's values in NAD83(2011) Epoch 2010.0...
at about 2mm/yr crustal motion in MO that's .05' in epoch difference alone.

It seems that the only way you could be getting the numbers you are is by calibrating everything all the time. If hanging your hat on this method works for you then no worries...
I would be worried if it were my work. Calibrations have a tendency to blow up in your face if you are not very careful.

TBC would give you the power to QA/QC a little more, and create and control post-processed calibrations if that is what you plan to use.

MoDOT VRS is now broadcasting in NAD83(2011). You have to re-calibrate all existing sites.

I use TBC for data backup(.dc, .job), cut sheets, coordinate reports (LLH), adjustments, and like others mentioned, it accepts and exports machine control files (.svd, .svl, .pro) as well as old Terramodel files. Not to mention all the feature code libraries capabilities. We have three sets of field codes we use on a regular basis. I have used TBC to create the code libraries and loaded them onto the controllers. This allows the codes to pop up on the data collectors, making it easier for the field guys.

I only have the base version. I think it was only 300-400 bucks per machine.

> Carlson allows you to do it for both topcon and trimble control files.

COOL! Which module is that?

That is the answer I was looking for. Thank you.

Munt,
With RTK (be it VRS or base and rover) there are several ways for things to go sideways. Checking into a passive mark or two will eliminate some of them.
Sticking with the issue at hand... we have good people. They use current equipment. I still find things in our data that the data collector is not designed to deal with, and many more where it is not an efficient tool for the job. Where you draw the line for office versus field is a personal choice. For me it's simple. I believe we produce a more efficient and higher quality product when the data is post processed.