Trimble Geomatics Office (TGO) Processing Issue

Share this thread:

Houston! We have a problem...TGO will no longer process Static GPS data as of Wednesday (Julian Day 257)~!

The apparent problem is that GPS time reached 1 billion seconds since 1980 on Wednesday…(the Y2K issue comes to mind).

Our hopes is that Trimble will create a patch to fix the problem, but I would not hold my breath since TGO is discontinued! Trimble Business Center seems to be processing static GPS with no issues.

Ricardo Johnson, PLS
John Chance Land Surveys, Inc.

Post reply

14372 views

link

Yup, the days of TGO are gone. TBC is the new deal and if you don't like it apparently too bad. Last issue I had I was told to contact my local Trimble dealer about purchasing TBC.

Post reply

14301 views

link

Whoa...I had a wacky thing happen on Tuesday...in Trimble Business Center, an RTK topo shot is showing a vector as being from 1/5/1980. The duration is 0:00 and it shows no hor. or vert. residuals.

It must have something to do with that. Thanks for the info.

Post reply

14272 views

link

The 1/5/1980 is week zero. This happens when the week number is corrupted or missing.

I think it strange that the number of seconds since the beginning of GPS time has any effect. Most comps are done with week number and seconds of week, which rollover after 604,800. I was not aware that TGO converts it to a running count from week zero.

Post reply

14259 views

link

Wow-I just tried it with data from today. This really sucks. I am not totally ready for TBC, and I don't like being forced into it. It is not a monetary issue-I have TBC, and I keep up-to-date with versions, etc. I just am very comfortable with TGO.

Hope they fix this!

Post reply

14252 views

link

Hopefully, they will come up with a patch. Trimble Geomatics Office is a great software. Intelligently designed.

It would be inconvenient that users need to rely on third party manufacturers (or competitors) to process the Trimble data of their older, but still in good condition, equipment.

Post reply

14222 views

link

I downloaded a data collector (all RTK) from the 15th and it worked. Then I processed a .dat file from a base using a Cors point and it worked (also from the 15th). What isn't working for you?

Post reply

14196 views

link

I just downloaded a couple hours of data from 2 local CORS from the 15th and TGO would not process them. If Trimble was aware of this problem and didn't send a warning, I think they just lost a lot of customers.

Post reply

14172 views

link

I just tried some CORS data from the 15th, too, and got nothing, not even a wave.log file. Hmmm...

--
Jim Frame
Frame Surveying & Mapping
609 A Street
Davis, CA 95616

Post reply

14176 views

link

Evidently the problem is with the WAVE processing engine that both GPSurvey and TGO share, as I understand it. My version of GPSurvey with WAVE 2.35 began refusing to process static and stop-and-go baselines on Wednesday. The processing log indicates problems with the data in various modules of the program.

Now the question is what to do. Trimble Business Center looks like it is several orders of complexity beyond TGO, which is really unfortunate for someone who just wants to process GPS vectors to export for adjustment in Star*Net.

--
Best regards,
Kent McMillan, RPLS Austin TX

Post reply

14163 views

link

You can download and run the L1 version of GNSS solutions for free. I don't know how much an L1/L2 license costs:

http://www.ashtech.com/gnss-solutions-3935.kjsp

The antenna editor is way more friendly than TGO's.

Post reply

14155 views

link

You can download and run the L1 version of GNSS solutions for free. I don't know how much an L1/L2 license costs:

http://www.ashtech.com/gnss-solutions-3935.kjsp

The antenna editor is way more friendly than TGO's.

What's the secret word to get access to the free download, though? When I follow that link, I just see the suggestion to have a salesperson contact me, which is friendly, but not all that helpful.

--
Best regards,
Kent McMillan, RPLS Austin TX

Post reply

14041 views

link

After doing a bit of research, I see that Trimble Business Center (what a Donald-Trump-sounding name) comes in two versions, the Standard, which will only process L1 GPS vectors, and the Advanced, which handles multi-frequency processing. The price I was quoted was about three grand, but I didn't know to ask which version was being quoted. Considering that some manufacturers are giving away their L1 GPS processing software, it may well be that the Standard version of TBC is less than three grand. That would be pleasant.

--
Best regards,
Kent McMillan, RPLS Austin TX

Post reply

14021 views

link

OK that's new since the last time I went there. They used to just have everything on a public FTP, no login required.

Now I guess they want you to register so they can start sending you spam.

Google search for GNSS Solutions Download brings up several links. One I found is 3.60 (I am using 3.10). You would have to pay for dual frequency anyway.

Obviously Trimble should be better for use with Trimble receivers (maybe).

Post reply

14002 views

link

Google search for GNSS Solutions Download brings up several links. One I found is 3.60 (I am using 3.10). You would have to pay for dual frequency anyway.

Obviously Trimble should be better for use with Trimble receivers (maybe).

Well, that is going to pretty much depend on whether the new TBC software supports the older Trimble receivers or not. If not, I guess all RINEX files look the same in the dark.

--
Best regards,
Kent McMillan, RPLS Austin TX

Post reply

13997 views

link

could you post your method for entering multiple OPUS solutions into Star*Net V6, please?

I am working on a project with my co-worker which has 4 primary control points, each of which has multiple 5+ hour static observations on different days. So far it is all GPS to aerial target panels but ultimately there will probably be some conventional ties to boundary monuments. My co-worker is doing the processing in Topcon Tools so far but eventually I will put it all into a Star*Net so we can keep adding observations in over time. It would be nice to use all of the OPUS solutions.

Post reply

13846 views

link

While you're waiting for Kent to chime in, you might want to look at Peter Lazio's excellent article on A Hybrid Covariance Matrix for Use with OPUS Solutions. I've never used it, but I keep it bookmarked for the day I finally have to wrap my brain around the concepts and put them to use.

--
Jim Frame
Frame Surveying & Mapping
609 A Street
Davis, CA 95616

Post reply

13801 views

link

could you post your method for entering multiple OPUS solutions into Star*Net V6, please?

