We recently picked up a pair of used R8-3 receivers, and I am still getting acquainted with working with the additional data & different file types. Prior to this, i was using a 4700/4800 pair until we came upon a deal we thought was pretty good. Long story short, every time I submit the file from the base receiver to OPUS, after using the "RTK & Infill" survey style in Access and having the base receiver set up to collect on-board, I get the message "Internal format of XXXXXXXX.T02 could not be formatted to RINEX and ... is not supported." Are T02 files really not supported?
There is kind of an extension to this question - I have been using TEQC Editor (build 5.27.2015) to convert the T02 to RINEX; however, when I do that I get a whole string of errors like this:
! Warning ! TI-4100 ROM record 0x0000 has a length of 26 bytes (expected 240 bytes)
! Warning ! TI-4100 ROM record 0x0001 has a length of 4118 bytes (expected 442 bytes)
! Warning ! TI-4100 ROM record 0x0005 has a length of 154 bytes (expected 388 bytes)
! Warning ! TI-4100 ROM record 0x0000 has a length of 13934 bytes (expected 240 bytes)
! Warning ! TI-4100 ROM record 0x0001 has a length of 116736 bytes (expected 442 bytes)....
and nothing shows up in the output window or the output file.
If I run the DAT file (generated on download when using Data Transfer) through TEQC Editor, I get a standard RINEX file that seems to process normally.
I have one recent file though that really has me scratching my head. I converted the DAT to RINEX as described above, and I get the 9001 error - data is too noisy or kinematic. However, it processes fine using Centerpoint RTX, and I can process it against data downloaded from the local CORS. In the session editor, there appears to be a cycle slip at one specific time across all satellites, which makes me wonder if there was some kind of power issue during the setup. The cycle slip occurs just shy of 2hrs into a 6hr observation. This brings me to the even weirder part - the date of observation in TBC shows up as 05/26/1879. I stuck the file into a new project, and I get the exact same date. When I import the CORS data, it shows up with a 1879 date too! The converted RINEX file has the correct dates in it.
Any thoughts as to what is going on?
"Any thoughts as to what is going on? "
Could only guess here.
If you recently added a new receiver in survey style, would you have to redefine your receiver and antenna in TEQC ?
Your new receiver records your infill in another file extension other than the .t02 ?
It sounds like the .dat is an ubiquitous extension that your TEQC can easily recognize and parse regardless of the receiver or antenna definition,
and the character exception errors are large enough to make you wonder if the .t02 is the correct file or folder.
I have never used TEQC or TBC.
Native files (Trimble) in OPUS have not been supported for several years. I routinely make a rinex (convert2rinex) file from the D/L *.t01 file from the base.
Also, if you want to use OPUS, not OPUS-RS, you will need your base file and not the file you logged in the DC (RTK&Infill). Also, if you're using that as your survey style for the rover, you aren't using any GLONASS sats. Can make for a long day.
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
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.
Paul, once again your condescending attitude grates on me. How is anyone going to learn to use a new receiver if they don't ask questions here?
Alan: I had an R10 file that was collected on 7/2. I submitted to RTX, and it seemingly processed fine (good sigmas, 1 to 3 cm), but was off by 0.6 m H and 1.1 m vertically versus TBC processing against a nearby CORS. The data file was only 32 minutes (because it was near a CORS), but I would expect from past experience that a short data file that did not get a good results would have much higher sigmas. On a hunch that it maybe had something to do with leap second, i removed the glonass and resubmitted to RTX. It came out much closer to the "truth" (short baseline from CORS), 4 cm H and 35 cm V , and with higher sigmas (15 cm). I submitted to OPUS-RS, and it failed to converge after 5 iterations, submitted multiple times on different days.
I have never seen RTX be off significantly but with good sigmas. A bit disconcerting. I emailed them, but got no response. I can accept if it doesn't get a good solution, but the sigmas should reflect that.
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.t02
The tgd file has glonass and gps, dat file only has gps
John Hamilton, post: 326446, member: 640 wrote: Paul, once again your condescending attitude grates on me. How is anyone going to learn to use a new receiver if they don't ask questions here?
First off, they read the receiver manual and software manual. If you have done what the manuals instruct then you can ask questions about why your results differ. We can perceive nothing from his posting of OPUS reported errors. As has been said most of those errors go away after a resubmission a day later. Again we can perceive nothing of the where or when.
There are many ways to get a GPS education, and if you choose the hard way, why should others make your choice the easy road?
I would suspect his 32 minute file was collected too soon after start up and does have cycle slips and incomplete data. If someone wants to send me that file I most likely can clean it up and trim it. Something I have done much too often for way too many neophytes.
BTW, here is a teqc forum that can often get you answers faster than here and can deal with very specific problems, the solutions to which may involve actual teqc improvements.
Paul in PA
Alan Chyko, post: 326400, member: 1145 wrote: We recently picked up a pair of used R8-3 receivers....Are T02 files really not supported? .....Any thoughts as to what is going on?
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.
Paul in PA, post: 326472, member: 236 wrote: First off, they read the receiver manual and software manual. ...
I've always found that manuals start to make a little sense after I've figured out the software / hardware they purport to describe. Learning from scratch using only the manual is an extremely difficult thing to do, IMHO.
Paul in PA, post: 326472, member: 236 wrote: There are many ways to get a GPS education, and if you choose the hard way, why should others make your choice the easy road?Paul in PA
No surveyor is an island,
Entire of itself,
Every surveyor is a piece of the continent,
A part of the main.
If a clod be washed away by the sea,
The profession is the less.
As well as if a promontory were.
As well as if a manor of thy friend's
Or of thine own were:
Any surveyor's lack of knowledge diminishes me,
Because I am involved in the profession,
And therefore never send to know for whom the Chi-Square Test fails;
It fails for thee.
Paul in PA, post: 326472, member: 236 wrote: First off, they read the receiver manual and software manual. If you have done what the manuals instruct then you can ask questions about why your results differ. We can perceive nothing from his posting of OPUS reported errors. As has been said most of those errors go away after a resubmission a day later. Again we can perceive nothing of the where or when.
There are many ways to get a GPS education, and if you choose the hard way, why should others make your choice the easy road?
I would suspect his 32 minute file was collected too soon after start up and does have cycle slips and incomplete data. If someone wants to send me that file I most likely can clean it up and trim it. Something I have done much too often for way too many neophytes.
BTW, here is a teqc forum that can often get you answers faster than here and can deal with very specific problems, the solutions to which may involve actual teqc improvements.
Paul in PA
Paul: I don't know if you have reading comprehension issues or what. He stated that TBC was giving the 1879 date, not the rinex file. That is very pathological, because the way Trimble data files work is with GPS week (starts in January of 1980) and seconds of the week (0 at 0h Sunday GPS time). So, it SHOULD be totally impossible for any data to precede that date.
Also, the 32 minute file was MINE. It has GPS and Glonass, and was collected on a wide open site in the desert. I know what the "true" values are, I processed against a nearby CORS (actually 2) and got an excellent solution. What I was commenting on as undesirable is the fact that for the first time I had seen, the Trimble RTX processor returned a seemingly good solution (% used and sigmas) for a really bad solution. My experiences with Trimble RTX have been that if I submit a short data file (under 45 minutes), it may or may not get a good solution, but if it does not the statistics indicate that it is not good. One thing I have always said about Trimble processors is that I can live with an occasional false negative, but I never want to see a false positive, and that is the way they have been since trim640, then TRIMMBP, then wave (GPSurvey), then TGO, and now TBC. As long as there was enough data, it would not give a false positive. I have seen a false positive in the case of, for example, 15 minutes of data on a 75 km line, but that violates my rule of 1minute/km for lines above 15 km.
I think this is an excellent place to ask about weird things that happen, it is a good way to find out about the existence of bugs in firmware or software. Also, I don't know of any single place where it explains .t02 files, .tgd files, .dat files, etc.
Paul in PA, post: 326472, member: 236 wrote: There are many ways to get a GPS education, and if you choose the hard way, why should others make your choice the easy road?
Suggestion to Alan: Ignore the grumpy old man and keep asking questions. Many of us have been in similar situations and appreciate the cheerful assistance freely given by most participants hereabouts.
John Hamilton, post: 326506, member: 640 wrote: Paul: I don't know if you have reading comprehension issues or what. He stated that TBC was giving the 1879 date, not the rinex file. That is very pathological, because the way Trimble data files work is with GPS week (starts in January of 1980) and seconds of the week (0 at 0h Sunday GPS time). So, it SHOULD be totally impossible for any data to precede that date.
Also, the 32 minute file was MINE. It has GPS and Glonass, and was collected on a wide open site in the desert. I know what the "true" values are, I processed against a nearby CORS (actually 2) and got an excellent solution. What I was commenting on as undesirable is the fact that for the first time I had seen, the Trimble RTX processor returned a seemingly good solution (% used and sigmas) for a really bad solution. My experiences with Trimble RTX have been that if I submit a short data file (under 45 minutes), it may or may not get a good solution, but if it does not the statistics indicate that it is not good. One thing I have always said about Trimble processors is that I can live with an occasional false negative, but I never want to see a false positive, and that is the way they have been since trim640, then TRIMMBP, then wave (GPSurvey), then TGO, and now TBC. As long as there was enough data, it would not give a false positive. I have seen a false positive in the case of, for example, 15 minutes of data on a 75 km line, but that violates my rule of 1minute/km for lines above 15 km.
I think this is an excellent place to ask about weird things that happen, it is a good way to find out about the existence of bugs in firmware or software. Also, I don't know of any single place where it explains .t02 files, .tgd files, .dat files, etc.
I missed the actual file that had the 1879 date.
I know the 32 minute file was your file, send it and I'll take a look at it. I have from time to time gotten very good post processing from a rejected OPUS or OPUS-RS file, but I can usually weed out the chafe and find some wheat. Usually it is because I sometimes make the mistakes I advise others no o make. Sort of reverse reinforcement.
Paul in PA
Alan -
I think someone already said this but just use Trimble's Convert To RINEX utility to convert your TO2 files - it's fast, painless, and I've never had a problem with it. It's on trimble.com under Support A - Z, under the Rs. The only time I find it necessary to use TEQC is when one of our crews inadvertently collects a 1 second file; I'll use it to strip it down to 15.
John - I never really understood why the DAT file even existed; I'm guessing that it was a legacy format that was needed before I started using Trimble in 2004. I know TGO needed it and would not read a TO1, which I thought was odd as well. But in any case I haven't messed with a DAT file since switching to TBC; we transfer the TO2 to the collector via BT and sync it to TCC, I convert directly to RINEX to submit to OPUS.
Last week I selected 15 files in Windows Explorer, right-clicked, and hit Open (I have TO2 files associated with Convert to RINEX); I was pleased to see that the computer and software both handled this with no problem whatsoever. I don't even actually open the convert utility anymore, I just select the files, right-click, Open, done.
Lee D, post: 326525, member: 7971 wrote: John - I never really understood why the DAT file even existed; I'm guessing that it was a legacy format that was needed before I started using Trimble in 2004. I know TGO needed it and would not read a TO1, which I thought was odd as well. But in any case I haven't messed with a DAT file since switching to TBC; we transfer the TO2 to the collector via BT and sync it to TCC, I convert directly to RINEX to submit to OPUS.
Last week I selected 15 files in Windows Explorer, right-clicked, and hit Open (I have TO2 files associated with Convert to RINEX); I was pleased to see that the computer and software both handled this with no problem whatsoever. I don't even actually open the convert utility anymore, I just select the files, right-click, Open, done.
The only GOOD thing about a dat file is that I have a document that details the record formats, so I can read the dat file. I like to load everything into a database which helps immensely when dealing with point names, HI's, antenna types, etc.
T01 (GPS) and T02 (GPS & GLONASS and others) are more compressed, but I do not have the format details (!@#$ Trimble and their proprietary ways). Their converter runpkr00 will make the tgd, which is like a dat file but has additional constellations (I believe that is the difference). I prefer to use teqc because it has become a defacto standard. And it has a lot of other features besides just converting to rinex.
Paul in PA, post: 326521, member: 236 wrote: I missed the actual file that had the 1879 date.
I know the 32 minute file was your file, send it and I'll take a look at it. I have from time to time gotten very good post processing from a rejected OPUS or OPUS-RS file, but I can usually weed out the chafe and find some wheat. Usually it is because I sometimes make the mistakes I advise others no o make. Sort of reverse reinforcement.
Paul in PA
Thanks for the offer, Paul. My real concern is what I said about the RTX processor. I only submitted it to OPUS to see if it had a problem with the data, which it apparently did. But I rarely depend on OPUS-RS for anything, just as a check. Like I said, I had a good solution with TBC post processing. This was the shortest data file collected, because we were going to rely on RTX if no CORS nearby. As it turned out, all of the data post processed well, and the RTX all agreed (longer sessions) well with the post processed except this short session. And there were others collected earlier that day (July 1) than this one with Glonass and no problems.
Kris Morgan, post: 326435, member: 29 wrote: Native files (Trimble) in OPUS have not been supported for several years. I routinely make a rinex (convert2rinex) file from the D/L *.t01 file from the base.
Also, if you want to use OPUS, not OPUS-RS, you will need your base file and not the file you logged in the DC (RTK&Infill). Also, if you're using that as your survey style for the rover, you aren't using any GLONASS sats. Can make for a long day.
Kris - Unfortunately TEQC or TEQC Editor are the only tools at my disposal at the moment. Our IT folks keep the Window's permissions locked down, and Trimble's conversion utility did not get installed on this machine. That being said, I've never had a problem with an un-OPUS-able (if that's not a word it should be) file from either our old equipment or this new pair of receivers prior to this.
The file in question did come from the base receiver itself - that is how I have my RTK & Infill style set up. Not sure what you mean w/ the GLONASS comment. I've never seen that in the documentation, the controller indicates all sats are in use, as does the QC2 record w/ the vector.