For many years I have been creating a Baseline Processing Report after static processing in TBC, saving it as an excel file, and then I have a program that reads it into a database that also has occupation data, etc. Very important part of my workflow and facilitates the reports I create. Before TBC there was TGO, and it created a MSAccess database that I was able to easily read and extract info for my database file. But they went away from that to their proprietary file .vce. So it was a lot of work to come up with a program that reads their excel output. A minor irritation has been that anytime I install a new version of TBC I have to reconfigure the report format in TBC. But that only takes a few minutes.?ÿ
In V5.40, the values (Delta N, E, Up, and Delta ECEF X, Y, and Z, as well as azimuths, etc ) are all INCORRECT, by about a meter or two.
So through my dealer I contacted Trimble, and sent them my .vce file. They agreed, all of the values are messed up. But they could not recreate the problem with new data (i.e. not using my .vce file). I have verified that it is not just that file, anytime I create a project, process static data, and then create the report it is the same. If I export TDEF (Trimble Data Exchange Format), all of those values are correct.?ÿ
So I have uninstalled TBC, then reinstalled it from a fresh download, problem remains. My long term workaround would be to create my own export (which I have done), and then change my program to read that instead, but that is a lot of work to reconfigure everything.?ÿ
I have 5.30 on my laptop, it exports correctly. Of course, the only version available now from the web page is 5.40.?ÿ
Has anyone else ever seen this problem with 5.40? Does anyone else actually use the Baseline processing report??ÿ
Does anyone have a V5.30 full install that I could use??ÿ
?ÿ
?ÿ
?ÿ
John,
?ÿ
Do you think your problems might have something to do with this product Bulletin?
?ÿ
I don't think that the RTX enhancement (using HTDP model) should affect this, but who knows. As I said, I appear to be the only user affected, but not sure who even uses the report.
We do generate baseline processing reports, but only in a handful of offices that regularly run static networks.
Alas, I am in "ping a few VRS points then set up the total station" land.
A good chunk of our users are now running 5.40, so I will ask around and see if anyone has noticed that particular bug since upgrading. And if not, I can pull a bunch of data from other offices to check on myself.
IIRC, that's not the first time that baseline report has gotten screwed up...I seem to remember some really messed up graphs in a previous version.
I turn off the graphs. If the graphs are on, it totally changes the format of the excel file., makes it much harder to parse. I would like to have them on just for documentation purposes.?ÿ
I received a message back thru my dealer about the problem. I had selected UTM as the coordinate system, and a datum transformation to NAD83. For whatever reason, that caused the problem. Once I made the datum WGS84 it solved the problem. It is still a bug, and they said it should be fixed on the next release.?ÿ
?ÿ
should be fixed on the next release.?ÿ
?ÿ
Hahaha...haven't heard that before! Glad you got it working.
T. Nelson - SAM
I just encountered this problem with TBC 5.40. Baseline processing report is 1-2 meters off on coordinates & vector components, properties window is correct. In this case I had an old Trimble 5700 (GPS only) at the rover, raw data imported as RINEX 2.11 file converted from T01 using ConverttoRINEX 3.1.4.0.?ÿ Base end was modern Trimble Alloy, RINEX 2.11 downloaded from Wisconsin's WISCORS RTN.
Back in December 2020 I did not have this problem in TBC 5.40, when I had a Trimble R6 & R8s as rovers with same base above.
Dan: it has nothing to do with the type of receiver as far as I know. As I mentioned, if you set the transformation to none it should work. Glad to know I wasn't the only one affected...
OK, hopefully fixed in next release.
More info: I opened a TBC 3.90 project in 5.40 and generated the baseline processing report. Report vector components & "to" point are off about 1 meter. Original report generated in 3.90 was OK (matches properties window & TDEF export). I also got report errors when I copied a 3.90 project, opened in 5.40 & added new data. However when I created a new project in 5.40 from the default template (presumably a 5.40 template) the report was OK.
All these projects, old & new, had no datum transformation (molodensky dXYZ = 0). I'm going to delete my old project template and recreate it in 5.40 for now.
Recreating project template in 5.40 didn't help, must be the NAD 83 in my predefined coordinate system. Even though there's a zero-parameter datum transformation defined, and local geodetic = global geodetic coords in the project, the baseline processing report is applying some transform anyway, including major distortion of the baseline.
Does your 5700 have updated firmware installed for a leap second that arose a year or two ago?
Yes, got that firmware update, but even without it editing the RINEX file wasn't too complex. We dug the 5700 out of storage for GPS on Benchmarks.
I always enter a "global" coordinate referenced to ITRF2014 current epoch in to my processing, I wonder if that is a factor in this??ÿ
One note from years past. GNSS positioning software will automatically overwrite existing files, thus it needs to have administrative status. Check and see if some automatic system update altered the permissions status of your GNSS software.
Paul in PA