It is really just a cut-n-paste job with the xyz covariance matrix to create a GPS vector of nominal length = 0 (DX=0 DY=0 DZ=0) with the elements of the upper triangle of the covariance matrix that OPUS supplies used to fill in the covariances of the GPS vector.

That is, the standard covariance-weighted GPS vector in Star*Net looks like this:

.GPS WEIGHT COVARIANCE
.GPS FACTOR 2.5 VERT 5.0

.UNITS METERS

# BASE STATIONS USED in 11Day190a
#PID DESIGNATION LATITUDE LONGITUDE DISTANCE(m)
#DE6248 SGI1 SCHULTZ GROUP COOP CORS ARP N294315.169 W0980851.693 37050.1
#DJ7872 TXSE SEGUIN CORS ARP N293527.013 W0975951.834 44721.4
#DG5767 TXSM SAN MARCOS CORS ARP N295240.525 W0975409.649 12302.3

PH 10Day190a 29-59-17.34185 97-55-02.88662 182.398 ! ! !
G0 'V1 Day190a
G1 10Day190a-10 0 0 0
G2 0.0000031156 0.0000125200 0.0000103000
G3 0.0000003031 0.0000002430 -0.0000001044

The "#" comment lines are just to remind me of which reference stations were used in the solution. They aren't really necessary.

The blue GPS WEIGHT line is needed if you are mixing covariance-weighted vectors with other types in the adjustment. You don't need it if all the vectors are covariance-wieghted, but it doesn't hurt to throw it in.

The red line is just the NAD83 OPUS estimate of the position. If the mark is designated as, say, "10", I add a "DayNo" suffix if multiple OPUS solutions on the same point are to be used in the adjustment. The form of the adjustment is to treat the actual position of "10" as being tethered to the OPUS estimate "10Day190a" (in this case). Where there are multiple OPUS estimates on various days, the suffixes group them together in the output listing.

The orange line is is a zero-length vector, i.e. "10Day190a" is the same point as "10", but the coordinates of "10" are subject to adjustment. Those of "10Day190a" are merely one estimate of the coordinates of "10".

The green lines were extracted from the following covariance matrix that OPUS supplied:

Covariance Matrix for the xyz OPUS Position (meters^2).
0.0000031156 0.0000003031 0.0000002430
0.0000003031 0.0000125200 -0.0000001044
0.0000002430 -0.0000001044 0.0000103000

which is in the general form of variances and covariances:

XX XY XZ
YX YY YZ
ZX ZY ZZ

with the G2 and G3 lines being formed as follows

G2 XX YY ZZ
G3 YX YZ YZ

You can derive an appropriate scalar to apply to the OPUS-derived weights. The values of "GPS FACTOR" of 2.5 for horizontal components and 5.0 for vertical are empirically derived from summertime work in Central Texas. Elsewhere, your mileage may vary.

--
Best regards,
Kent McMillan, RPLS Austin TX

Post reply

13761 views

link

Thanks.

It looks like you have:
G2 XX YY ZZ
G3 YX XZ ZY
The Star*Net Manual should have the format too. I just don't have it here.

So you get a list of different positions for the same point? What do you tie your baselines to if you have more than one point 10?

Post reply

13683 views

link

Thanks.

It looks like you have:
G2 XX YY ZZ
G3 YX XZ ZY

Sorry for the typo. Make that:

G2 XX YY ZZ
G3 XY XZ YZ

The Star*Net Manual should have the format too. I just don't have it here.

So you get a list of different positions for the same point? What do you tie your baselines to if you have more than one point 10?

If you have more than one OPUS solution on Pt. 10, then you assign the different OPUS solutions names other than "10". I use related point names like "10a", "10b", "10c" or, better yet, names connected with the OPUS solution such as "10Day120" for the OPUS solution from Day 120. The position returned by OPUS is given the related point name and its coordinates are treated as fixed, i.e. weighted "! ! !" in the adjustment.

The floating point "10" (in this example) is connected to fixed OPUS points. Just as an example, let's call the three different OPUS solutions for Pt.10 "10Day120", "10Day121", and "10Day125". Each of them is supposedly Pt.10, so the vector from each to 10 is DX=0, DY=0, DZ=0, but with uncertainties described by the covariances.

So, if you generate three different GPS vectors from "10Day120", "10Day121", and "10Day125" to "10", the adjustment will estimate the position of "10" that is the least squares solution of "10". On the network plot, you'll see the adjusted vectors from each of the three OPUS solutions to "10" will have a length that represents the residual from the adjustment. Here is an example showing three different OPUS solutions on a Pt. 11. in the diagram below.

[image]

The baselines from Pt.11 connect to it, the adjusted point, not the fixed values of OPUS solutions, so the uncertainties in Pt.11 propagate to all points connected to it.

--
Best regards,
Kent McMillan, RPLS Austin TX

Post reply

13667 views

link

Thanks Kent, that makes sense.

I didn't notice before that you had a vector from Pt 10 to Pt 10day190. I saw the 0,0,0 part I just didn't see the vector which is obvious now that I see it. I see you have !!! for the fixed OPUS solution.

Post reply

13608 views

link

BTW as a footnote, when I wrote:

If you have more than one OPUS solution on Pt. 10, then you assign the different OPUS solutions names other than "10".

I should have mentioned that the technique should be used even when you only have one OPUS solution on a point. That way, you can propagate the uncertainty estimates in the OPUS-derived position through the network connected to the point and, if somewhere else in the network other OPUS-derived positions are connected, use the network measurements and observations as conditions for the adjustment of the OPUS-derived positions.

So if all you have is one OPUS position on "10", you still generate a vector of nominally zero length from a point "10a", "10Day272", or whatever to Point "10" and pin the network to Point "10" and its uncertainties.

--
Best regards,
Kent McMillan, RPLS Austin TX

Post reply

13179 views

link

As far as I know, TBC supports all the older recievers and also Rinex...

--
"Make them enchiladas greasy, make them steaks chicken fried...sure does make a man feel happy to see white gravy on the side..."
Guy Clark

Post reply

12426 views

