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.
> 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?
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.
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:WavecrstcntlSTATSOLV.C)
TRACE : Error at Line 1030 in File (D:WavecrstcntlSTATSOLV.C)
TRACE : Error at Line 269 in File (D:WavecrstcntlSTATNET.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
float solution can be saved in my case as well, so only fixed ones are affected.
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.
Kent
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
> 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:WavecrstcntlSTATSOLV.C)
> TRACE : Error at Line 1030 in File (D:WavecrstcntlSTATSOLV.C)
> TRACE : Error at Line 269 in File (D:WavecrstcntlSTATNET.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)
> 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.
> > 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?
Kent
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.
John
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
John, Loyal
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.
"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.
I see said the blind man
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.
John
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!
did trimble do this intentionally, or did something unforeseen change?
"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?
John
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
John
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.
