Then I'd raise billy hell with them to let you d/l convert2rinex. In fact, you MAY have it on a disk. The version I use is the same one from when I had TGO, so it may be there in the dust.
So, what I meant with the Glonass was that our R8's can use GLONASS, but TGO couldn't process it. So, we have one style (RKT&Infill) that we crank the base up with so it logs data and one style (RTK) that uses the Glonass SV's in the RTK solutions. It may not be a huge issue anymore since TBC "looks" like it uses those birds for processing. I will defer to John Hamilton or Loyal or other static guru's on that. My initial thought is that the *.t02 needs to be converted to rinex. The file should be quite large. The 5700 and earlier systems used a compression for base files and an 8 hour day was quite small. Not so much with the R8's. I think ours are R8 2's and not the 3's though.
As far as TEQC, I have never used the utility before, so I can't speak to it but convert2rinex works on my R8's and R10 static data for submission into whatever.
I suppose, as a last resort, you could d/l the data into TBC and then d/l CORS stations and process the data yourself and average the answers. It will be nearly the same answer (0.01').
Hope it helps Alan.
Paul in PA, post: 326437, member: 236 wrote: These receivers have been used successfully for years. First learn how to use them, then ask questions.
Where are you seeing a date in MM/DD/YYYY format, because it is not normal to use that format in RINEX?
RINEX looks for unambiguous formats such as YYYY/MM/DD HH/MM/SS This format guarantees that date/time always increments positively.
Paul in PA
I wasn't going to reply to this, but here it is:
I have been using GPS, mostly Trimble, since 1999. I consider myself, at the very least, to be a competent user. In the 16 years I have been monkeying with this stuff, I have rarely come across a hiccup that I couldn't research and solve. The handful of times that I have been stumped, I have come here because the wealth of knowledge is amazing. This is one of those times.
I have made it a habit to jump into threads that I could positively contribute to, and to stay out of the ones that I can't; however, I never assume I know the user on the other end or their abilities. If I didn't provide you with the information you needed to help out, I apologize. You, on the other hand, could have simply asked for more info.
Paul is just grumpy. You kinda have to like old pissed off men otherwise, he always comes off poorly. 🙂
Dan Dunn, post: 326444, member: 911 wrote: TEQC will only convert a Trimble DAT file not the T02. OPUS will accept a DAT file directly.
Use a text editor and check the RINEX file for kinematic marker records, and remove them if any are found.
You don't say when you ran the session but sometimes waiting 48 hours after your last observation and then submitting to OPUS solves the noisy data issue.
Dan - I get the same error w/ the DAT file. With the 4700 I had as a base previously, I would just submit the DAT directly w/ no issue.
I did check for MARKER records - nada. I have also submitted it several times w/ the same result.
Thanks for the suggestions!
John Hamilton, post: 326448, member: 640 wrote: Alan...send me the raw file and I will look at it
also,
Use runpkr00.exe to convert the T02 file to tgd and or dat
to go to .tgd (recognizable by teqc): runpkr00 -d -g xxxxddds.t02
to go to a .dat file: runpkr00 -d xxxxddds.t02The tgd file has glonass and gps, dat file only has gps
John - my RTX solution, from the same day as your's referenced above (07/02), looked great. I did run a quick baseline from the closest CORS as a check, but only ran it to see if it would actually process. I did not analyze or compare.
I will give your other suggestion a shot in the next day or two, and thanks for your offer. The file is on it's way.
Norman Oklahoma, post: 326473, member: 9981 wrote: Trimble has a little free utility called "Convert to Rinex" which will easily convert your T02 files to Rinex. If you have TGO or TBC it's in their also.
Norman - for the life of me I can't find it in there! It used to come as a separate install.
Alan Chyko, post: 326564, member: 1145 wrote: John - my RTX solution, from the same day as your's referenced above (07/02), looked great. I did run a quick baseline from the closest CORS as a check, but only ran it to see if it would actually process. I did not analyze or compare.
I will give your other suggestion a shot in the next day or two, and thanks for your offer. The file is on it's way.
Alan: I responded to you by email, but I will post here as well for the benefit of others.
I brought the .t02 file into TBC (3.50). No problem. Correct date.
I used runpkr00 to convert to a .tgd file, then used teqc to convert that tgd to a rinex. Submitted to OPUS. Excellent results. Peak-to-peak were 0.005/0.003/0.014 (N/E/Z)
I believe the problem (you are using 3.30) is an older version of TBC. As I noted, it is significant to me that it was collected on the same day as my problematic RTX file.
As for the opus issue, it processed fine using the teqc converted file, which strengthens my belief that one should always use teqc rather than the manufacturer's program to convert.
I submitted to RTX, the H difference from OPUS was 0.012 m N, 0.014 m E, and 0.019 m in Z. So that is a good verification.
Still baffling to me that TBC would ever come up with a date before 1980. Even if week was set to 0, it would be in January of 1980.
Kris Morgan, post: 326559, member: 29 wrote: Then I'd raise billy hell with them to let you d/l convert2rinex. In fact, you MAY have it on a disk. The version I use is the same one from when I had TGO, so it may be there in the dust.
So, what I meant with the Glonass was that our R8's can use GLONASS, but TGO couldn't process it. So, we have one style (RKT&Infill) that we crank the base up with so it logs data and one style (RTK) that uses the Glonass SV's in the RTK solutions. It may not be a huge issue anymore since TBC "looks" like it uses those birds for processing. I will defer to John Hamilton or Loyal or other static guru's on that. My initial thought is that the *.t02 needs to be converted to rinex. The file should be quite large. The 5700 and earlier systems used a compression for base files and an 8 hour day was quite small. Not so much with the R8's. I think ours are R8 2's and not the 3's though.
As far as TEQC, I have never used the utility before, so I can't speak to it but convert2rinex works on my R8's and R10 static data for submission into whatever.
I suppose, as a last resort, you could d/l the data into TBC and then d/l CORS stations and process the data yourself and average the answers. It will be nearly the same answer (0.01').
Hope it helps Alan.
Understood. I've used TEQC quite a bit, and have never had this problem before, with our older equipment, or this new batch. Processing may very well be the way to go here. Thanks.
John Hamilton, post: 326569, member: 640 wrote: Alan: I responded to you by email, but I will post here as well for the benefit of others.
I brought the .t02 file into TBC (3.50). No problem. Correct date.
I used runpkr00 to convert to a .tgd file, then used teqc to convert that tgd to a rinex. Submitted to OPUS. Excellent results. Peak-to-peak were 0.005/0.003/0.014 (N/E/Z)I believe the problem (you are using 3.30) is an older version of TBC. As I noted, it is significant to me that it was collected on the same day as my problematic RTX file.
As for the opus issue, it processed fine using the teqc converted file, which strengthens my belief that one should always use teqc rather than the manufacturer's program to convert.
John - that's awesome. Thanks. One more thing to add to the to-do list for IT!
For what it's worth, I converted from the DAT to RINEX using WinTEQC Editor, looks like I will be jumping back to plain old TEQC.
Alan Chyko, post: 326562, member: 1145 wrote: Dan - I get the same error w/ the DAT file. With the 4700 I had as a base previously, I would just submit the DAT directly w/ no issue.
I did check for MARKER records - nada. I have also submitted it several times w/ the same result.
Thanks for the suggestions!
Alan,
Have you tried using the QC of TEQC? That may help identify where and what the problem is.
You could also try trimming off the first 2 hours to get past where you think the problem is and submit the remaining file to OPUS.
Good Luck
The silence from Trimble is deafening. I know there are people there who read this board (or there should be). I emailed the RTX people with my problem and got no response. I believe that the hiccup Alan describes is due to an older version of TBC, but it is not that much older.
I have been using Trimble gear exclusively since 1986, and a lot of different Trimble units since then. i know the .dat files very well, in fact i wrote a program around 1990 to read the RT17 data stream from Trimble receivers and create a .dat file and a rinex file on the fly (before they had a good program for logging at CORS). Yet the few times I have contacted them I am treated like a newbie...is your antenna connected...do you have power to the receiver...are you in an open location...
I have a lot of respect for their equipment and software, but of course bugs can always happen. I just don't appreciate their secretiveness about everything. Data formats? Sorry...proprietary. S6 total station commands? Sorry...proprietary. Job file formats?...sorry proprietary. TGO 1 billion seconds problem...oh no, that is out of date software.
Alan Chyko, post: 326565, member: 1145 wrote: Norman - for the life of me I can't find it in there! It used to come as a separate install.
I don't have either TGO or TBC currently at hand. But I do have Spectra Precision Survey Office, which is a TBC clone. In SPSO (and presumably under TBC as well) Under the File tab, choose TOOLS. It's there.
In the olden days, if you had TGO installed, you could highlight the T02 file in file explorer, then right click, and a context menu would pop up with a "Convert to dat" option. Try that.
Not sure whether I should start a new thread but I am also getting the "1879" error in TBC 3.4. This is from a Trimble .T02 file
I have converted to Rinex and the date looks correct there. When I import the RINEX file into TBC I also get the year as 1879.
Did anyone find out the cause of this. I have used this edition of TBC and this GOS receiver before successfully. I am also getting the same error on the rover file. (wrong century).
Sorry can't upload the data files but see screengrab.
squowse, post: 334770, member: 7109 wrote: Not sure whether I should start a new thread but I am also getting the "1879" error in TBC 3.4. This is from a Trimble .T02 file
I have converted to Rinex and the date looks correct there. When I import the RINEX file into TBC I also get the year as 1879.Did anyone find out the cause of this. I have used this edition of TBC and this GOS receiver before successfully. I am also getting the same error on the rover file. (wrong century).
Sorry can't upload the data files but see screengrab.
OK - an update to version 3.40.2 fixed it. (build 3.40.5497.19971)
I must have updated it on my laptop and only done static on that machine.
Paul in PA, post: 326472, member: 236 wrote: if you choose the hard way, why should others make your choice the easy road?
Because some of us like to help others out. If you want to continue playing the grumpy old man, fine, but don't assume everyone else wants to wallow in that with you.
squowse, post: 334773, member: 7109 wrote: OK - an update to version 3.40.2 fixed it. (build 3.40.5497.19971)
I must have updated it on my laptop and only done static on that machine.
Sorry for the late reply, but yes, the only option Trimble gave to fix the issue was the update. From my experience, 3.40 on seems to function fine.