link

OK that's new since the last time I went there. They used to just have everything on a public FTP, no login required.

They still do: GNSS Solutions v3.60.

--
Jim Frame
Frame Surveying & Mapping
609 A Street
Davis, CA 95616

Post reply

13961 views

link

Cool. :-)

I like GNSS Solutions but I haven't used it in a long time. Even TGO only processes the L1 only on shorter static vectors.

Post reply

13848 views

link

Thanks, Jim. Looks like I'll be plugging away at learning Ashtech tomorrow. The field work on the 15th is due Monday. Helloooo Ashtech, Goodbye Trimble.

Post reply

13416 views

link

OK that's new since the last time I went there. They used to just have everything on a public FTP, no login required.

They still do: GNSS Solutions v3.60.

I just downloaded the program from your hotlink but the program won't open. What program does one use to open it up.

Also I went onto the Ashtech website but where is the download for the program?

Post reply

13218 views

link

After doing a bit of research, I see that Trimble Business Center (what a Donald-Trump-sounding name) comes in two versions, the Standard, which will only process L1 GPS vectors, and the Advanced, which handles multi-frequency processing. The price I was quoted was about three grand, but I didn't know to ask which version was being quoted.

I got a quote from my local dealer in March: $2,995 for Advanced.

--
Jim Frame
Frame Surveying & Mapping
609 A Street
Davis, CA 95616

Post reply

13959 views

link

The Advanced version is $3000.... Standard is $500

--
"Make them enchiladas greasy, make them steaks chicken fried...sure does make a man feel happy to see white gravy on the side..."
Guy Clark

Post reply

12452 views

link

The Advanced version is $3000.... Standard is $500

Thanks, Tom. Since most of my work is L1-only, the Standard version ought to do the trick. To save my hair, I'm planning on carrying of with my long habit of simply using the Trimble software to process vectors and exporting the vectors to Star*Net for adjustment.

Do you happen to know what formats TBC uses for its vector solution files? I assume that they aren't .ssf and .ssk files.

--
Best regards,
Kent McMillan, RPLS Austin TX

Post reply

12379 views

link

You can download and run the L1 version of GNSS solutions for free. I don't know how much an L1/L2 license costs:

I don't often use GNSS Solutions -- I'm just more familiar with TGO -- but I decided to see if it had a similar problem. It didn't, and processed the test vector just fine.

In the process I was reminded of just how easy Solutions makes incorporating CORS data into a network. It's pretty much a push-button operation: tell it which CORS and the desired time window, and off it goes, downloading the data automatically. It even gets the precise orbits and clock files if you have your processing style set up for it. Very slick.

--
Jim Frame
Frame Surveying & Mapping
609 A Street
Davis, CA 95616

Post reply

13969 views

link

Has anyone tried the patch download at the trimble site yet? Has it worked to fix this?

Trimble

Post reply

14104 views

link

That download is years old and has nothing to do with this. BTW, after reading this I grabbed a couple of random UFCORS RINEX files from yesterday and they would not process today in TGO. I have TBC, but I would think Trimble has some explaining to do as I know alot of folks that still use(and like, including me) TGO.

Post reply

14074 views

link

Some us old dogs might need to learn new tricks! Kinda sucks for sure!

Post reply

14077 views

link

Just thinking out loud ...
I have no experience with the data format of rinex files ... but it's ascii.
Is it possible to change the time stamps in the Rinex files so they keep synchronised but with a valid time stamp that TGO will process??

chr.

Post reply

13656 views

link

Good thought. I don't work with RINEX files very much but Loyal Olsen does so maybe he can shed so light? I talked with my favorite Trimble Trainer and he assured me that Trimble was working on a solution. Let's hope they post a fix soon.

Post reply

13619 views

link

I have no experience with the data format of rinex files ... but it's ascii.
Is it possible to change the time stamps in the Rinex files so they keep synchronised but with a valid time stamp that TGO will process??

I don't know enough about the way carrier phase data is handled in a baseline processor to offer a definitive comment, but I believe that any workaround that alters observation times would be awfully complicated. You'd not only have to manipulate the observation files, but the orbit file(s) as well. My seat-of-the-pants assessment is that it's not a practical solution.

--
Jim Frame
Frame Surveying & Mapping
609 A Street
Davis, CA 95616

Post reply

13613 views

link

As a test of the reported problem, this afternoon I downloaded 24 hr dual frequency data sets in RINEX 2.11 format from Canadian Active Control points in Penticton (DRAO), Priddis (PRDS), and Saskatoon (SASK) observed yesterday (Friday September 16th).

I imported them into a TGO 1.63 project - note that TGO converts the RINEX files into DAT format during import.

I used the default GPS processing parameters to compute baselines. No problems. The processing worked flawlessly.

I have the software running on a Windows 7 Pro 64-bit system.

Seems like something else is going on here...

--
Ex tenebris ad lucem

LinkedIn profile http://www.linkedin.com/in/scottpartridge

Post reply

13559 views

link

Can you try a second processing session? I processed two points from the 15th and it worked fine. Then after reading all the posts I tried to process a second set today (the data was also from the 15). It did not work. Each time I tried, the processor started working and would hang up and give me an error message. I also downloaded and ran all the latest "fix" programs from Trimble for v1.63 and that didn't help.

Post reply

13477 views

link

I tried again with 24-hour data from CORS LNC1 and P271 from the 15th. The WAVE processor hung and, when I checked a couple hours later, was still hung. I had to shut it down.

I'll try the Canadian data to see if I get different results.

--
Jim Frame
Frame Surveying & Mapping
609 A Street
Davis, CA 95616

Post reply

13450 views

link

Jim I'll try CORS data from the 15th and 16th.

I wonder if this is related to the recent NGS changes in the CORS data?

--
Ex tenebris ad lucem

LinkedIn profile http://www.linkedin.com/in/scottpartridge

Post reply

13445 views

link

I wonder if this is related to the recent NGS changes in the CORS data?

