RinexDates 1.8

RinexDates - TGO Workaround for 1 billion sec issue

Luciano
I haven't tried processing any files recently myself but I know of others that are using the combination of TGO and RinexDates sucessfully in the last couple weeks. Did you run the precise ephemeris file through RinexDates along with the nav and obs files?

RinexDates - TGO Workaround for 1 billion sec issue

Hi, John. Thanks for your attention.
Well, I revised all my procedures and everything seems OK.
I did run the precise ephemeris files through RinexDates along with the nav and obs files, but TGO is still giving me this warning message:
"Precise ephemeris unavailable for this baseline, using broadcast" for every baseline processed.
The data was collected on march, 18. I've downloaded and processed the ephemeris files once again today with the same results. I've tried even in other PC: same results...
I've checked the files and all of them shows the changes to the year of 1991.
Some idea ?
Thanks again for your attention and sorry for my bad english (things get rusty without practicing !)

Luciano

RinexDates - TGO Workaround for 1 billion sec issue

Luciano
Am I correct that you were able to use the precise ephemeris prior to March? Is it possible that the setting in TGO is set to broadcast rather than precise? You can check it by looking under the Survey tab then GPS processing styles then editand select precise. You probably already have checked this but sometimes the obvious slips by.

I'll try grabbing some CORS files and see what happens later today or tomorrow.

RinexDates - TGO Workaround for 1 billion sec issue

Hi, john.
Yes, TGO was working fine with RinexDates prior to March. It's important to check everything from the basics to the more complex tasks. As you said: "sometimes the obvious slips by" . It's really true.
But I've reviewed my TGO's "GPS Processing Styles" and nothing has changed: Ephemeris->Precise ; Solution type-> Fixed ; etc
Well, I'm still looking for some bug in my procedures.
And I'll collect some new data, too.
Let's see what happens.
Thanks

Luciano

RinexDates - TGO Workaround for 1 billion sec issue

Luciano
I tried some CORS files today and had the same problem you are experiencing. I have sent an email off to a friend. He should be getting back to me soon. I'm wondering if perhaps there has been a slight change in the format of the precise ephemeris file that causes TGO to not recognize it anymore. If that's not it, I'm afraid I don't know the answer.

Maybe tomorrow I'll try processing with TBC to see if it has the same problem.

RinexDates - TGO Workaround for 1 billion sec issue

Luciano
I heard back from my friend and he said he wasn't aware of any format changes to the precise ephemeris file format in the recent past. I'm at a dead end right now.

RinexDates - TGO Workaround for 1 billion sec issue

Hi, John.
You hit the spot: we're at a dead end ! I hope we find a way out of it.
I'll try Topcon Tools and see if it properly process the data.
Thanks

Luciano

RinexDates - TGO Workaround for 1 billion sec issue

Luciano, John,

I'll have a look at this,
can you send me some files to work on,
I need the original files and the modified ones, a set collected before 1st of march and a recent set.

You'll find my email in the RD program.

I'll be out of town for some days, enjoying 'De Ronde van Vlaanderen' and the Easter week end, probably not so much internet access.

Chr.

RinexDates - TGO Workaround for 1 billion sec issue

Luciano and Christof
I have sent some test files to Christof. For some reason RinexDates appears to be turning the ephemeris files into jibberish and that is why TGO will not recognize them.

RinexDates - TGO Workaround for 1 billion sec issue

John, Christof.
At least it seems the problems origin was found.
I could send some test files, too. Please notify me if needed.

RinexDates - TGO Workaround for 1 billion sec issue

luciano,

yes send me some files,
not sure what happened at john's side but his filesize of the modified files is not good, I processed the same files here and got decent results, but have no files to process in TGO.

Chr.

RinexDates - TGO Workaround for 1 billion sec issue

Hi, Christof.
I've sent the files. Two sets: january-21 and march-19.

RinexDates - TGO Workaround for 1 billion sec issue

Hi,
we figured out what could be the problem,
after fixing the modified files manually John Minor was able to process successfully in TGO. (Thanks john - appreciate your instant help on this)

