FixDatTGO update

John
My system won't allow me to download either of your update methods. I suspect it detects an exe file. This wasn't a problem with previous issues of your program. Christof and I got around this problem with his program by editing the extension to xyz.

Thanks. I used your program yesterday and it worked flawlessly.

Hi,

Thanks for your software, really appreciate it 🙂 I'm starting to use it but I'm getting a little suspicious results. I wanted to ask you if you have taken into account the leap year?

Second question, if I may ask, how do you read the dat files? What is their structure? Is this information published somewhere? I tried to google it but didn't find anything.

Regards
simon

Leap year should not matter. While I had to deal with various ways that different Trimble receivers store the date in the file, as I recall I was always dealing with the week number (and seconds of the week, which are not changed). I don't remember any of them actually using a date. So, using the week number would not be affected by leap year.

If you are having a problem, send me the original file and the modified file and I will look at it.

As for the formats, I obtained them many years ago when I was writing a program to convert the RT17 stream coming out of a receiver to RINEX and dat files (i.e. to store data from a CORS receiver), but I made a promise to not pass along the information unathorized. While I hate the fact that Trimble (and Leica, and others) are proprietary with this information, I gave my word. Because they are proprietary, I do not have T01 formats, nor any information about TBC formats, so I am locked out of doing anything with those.

Thanks for such a quick reply 🙂

The reason I'm asking about the leap year is because someone [msg=95978]here[/msg] is mentioning it and the "formula" is different before 29.02.2012 and after. But you are saying it doesn't matter? In that case we will look for the error somewhere else.

I'll try to explain our problem but I'm not a surveyor 🙁

We are measuring around 30 points and we have 3 stations with known coodinates. Baseline lengths are up to 2km. One of these stations has high precision height, the other 2 has lower precision height. When we fix the height of all 3 and do ajustment, we get a wide range of errors for height (I think up to ~30cm). When we fix the height for the high prec point only, then the calculated error is 15cm but the calulated heights of remaining two stations is correct. The lat & lon is correct all the time and has a very small error (few mm).

I don't recall such thing ever happen in the past (15+ years) but this is first time we use your software and I thought maybe it has something to do with it.

Thanks for the info about the formats. Can I ask one more thing since we have never used RINEX but sticked with DAT, are they the same thing just coded differently (the processed results will be exactly the same)?

Thanks again!
simon

RINEX is just a generic ascii format that many (most if not all) different receivers support. But, it uses actual dates and times, whereas a dat file uses the week number (since 1980) and the seconds of the week. So, the rinex solution does have a problem with the leap year, dat file should not.

The results SHOULD be the same whether using RINEX or dat. The rinex is simply an ascii representation of the measurement data inside the dat file. There can be some issues with cycle slip detection/reporting, but nothing major.

Hard for me to say exactly what the problem is with the control. I do not use TGO nor TBC to do the adjustment part, I use Geolab. I use the Trimble software only for processing the baselines. But, I will say that TGO AUTOMATICALLY turns on the tilts (and scale and azimuth biases as well) when there is a sufficient amount of control. For example, if you have two or more known H points, and three or more known elevations, and you fix them, it will solve for deflections of the vertical and scale and azimuth. This can be dangerous. I prefer to turn these parameters off. But, if you do leave them on, always look at them and make sure the values are reasonable. If you are using a geoid model, the tilts are the residual tilts left over after the model, and should be a few seconds or less. Ditto the scale and azimuth if you are using good control. I always solved for these parameters in the days before we had good geoid models, but now it is not necessary nor desired.

OK now its very clear 🙂
Thanks a lot for all the info and the tips. I'll have our surveyors check your suggestion.