I'm going to guess not, Scott. I hit similar problems processing .dat files that I'd collected in the field. The problems began with the data from Day 257. Files from Day 256 and before processed just fine (using the WAVE 2.35a processor in GPSurvey), but nothing other than code phase solutions was possible with sessions from 257 or after.

The error logs indicated that the problem was with certain modules in the software. It wasn't the data.

--
Best regards,
Kent McMillan, RPLS Austin TX

Post reply

13426 views

link

I downloaded files for DRAO, PRDS and SASK for JD258, and all processed without incident.

The plot thickens...

--
Jim Frame
Frame Surveying & Mapping
609 A Street
Davis, CA 95616

Post reply

13420 views

link

I had data from the 15th, wouldn't process a L1 PPK session. Crap. If Trimble doesn't provide a free patch, bye bye Trimble. Ashtech, Leica, Topcon here I come.

Post reply

13418 views

link

I just successfully processed a vector between P271 and VTD7, both CORS. This was a 4,000 km line. It's looking like the problem kills short baselines, but not long ones.

--
Jim Frame
Frame Surveying & Mapping
609 A Street
Davis, CA 95616

Post reply

13414 views

link

I just successfully processed a vector between P271 and VTD7, both CORS. This was a 4,000 km line. It's looking like the problem kills short baselines, but not long ones.

It was a *float* solution, may we assume?

--
Best regards,
Kent McMillan, RPLS Austin TX

Post reply

13412 views

link

I just reran my sessions from Days 257 and 258, but set up the processor controls (in GPSurvey 2.35a) to force the float solution as the final solution quality on the short (3km) baselines. The processor computed float solutions. It's the fixed integer solution that is causing things to blow up, apparently.

--
Best regards,
Kent McMillan, RPLS Austin TX

Post reply

13373 views

link

If you want to explore Christ's idea, send me the two files you are playing with (RINEX .11o & .11n), and I'll "drop them back" a year and shoot them back to you. I have NO IDEA whatsoever if it will work, but what the heck, it can't hurt anything.

Loyal

Post reply

13278 views

link

Loyal
That would be great if you tried changing the date. I would suggest just grabbing a couple CORS files and try it. If it works, I trust you will share your methodology? please.

Post reply

13214 views

link