Temporary fix below, I'll update the program after some more testing ...

Chr.

RinexDates - TGO Workaround for 1 billion sec issue

Well,
it's that time of the year again ... RinexDates 1.6 can't take the switch from february to march due to the leap year 1992. Sounds a little weird I know, but the Rinex files are backdated 22 years in version 1.6. At the moment of writing the code last year I tought I had figured out a long term solution but apparently that's not the case. I'll do some coding next weekend and will have another date offset on sunday if all goes as planned.

Christof.

RinexDates - and another TGO Workaround for OS data

Christ Lambrecht has suggested I post here regarding my experiences with another TGO work- around originally posted on another thread...

I have been using the RinexDates utility to keep a TGO installation working, but hit another problem recently. I'm using RINEX corrections downloaded from the Ordnance Survey (UK) website for baseline processing of Trimble data.

My workflow is:
download Rinex data from Ordnance Survey (UK) passive network, nearest five stations.
download dat file from receiver
convert dat file to RINEX with RinexConvert 2.2.5
adjust data and OS files with RinexDates 1.7
import converted OS Rinex files to TGO for baseline processing

However, starting very recently, I get the following import report from TGO (similar entry for each imported OS Rinex file):

Errors:
- could not find two records with at least 5 SVs in RINEX file
- Unable to locate user position C:Documents and SettingsTim YoungStBridese_cari063i.15o
- Error on conversion from RINEX to DAT
Warnings:
- # / TYPES OF OBSERV: Number of types listed differs from count field.
- # / TYPES OF OBSERV: Number of types listed differs from count field.

What appears to have happened is that the OS have expanded the data types present in their Rinex download files from seven to ten. The tenth data type falls onto a second header line - causing the import filter to fail - and generating the two data types warnings given above. Since the number of data types can't be established then there appears to be no usable data.

The solution (suggested by 'Paul in PA') was to download teqc from:
http://www.unavco.org/software/data-processing/teqc/teqc.html

Teqc can then be used to strip the processed Rinex files back to the seven data types that the OS files previously contained, with the command:

teqc -O.obs C1L1SiC2P2L2S2 >

The Rinex files now contain only one line of data types in the header and import correctly into TGO.

Hopefully the lifetime of TGO is extended a little longer...

christ lambrecht, post: 101542, member: 284 wrote: TGO Workaround for 1 billion sec issue

Some of us have already switched to TBC, others haven't.
For those who want to process recent data in TGO there is the workaround described in Dario Canosa's post https://surveyorconnect.com/threads/trimble-geomatics-office-tgo-processing-issue.94125/&apos ;">Dario's emergency solution.

The editing of the Rinex files may be tricky so I made a small utility that will open the files, and write an edited copy to the same directory. In Beglium we have RTK-VRS available in the whole country, (okay, I admit Belgium is very small) so we don't do any Fast Static work anymore, but it was fun to program again some survey stuff. So I'm not a Rinex expert at all, but with the help of Dario Canosa and John Minor I think we got something that may work in most cases. It's still an emergency solution ... but probably some will benefit from it.

Feel free to download and test, let me know if you use it and have questions or requests.
Keep in mind that I'm a very slow programmer, If I were surveying as slow as I was coding ...
The program is free, updates will be announced here.

You can load obs and nav files, I received an orbit file and will have a look to add that file type.
The utility has been tested with files with 1 observation, don't know how it will handle files with multiple points.

You can use the free RinexConverter from Trimble to convert your Dat files to Rinex.
http://www.trimble.com/trimblerinex_ts.asp&apos ;">Trimble Convert Dat to Rinex Utility
Be sure you have the latest version

There is also the TGO 2.11 Rinex patch for importing the rinex data in TGO
http://www.trimble.com/support_trl.asp?pt=Trimble%20Geomatics%20Office%C3%A2%E2%80%9E%C2%A2&Nav=Collection-66&apos ;">TGO patch for importing Rinex 2.11

Christof.

