Trimble Business Center

Start New Project.
File
--Import:-)

> Jesus, why does this have to be so difficult!?

Because we are not Trimble's main source of revenue anymore.

We had a guy come over and demo it for us. It has some nice integrated features with baseline processing, automatic OPUS import and recomputing, but if I just want to look up point properties....HOLY :pissed:

Jered

> Start New Project.
> File
> --Import:-)

Not really.

:-@

Jered

Seems to work fantastic for me. I have imported job files, DC files, Static file ect.

For additional support Id recommend looking at Trimbles previously prepared videos that are linked from the startup page, or search on youtube. The workflows or tutorials are pretty good as well.

Hopefully it all falls into place:good: since it is a huge user interface change from TGO.:bad:

Jered

For old TGO files, yes, for new files from the DC and receiver, device pane is the ticket.

This sucks and the temporary license isn't working so I can't process baselines, view timeline to trim noisy data, etc.

Kris

You need to get the little device box at the bottom of the import slide to show up. Once it is there you can click on it and setup your devices; pretty much like TGO.
This is what it looks like. The little box at the bottom.

It just appeared for me. I think I activated it when I hooked up the TSC2 to the computer while in TBC. Once you get it to show it stays up as a feature of Import.

Kris, Trimble has posted help videos on Facebook. Just go to the Trimble Business Center facebook page and you'll find some helpful info.

Kris

Wow, that screen shot looks like it could of come right out of the Applanix PosPAC software, must be more Trimble influence than I thought since they bought Applanix!

SHG

When you open TBC, look at the tutorials and work flow guides as well...they are helpful.

Preliminary Testing Results

First, with my GNSS receivers, TBC will process that data where TGO wouldn't, thereby making them slightly different, but nonetheless very close. However, I took some old data that was run with only navstar capable gear and found the following. I noticed a solid 0.1" difference in bearings for static shots longer than 13k' but the distances, regardless of distance, were spot on. Under 10k', the bearings were spot on to the 0.1". The thing that really concerns me is the vertical component in this equation, and I'm interested in what you've found Kent. It would seem to me, that comparing apples to apples, IF the wave processors are the same, then there should be ZERO differences; however, I'm noticing anywhere from 0.01' to 0.03' differences in the vertical component regardless of distance from the base. Most of the time, it was at the 0.01' level (which I'll live with any day), but 0.03', from a static shot, begins to concern me.

The whole editing the static shots is a pain but easier. What are you guys who've made the move noticing between the baseline processors from TGO to TBC? What other testing would you recommend?

As far as the rest of the package, I'm not going to use it. I draw, calculate, and everything else in Carlson, so really, it's a glorified data collector utility that HAPPENS to process static data (which I dearly need in the piney woods of East Texas). I don't like how there is no wizard when you begin a project, or that it's more MICROSOFT like in that you must save your project (TGO saved it anyway). I also don't like downloading from the receiver first and having to enter the false northing and easting, indicating it's not seeing the "here" position from the R8 and 5700 receiver and using it.

What say you guys, better than TGO, worse than TGO? Some of you really know your stuff with this gear, and while I'm comfortable, I'm not nearly as versed as some of you as I'm self taught for the most part, which preserves the lessons, but makes them harder to learn and you don't know if you missed something along the way.

Preliminary Testing Results

The processor is NOT the same. Very much different. For one thing, you no longer have the trusty ratio/variance/rms trio to look at. It still gives rms, but I think it is derived differently. I was told it was totally rewritten.

As for the difference in azimuth for longer lines-that could be due to coordinate seeding, although it should also affect the distance (slightly). Remember, the better the starting coordinate, the less bias there is going to be, something like 1 ppm per 10 m (or something like that, I don't remember the exact number). In fact, to really minimize this effect you should process using an ITRF current epoch coordinate (as found in OPUS output on the right side). In any case 0.1" of arc is very small difference.

I really believe it gives better results, especially on crappy lines. But, what I am struggling with is the selection of baselines to process, I can't seem to do that with the mouse drawing a box as in TGO. I can pick each line individually. Maybe there is a trick to that.

It was pointed out to me by another new forced convert that if you try to get a baseline processing report->excel for too many lines (not sure how many is too many), you will get an out of memory error. They are working on fixing that.

I do not like having to use a dongle, that is always a major issue for me when I leave the office, as I invariably forget at least one thing if not more. I can remote back in, but I don't always have a decent internet connection.

As for testing, the bit that I did found that TBC more closely matched OPUS than TGO did, although there wasn't a whole lot of difference between TGO and OPUS. Very small differences.

Preliminary Testing Results

So far I've done one project since getting the new software. It calculated the base point correctly from cors stations. I'm not sure what you mean that you need to enter coordinates first. I had already set up a projection before going to the field for this project. When importing the base "here" point it placed it at the coordinates from the .dat file that the data collector came up with. Then I processed that position and imported the .dc file-it all worked correctly and the processed point matched an OPUS position within .02'. I got that point a day later. I'm also not using the other features for job management, but I will be using the roading program quite a bit, starting next week.

Mighty

It's possible that because the wizard isn't at the beginning of the project, then I imported the receiver using WGS84 as the projection, thereby causing my problem.

Give me a wizard or give me death! 🙂

Mighty

I think I see, you have an unprojected file and it asks for something during the import of the .dat file.

One thing that is bugging me is that it's difficult to change the quality of a point. When I import the "here" point I want to change the quality to unknown and the help menu tells me to click on the quality icon. When I do that nothing happens. There's only so much time I want to spend chasing after such a simple procedure.

Mighty

Geez!

Am I the only one that can't believe that we TGO users are left stranded on the island? Would anyone buy a car that all of a sudden stopped working after say 10 years, but the company tells us "well that is the way it is", but we will sell you a new car.

Charlie T says bend over and we will do it all again!

Mighty

This was wrong. Too many small shops can't afford to upgrade every other year. They should be able to use the product they purchased.

Mighty

Of course with a car you typically pay annual maintenance costs. You factor those costs into your budget.

Mighty

Don't get me wrong-I definitely think it was totally screwed up for Trimble to not fix the TGO problem. However, I was on my way to TBC, but resisting change, as we all do. So, it was a reason to switch completely. However, for various reasons I wish I could still use TGO-for example for a quick check on static data in the field before leaving.

Making a wish...

Following 'the day TGO died' - at least the short baseline processor - nary a day has gone by when I haven't thought about how great it would be if there was a web based service that would pre-process (or process) multiple GNSS data files submitted by the user.

Not OPUS but a service that would simply work with the files you send in. The returns would include vector/covariance data in a standard format for import into a commercial LSA package or perhaps just a QC report of the observation data that you could obtain while you are still in the field.

Of course, teqc running on a laptop can provide a QC report in the field...hmmmm, I am on the cusp of an idea....