I could of course do that, but my copy of GPSurvey (WAVE) is on my OLD laptop, and I am kinda up to my butt right now in REAL work (besides which, I'm not even sure where the sucker IS).

Although changing the "dates" in the .11o & .11n files isn't particularly difficult, is DOES require a GOOD understanding of the RINEX file format, and is NOT WITHOUT a few booby-traps!

Besides which, I'm NOT really sure if that would actually work (I suspect that it "MIGHT" though)...

Loyal

Post reply

13198 views

link

Well,
If it could solve the problem I'm willing to help,
I'm thinking of a little program that converts all the necessary timestamps to a new date that will process in TGO,
as stated before I have no experience with the format off the Rinex data itself, someone will have to point my nose in the right direction.
Changing the ascii file is not such a big deal if you know what to change ...

chr.

Post reply

13179 views

link

Loyal
I was refering to trying the date change then processing with TGO rather than GPSurvey. Like Christof said below, editing a text file is easy, knowing what and where to edit is the secret.

I understand being busy. I'm in the middle of putting a new wax ring under our toilet. I figure I'm dealing with crap whether it is toilet or TGO at this point!

Post reply

13159 views

link

Although I have a copy of TGO around here somewhere, I never liked it, and finally deleted it from my computer (the same OLD Laptop), but continued running GPSurvey for several years (still do from time to time).

If someone who HAS TGO, wants to Email me a couple of RINEX files, I'll "do the deed" and send them back to see what happens (if anything).

Loyal

Post reply

13125 views

link

Loyal
I'll try attaching two files for stations CABL and DDSN. If I am not able to attach them here I'll send them directly to you via email. Thanks for try to help. I'll try to process your edited files in TGO.

Edit- well looks like I'll send them via email. Couldn't attach them here.

Post reply

13051 views

link

Well...they say that cheaters never win, and they are probably right in this case.

As I had feared (and Jim Frame indicated), the problem is probably in the Navigation File (Time & timing). So far, NO JOY, and I'm not sure how comfy I would be with a kludge like this anyway.

If I have a little more "time" later (pun intended), I'll play around with it some more now that I have a couple of files.

:(
Loyal

Post reply

12916 views

link

It was a *float* solution, may we assume?

Yep. I've never processed a vector that long before, and just assumed that iono-free float was the norm for that distance. When I processed the vectors from VTD7 to both LNC1 and P271 (both 4,000 km lines) in GNSS Solutions, one solved as float, the other as fixed.

--
Jim Frame
Frame Surveying & Mapping
609 A Street
Davis, CA 95616

Post reply

13245 views

link

I always knew that Trimble was arrogant, I just never realized that they would be this arrogant. To think of all the money I've poured into Trimble all these years.

Post reply

13427 views

link

this is an extract of wave.log found in ..\Baseline Processing directory of a TGO project:

WARNING /////////////////////////// WARNING //////////////////////////// WARNING
TRACE : Error at Line 106 in File (ambmngr)
TRACE : Error at Line 747 in File (ambmngr)
TRACE : Error at Line 754 in File (modmngr)
TRACE : Error at Line 197 in File (modmngr)
Processing time 21 seconds
TRACE : Error at Line 970 in File (D:\Wave\crstcntl\STATSOLV.C)
TRACE : Error at Line 1030 in File (D:\Wave\crstcntl\STATSOLV.C)
TRACE : Error at Line 269 in File (D:\Wave\crstcntl\STATNET.C)
Error: 101, Processing error occurred

Same output is generated by both WAVEs: GPSurvey's and TGO's.

They should probably just change int to double for a variable(s) that hold time in those *.c files and recompile :)

Yuriy

Post reply

13332 views

link

float solution can be saved in my case as well, so only fixed ones are affected.

Post reply

13301 views

link

How much are y'all paying for a subscription for updates on TGO? I lost my TGO media during a move and was told I'd have to pay for a subscription just to get a replacement copy or download of the media.

--
www.willisengineering.com

Post reply

13296 views

link

WARNING /////////////////////////// WARNING //////////////////////////// WARNING
TRACE : Error at Line 106 in File (ambmngr)
TRACE : Error at Line 747 in File (ambmngr)
TRACE : Error at Line 754 in File (modmngr)
TRACE : Error at Line 197 in File (modmngr)
Processing time 21 seconds
TRACE : Error at Line 970 in File (D:\Wave\crstcntl\STATSOLV.C)
TRACE : Error at Line 1030 in File (D:\Wave\crstcntl\STATSOLV.C)
TRACE : Error at Line 269 in File (D:\Wave\crstcntl\STATNET.C)
Error: 101, Processing error occurred

Same output is generated by both WAVEs: GPSurvey's and TGO's.

For the record, GPSurvey 2.35 generated the following error log from trying to process L1 sessions under open sky on Day 258 (omitting the "WARNING /////" message):

TRACE : Error at Line 104 in File (ambmngr)
TRACE : Error at Line 743 in File (ambmngr)
TRACE : Error at Line 680 in File (modmngr)
TRACE : Error at Line 179 in File (modmngr)
TRACE : Error at Line 631 in File (kinsolv.c)
TRACE : Error at Line 1158 in File (kisolv.c)
TRACE : Error at Line 334 in File (kinnet.c)

--
Best regards,
Kent McMillan, RPLS Austin TX

Post reply

13251 views

link

"Arrogant' might be a harsh term here, after all TGO is a product that is already several years past 'end-of-life' in software development terms.

It may be possible to build a temporary patch, but that will only delay the inevitable in my opinion. What other hurdles would have to be jumped for it to be fully Windows 7 compatible? For example, the Feature Code Editor in TGO doesn't work in Windows 7 (unless you are the computer administrator) without using a third party fix.

If Trimble issues a patch for current TGO users, that would be a nice gesture but it would be akin to fixing the transmission of a car so you can drive it to the scrap yard. A really nice car...

After working with TBC 2.50, even hard core TGO users that I have talked to about the change say that once you get past the learning curve, it is a great tool.

--
Ex tenebris ad lucem

LinkedIn profile http://www.linkedin.com/in/scottpartridge

Post reply

13176 views

link

did trimble do this intentionally, or did something unforeseen change?

--
www.willisengineering.com

Post reply

13139 views

link

did trimble do this intentionally, or did something unforeseen change?

Obvious design problem with the software.

Also I was able to finally download the Ashtech stuff (musta done something wrong on download), we'll see if she works tomorrow.

Post reply

13045 views

link

"Harsh?" If they would have said five years ago the equipment would last five years I never would have bought it, nor would others. How many cars would Toyota sell if all Toyotas quit functioning all at one time in five years?

Post reply

13128 views

link

In regards of processing data from older Trimble GPS systems, how far back does TBC goes? Which model is the cutoff? 5800? 5700? 4700? 4600, etc...?

Post reply

13003 views

link

In regards of processing data from older Trimble GPS systems, how far back does TBC goes? Which model is the cutoff? 5800? 5700? 4700? 4600, etc...?

If someone buys a car that has a design flaw the manufacturer fixes the flaw. Simple. Lucky for me Ashtech software works. It doesn't pay to buy Trimble as apparently they can pull the rug out from under you at any moment.

Post reply

12975 views

link

Leica's current software only supports data from receivers back to the 399's, 299's are a no go, of course 399's date from around 1995, so 299's would be a pretty old unit, I think early 1990's.

Doesn't help the current situation with TGO, but just wanted to point out that most brands seem to put older equipment and software out to pasture.

Of course, the old software and equipment still works together, you just can't read the old data files with new software, so maybe a bit of a different situation than just plain not working.

I will say a few years ago, Leica came out with a fix within just a few days when the 500's which were way out of production quit working, I think it had to do with a new SV being turned on or something.

SHG

Post reply

12911 views

link

5800? 5700? 4700? 4600, etc...? I did not work with TBC for too long but it is possible to convert the above receiver data to RINEX and than load in TBC. Not sure if 5800 4600 antenna models are supported in TBC though...

Post reply

12695 views

link

I spoke with my trimble rep this morning at Western Data Systems. He is unaware of this but indicated that he would speak to Trimble today. Should I find anything that helps me, I will pass it along to everyone else.

For today, I'm having to take all of my infill shots from last week (John Francis moment) and convert them all to an OPUS-RS solution since I can't process the SOB's.

Here's to another cup of coffee and about 3 hours out of my day that I hadn't planned on.

Wendell, if you could sticky this, I would appreciate it. This is a HUGE hurdle to overcome and not buy the 3k software.

--
"You don't have to be a good surveyor if you find all the corners."

Kris

Post reply

12426 views

link

Same thing with my Trimble rep. Apparently all were caught unaware.

He did offer a temporary fix. TBC can be had on a free 30 day trial so you might be able to use that until Trimble solves the problem.

Now this is my personal opinion and nothing else, but I'd bet the "fix" will be to offer TGO users an upgrade to TBC at some reduced rate. Time will tell if my guess is correct.

Post reply

12333 views

link

I agree. I had the same offer.

I just spent my morning inventing new physics to process THREE points!!!! That GOD for Opus-RS and dual frequency receivers and my crew having the freaking thought pattern to wait on the point long enough.

FINALLY have my points in and my traverse between them adjusted. What SHOULD have taken MAYBE an hour has cost me 4 1/2 hours. THANKS A HELLUVA LOT TRIMBLE!!!!!!!

--
"You don't have to be a good surveyor if you find all the corners."

Kris

Post reply

12217 views

link

Want to take bets on whether or not Trimble has lost the source code to their program and that's why they can't/won't make a patch?

Post reply

12048 views

link

An interesting hypothesis...the code must be 15+ years old in a programming language likely not in common usage anymore.

While I am going to bet that given the size of the problem Trimble will be motivated to fix it, I wouldn't hazard a guess on how long it might take.

Maybe they need to hire Mike Potterfield (just like Clint Eastwood in Space Cowboys) to fix an antiquated system.

--
Ex tenebris ad lucem

LinkedIn profile http://www.linkedin.com/in/scottpartridge

Post reply

12003 views

link

Trimble processing software quit working once before and I can't remember if it was Y2K or the GPS clock rollover. Whichever it was the only solution trimble offered was to upgrade GPSurvey/Trimmap to TGO. The solution worked and in the longrun was OK because I think TGO was a much better product but at the time it seemed wrong for them to dump what was a $14.5K software package without fixing it. I can say that since upgrading to TGO I have not bought a single Trimble product.

Post reply

12114 views

link

Trimble processing software quit working once before and I can't remember if it was Y2K or the GPS clock rollover. Whichever it was the only solution trimble offered was to upgrade GPSurvey/Trimmap to TGO. The solution worked and in the longrun was OK because I think TGO was a much better product but at the time it seemed wrong for them to dump what was a $14.5K software package without fixing it.

Actually, GPSurvey was still working just fine until the billionth GPS second arrived a few days ago. To their credit, Trimble posted a Y2K patch for GPSurvey that worked perfectly well and has made updated receiver.ini and antenna.ini files available for download to keep it pretty much rocking along. In fact, the various patches worked so well that the version of GPSurvey I had originally bought as an L1-only version became an L1/L2 version, which was an unexpected dividend.

--
Best regards,
Kent McMillan, RPLS Austin TX

Post reply

11793 views

link

An emergency solution:

Transform raw data files to Rinex format.
Edit Rinex files and change:

1) Substract year by 6. Example: 2011 by 2005.
2) Substract GPS week by 313. Example: 1654 by 1341
3) Save and process with GPSurvey or TGO.
4) Edit baseline report ascii file and change again 2005 by 2011.
5) Dont send me to go to hell. It´s works.