Version Info

1.7 Date 2014.03.11
update for new Leap Year compatibility

1.6 Date 2013.04.14
fix missing space in week# in line 2 of the Precise Ephemeris sp3 file

1.5 Date 2013.03.04
modified year offset for data collected after 1st of march 2013 (22 yrs)

1.4 Date 2012.06.11
modified year offset for data collected after Leap Day March 1st, 2016 (22 yrs)
options added to save with modified year value in file extension
to build the GPSurvey Reports or to overwrite original Rinex File
(the original file is saved as OldFileName.OldFileExtension.bak)
browse to your TGO Baseline reports to modify the dates back to the date of survey (C:...TGO Project FolderReportsBaseline)
added link on About page to check online for updates

1.3 Date 2011.11.24
fix for not processing files with file extension in uppercase
comments added in header about resetting the date/time

1.2 Date 2011.11.13
fix for epochs collected past midnight Greenwich, Year value now modified.
LeapSeconds in Header are now set as Comments to avoid warnings on import in TGO.
converts files with data collected up to 2020.02.29.
preview of collected data in obs. files.

1.1 Date 2011.10.24
orbit .sp3 file format supported

1.0 Date 2011.10.18
only obs and nav files are supported.
tested only with 1 point FS files
rinex 2.10 and 2.11 supported

i like you work...thanks

Brad Ott, post: 101574, member: 197 wrote: Christof. & John...

...are two of the very best beer leggers, in my humble opinion.

I have absolutely no idea what they are posting about here.

But this looks like it will probably help somebody "out there".

Way to go boys!

:good: :beer:

"I have absolutely no idea what they are posting about here."

Me either Brad, I am still in awe at what the people can contribute to this site. Christof and John are so far advanced I'm depressed at how less educated I am.

B-)

Having used the method I described above successfully throughout 2015, my first survey in 2016 has run into problems.

TGO imports my own datafiles (rinex files created from the original dat files) just fine.
It fails to import the Ordnance Survey rinex files.
These are being imported using the navigation file from my own observations.

The error is given as:

- No position available from header or estimation.
- Header transfer failed
- Error on Conversion from Rinex to DAT

- No ephemeris at time of obs: PRN=1 WK=1566 SEC=122399.9
[ same for PRN = 3,11,12,17,19,23,31,32]
- Ignoring "APPROX POSITION XYZ". (6385 km from estimated position)
- Out of range position in header will force clock offset computation.

Does anyone have any idea either what I am doing wrong - or if RinexDates 1.7 has an issue with 2016?

i've looked at the headers of the RINEX files and they look to be in the same format as the last batch which worked...

Thanks

Tim

Tim,

not sure what th problem may be here. I don't think the problem has to do with RinexDates and the year 2016.

But as a side note I can tell you that RinexDates 1.7 files will only process upto the 28th (or maybe 29th) of february.
I have to calculate a new date offset for data collected from29th feb/1march for the RinexDates 1.8 due to the leap year.
Link or new program will be available here.

Christof.

christ lambrecht, post: 352991, member: 284 wrote: Tim,

not sure what th problem may be here. I don't think the problem has to do with RinexDates and the year 2016.

But as a side note I can tell you that RinexDates 1.7 files will only process upto the 28th (or maybe 29th) of february.
I have to calculate a new date offset for data collected from29th feb/1march for the RinexDates 1.8 due to the leap year.
Link or new program will be available here.

Christof.

Thanks Christof. I don't know what the problem was either, but I reoccupied the same station the following day and all the download files processed as expected. I have no idea what the glitch was on 11th Jan (possibly OS-related), but 12th-14th have all processed perfectly. Luckily the site was one that could be returned to simply...

Thanks for the heads-up for the end of next month!

As an aside, I have now discovered that the UK Ordnance Survey active net RINEX downloads have reduced the number of variables in the file - so the use of TEQC to thin-out the variables in my workflow earlier in this thread is no longer required. TGO will process the downloaded RINEX files once backdated, with no edit.

Tim