The reason: base time in GPS architecture is GPS week and GPS second.
01/Jan/2011 and 01/01/2011 were Saturday.
Processing software do the same time differences.
ASHTECH raw data files (B*.* and E*.*) has only week number and seconds. Year only appear in filename and is not used.
Therefore Result are correct.

Example: GPS rinex file in date 24/Sep/2011, GPS week 1654
Change in Rinex observation files:

replace "11 9 24" by "05 9 24"
and 2011 by 2005 in Rinex record Time of First obs and Time of last obs

Change in Rinex navigation file:
replace "0.156400000000D+04" by "0.134100000000D+04"
replace "11 9 24" by "05 9 24"

Avoid change columns position of the data to avoid corrupt file.

SAVE AND PROCESS. Excuse my (bad) english.

Post reply

11010 views

link

Dario
Thanks for posting this solution.

Editing the obs file is simple enough and can be done quickly but I'm not sure about the nav file. I believe the date and time appears following the satellite number on multiple lines throughout the file. It would be a time consuming error prone task to change all of the time references by hand.

I am not real familiar with rinex files so I might be misinterpreting what you have said. You have shown some examples but could you post examples of actual unedited and edited files? Just the first page of both file types would be a big help.

A few of us here are trying to solve the same problem so if you want to send me anything direct by email my address is johnminor@stuntzner.com

Post reply

10923 views

link

Of course is an emergency solution but it works.
I tested this procedure many years ago when Y2K and tested now again with actual data processing with GPSurvey and TBC 2.40.
You dont have to do by hand. You can do with a replace command with a text editor.
I use Kedit.exe (mansfied software)for example.

But You can edit Rinex observation files with MS Word and
replace the string "yy mm dd" for the new year zz "zz mm dd".
Doing this way avoid to wrong replace other records.

Example:
*** top of original file ***
2.11 OBSERVATION DATA GPS(GPS) RINEX VERSION / TYPE
cnvtToRINEX 2.11.0 convertToRINEX OPR 26-Sep-11 01:42 UTC PGM / RUN BY / DATE
----------------------------------------------------------- COMMENT
pf05 MARKER NAME
pf05 MARKER NUMBER
GNSS Observer Trimble OBSERVER / AGENCY
0220394038 5700 2.30 REC # / TYPE / VERS
TRM39105.00 ANT # / TYPE
2269096.2347 -4707251.6902 -3645061.1470 APPROX POSITION XYZ
-0.0460 0.0000 0.0000 ANTENNA: DELTA H/E/N
1 1 0 WAVELENGTH FACT L1/2
4 C1 L1 L2 P2 # / TYPES OF OBSERV

2011 9 24 17 2011 9 24 21 0 15 14 G02 1608 1608 1608 1608 G04 1320 1320 1320 1320 G05 1991 1991 1991 1991 G07 2741 2741 2741 2741 G08 2741 2741 2741 2741 G10 2741 2741 2741 2741 G13 2316 2316 2316 2316 G15 71 71 71 71 G16 966 966 966 966 G17 17 17 17 17 G20 672 672 672 672 G23 1398 1398 1398 1398 G26 1283 1283 1283 1283 G28 1751 1751 1743 1743 CARRIER PHASE MEASUREMENTS: 11 9 24 17 53 20.0000000 23718707.88316 -128282.81616 21783243.82017 -59758.25417 20663161.58617 -142830.97717 22355029.60216 -205132.28516 22172453.64817 -180603.31317 20814699.96117 -43334.47717 23459459.08616 -81225.22716 22290204.85216 38346.38716 11 9 24 17 53 25.0000000 ...... 53 20.0000000 GPS TIME OF FIRST OBS
41 40.0000000 GPS TIME OF LAST OBS
RCV CLOCK OFFS APPL
LEAP SECONDS
# OF SATELLITES
PRN / # OF OBS
PRN / # OF OBS
PRN / # OF OBS
PRN / # OF OBS
PRN / # OF OBS
PRN / # OF OBS
PRN / # OF OBS
PRN / # OF OBS
PRN / # OF OBS
PRN / # OF OBS
PRN / # OF OBS
PRN / # OF OBS
PRN / # OF OBS
PRN / # OF OBS
PHASE SHIFTS REMOVED COMMENT
END OF HEADER
0 9G02G04G07G08G10G13G16G20G23
-86635.43456 23718707.46156
-40257.66058 21783244.89158
-94665.37159 20663160.85959
-136702.35557 22355032.02357
-119245.63758 22172454.06658
-28570.57058 20814698.83658
-53644.24257 23459459.13757
24992.47357 22290205.37157
0 9G02G04G07G08G10G13G16G20G23

*** end of original file ****

*** top of modified file***
....
2005 9 24 17 53 20.0000000 GPS TIME OF FIRST OBS
2005 9 24 21 41 40.0000000 GPS TIME OF LAST OBS
....
05 9 24 17 53 20.0000000 0 9G02G04G07G08G10G13G16G20G23
23718707.88316 -128282.81616 -86635.43456 23718707.46156
21783243.82017 -59758.25417 -40257.66058 21783244.89158
20663161.58617 -142830.97717 -94665.37159 20663160.85959
22355029.60216 -205132.28516 -136702.35557 22355032.02357
22172453.64817 -180603.31317 -119245.63758 22172454.06658
20814699.96117 -43334.47717 -28570.57058 20814698.83658
23459459.08616 -81225.22716 -53644.24257 23459459.13757
22290204.85216 38346.38716 24992.47357 22290205.37157
05 9 24 17 53 25.0000000 0 9G02G04G07G08G10G13G16G20G23
.....
***end of modified file ***
Save as text without format.

Rinex navigation file is a little more complicated:

*** top of original file ****
2.10 NAVIGATION DATA GPS(GPS) RINEX VERSION / TYPE
cnvtToRINEX 2.11.0 convertToRINEX OPR 26-Sep-11 01:42 UTC PGM / RUN BY / DATE
----------------------------------------------------------- COMMENT
0.2235D-07 0.1490D-07 -0.1192D-06 -0.1192D-06 ION ALPHA
0.1290D+06 0.0000D+00 -0.2621D+06 0.2621D+06 ION BETA
0.186264514923D-08 0.888178419700D-14 147456 119 DELTA-UTC: A0,A1,T,W
15 LEAP SECONDS
END OF HEADER
4 11 9 24 17 59 44.0 0.240915920585D-03 0.111413100967D-10 0.000000000000D+00
0.130000000000D+02 0.535312500000D+02 0.501806616545D-08-0.126826539319D+01
0.280328094959D-05 0.982764875516D-02 0.106766819954D-04 0.515371054268D+04
0.583184000000D+06 0.290572643280D-06-0.300198193401D+01 0.391155481339D-07
0.938435309575D+00 0.160062500000D+03 0.768060242026D+00-0.823105714228D-08
0.431089385175D-09 0.100000000000D+01 0.165400000000D+04 0.000000000000D+00
0.240000000000D+01 0.000000000000D+00-0.651925802231D-08 0.130000000000D+02
0.582792000000D+06 0.400000000000D+01 0.000000000000D+00 0.000000000000D+00
7 11 9 24 18 0 0.0 0.283662229776D-04 0.193267624127D-11 0.000000000000D+00
....
*** end of original file ****

In red is the GPS week number.
You have to replace week number 1654 by 1341, that is substract 313 to actual gps week number.
so edit with MS Word and do two replace:
1) Replace "0.165400000000D+04" by ""0.134100000000d+04"
2) Replace "11 9 24" by "05 9 24"
Doing this way avoid do other incorrect replacements.

*** top of modified file ***
2.10 NAVIGATION DATA GPS(GPS) RINEX VERSION / TYPE
cnvtToRINEX 2.11.0 convertToRINEX OPR 26-Sep-11 01:42 UTC PGM / RUN BY / DATE
----------------------------------------------------------- COMMENT
0.2235D-07 0.1490D-07 -0.1192D-06 -0.1192D-06 ION ALPHA
0.1290D+06 0.0000D+00 -0.2621D+06 0.2621D+06 ION BETA
0.186264514923D-08 0.888178419700D-14 147456 119 DELTA-UTC: A0,A1,T,W
15 LEAP SECONDS
END OF HEADER
4 05 9 24 17 59 44.0 0.240915920585D-03 0.111413100967D-10 0.000000000000D+00
0.130000000000D+02 0.535312500000D+02 0.501806616545D-08-0.126826539319D+01
0.280328094959D-05 0.982764875516D-02 0.106766819954D-04 0.515371054268D+04
0.583184000000D+06 0.290572643280D-06-0.300198193401D+01 0.391155481339D-07
0.938435309575D+00 0.160062500000D+03 0.768060242026D+00-0.823105714228D-08
0.431089385175D-09 0.100000000000D+01 0.134100000000D+04 0.000000000000D+00
0.240000000000D+01 0.000000000000D+00-0.651925802231D-08 0.130000000000D+02
0.582792000000D+06 0.400000000000D+01 0.000000000000D+00 0.000000000000D+00
7 05 9 24 18 0 0.0 0.283662229776D-04 0.193267624127D-11 0.000000000000D+00
.....
***end of modified file ***

Save the file as text without format.

Avoid moving data position. Rinex is a formatted file. This cause corrupt file.

You have to be careful with this solution after 29Feb2012, a leap-year, because you have to choose 2007 instead of 2006 and you have to substract 261 to GPS week number instead of 313 now.

March, 01, 2007 (week 1677) and March, 01, 2012 (week 1416). both are thursday, that is day of week 4. GPS second into their week are equals.

Obviously, if you try to process this GPS data with real 2005 GPS data, you will get an explosion.

Regards.
Dario,
Buenos Aires.

Post reply

10890 views

link

Sorry. seems to blank space dissapear.
Dario

Post reply

10881 views

link

Dario,
many thanks for the insight ...

In the header of the nav file is another GPSweek nr. that I changed the same way,

some screenshots of the edited fields.

the obs file

[image]

the nav file

[image]

chr.

Post reply

10857 views

link

Things look promising. Dario, Christof, Loyal and I have been working on rinex files from day 258 sta DDSN and CABL.
I have processed the edited data in both TGO and TBC then the unedited data in TBC (of course the unedited data will not process in TGO) Now we need to compare the results but the good thing is that the edited data now processes in TGO.

Post reply

10833 views

link

Hello everybody,

Thanks Dario for your trick !
So, I've got some strange things when modifying rinex files. TGO now accept to open and process base lines, but return an incredible Varref (reference variance) for some post processed points. I've got 2 187 369 meters !!!

Some points are not affected by any error during the base line proccess, but I've found that the coordinates are exactly the same before and after base line processing.

Is somebody got the same problem ?
I didn't found the solution a this time, but I'll keep you in touch in the furtur.

PS : I apologie for my bad english.

Terry

Post reply

10194 views

link

The apparent problem is that GPS time reached 1 billion seconds since 1980...
WHY since 1980??? GPS system is used by surveyors from cca 1993, TGO is software for Win XP and Windows XP exists since 2001...
What's this bug from TRIMBLE??? :-(

Post reply

10138 views

link

According to computers, the world began Jan 1, 1980. Computers count time in seconds beginning on that date. If you remember, all DOS programs using time use seconds beginning at 12:00 am Jan 1, 1980.

--
David A. Lee, PS

"Knowledge has to be improved, challenged, and increased constantly, or it vanishes." - Peter Drucker

Post reply

10125 views

link

Thanks for your reply. But TGO is not DOS program. And ... why other softwares (in this issue: TBC, GNSS Solutions) are OK?
I try another DOS programs and - no problem, they are functional.
We work with satelites and we must "manually" editing rinex files (6y, 313m) and give thanks not to Trimble's techniks but to Dario Canosa for emergency solution...
I don't know if it is good Trimble's business strategy :-S

Post reply

10110 views

link

GPS time is measured in weeks and seconds of week. week zero was 1/5/1980. I think it is pure coincidence that computers default to 1/1/1980.

I started using GPS in 1986, not 1993. And there were static jobs done as early as 1984.

Post reply

10052 views

link

WHY since 1980??? GPS system is used by surveyors from cca 1993, TGO is software for Win XP and Windows XP exists since 2001...

TGO uses the WAVE baseline processor that was also used in GPSurvey, and possibly even earlier applications. The code base was probably transplanted into TGO with as few modifications as possible, with no consideration given to the possibility that some of the variables didn't have a large enough memory allocation to handle time values in excess of 10^E9. That's my surmise, anyway.

--
Jim Frame
Frame Surveying & Mapping
609 A Street
Davis, CA 95616

Post reply

10034 views

link

The WAVE processor is based in the original TRIMVEC code that we used in the late 1980s first as DOS command line launched and later in the Windows 3.1 shell.

--
"We the willing, led by the unknowing, have been doing the impossible, for the ungrateful. We have been doing so much, with so little, for so long, that we are now qualified to do anything with nothing."

Post reply

10027 views

link

NAMRIA ano masabi nyo?

Post reply

8586 views

link

Sheen....

Pwde po ba kayo mag salita n wikang english kasi hindi ako nakaka-intindi ng tagalog..If u dont Mind..salamat. :-)

--
Happy 2013!! May your lotto ticket win ya millions!!!
Daryls News Page
http://flakelist.org ◄ THE BEST scam reporting site out there!! B-)

Post reply

8567 views

link

dili ko kasabot sa imo giingon angel

Post reply

8549 views

link

dili ko kasabot sa imo giingon angel

To: Mr Sheen Suba.. What I mean to my messages is, Pwde ba kang mag-eninglish kay dli ko kasabot sa imohang dialect..Thank u again. Salamat. :-)

PS: If you can type in English, that would be much appreciated as our other users cannot understand you.

--
Happy 2013!! May your lotto ticket win ya millions!!!
Daryls News Page
http://flakelist.org ◄ THE BEST scam reporting site out there!! B-)

Post reply

8497 views

link

kaya man ni himoon nga multilingual sa umaabot nga panahon. Nianang panahuna mas ma-appreciate sa mga tao ang kalapad sa pagpadayag. ;-)

Post reply

8471 views

link

I have no idea if that was all in reply to my post, I have no jibberish translator. Angel seems to speak the lingo.

Post reply

8451 views

link

Part of it was....

NAMRIA ano masabi nyo? Translates to: NAMRIA, need I say more?

SO I explained to him that almost no one will know what he meant and asked him to talk in English, and said thanks. He said Angel I wont do that. (Smart alec!!) So I explained to him that no one here understands tagalog dialect...and he thinks that you guys should and it should be multi cultural, and again is being a smart alec. I'm beginning to wonder if he's a spammer??? :-|

--
Happy 2013!! May your lotto ticket win ya millions!!!
Daryls News Page
http://flakelist.org ◄ THE BEST scam reporting site out there!! B-)

Post reply

8439 views

link

what language?, I thought it was a spoof...

Post reply

8402 views

link

what language?, I thought it was a spoof...

No, he's speaking in Filipino. And starting to be a smart ass. He wants you guys to also speak in Filipino, but doesn't want to speak in English. :-|

--
Happy 2013!! May your lotto ticket win ya millions!!!
Daryls News Page
http://flakelist.org ◄ THE BEST scam reporting site out there!! B-)

Post reply

8383 views

link

Hey Ricky,

I just uploaded something I have been fooling with and you guys are most welcome to give it a try. It will subtract the 5 or 6 years from the RINEX files. You can get it from http://teqc.silkwerks.com It also runs TEQC from a menu interface. I make no guarantees or warranties.

I wouldn't mind spending some more time enhancing this if folks sent me in suggestions.

Just unzip it in a folder and she should start working without installation. I am running it on Windows 7 and have tested it on Windows XP.

I don't even have TGO anymore so I can't test the output RINEX with the WAVE Processor.

Mark W. Huber
USACE-AGC

Post reply

5216 views

link

Back to the forum index

RSS Feed of thread

Trimble Geomatics Office (TGO) Processing Issue (Land Surveying)