Collected a set of data today and trying to process...
downloaded Rinex data from Ordnance Survey (UK) passive, nearest five stations.
download dat file from receiver
converted dat file to RINEX with RinexConvert 2.2.5
adjusted data and OS files with Rinexdates 1.7
tried to import converted OS Rinex files to TGO
I then get the following report from TGO (similar entry for each imported OS 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.
Anybody know whats gone wrong? Quite likely just user error, but there are so many links in the RinexConvert / RinexDates chain its hard to know where to start troubleshooting. Its the first survey needing processing in 2015...
First Open The RINEX And Take A Look...
...to confirm what observations there are.
From reading your error messages you may not have downloaded enough information to convert the Ordinance RINEX files into files readable by TGO. One needs to download the "o" and the "n" file in order for most software to convert it to a manufacturer type file for post processing. Because in essence every "n" is the same for any given day, servers do not keep an "n" file for every "o" file. If your source does not you not you need to find and download their universal "n" file for that day. Then you need to rename it to match the "o" file name before the .015n. Put this file in the same folder as the corresponding .15o file. When your post processor goes to convert the RINEX to a manufacturer specific file it will use both the "o" and the "n" file. Suppose you download 3 RINEX files, you can either make 3 copies with 3 corresponding names of the "n" file or just rename one to match one "o" file. After converting that RINEX file you can rename the "n" file to match a different "o" file and process that one and so on.
OPUS does not require you to create and send an "n" file, since it already has the universal file.
Paul in PA
First Open The RINEX And Take A Look...
Thanks Paul. Yes, I used the navigation file from my own observations to pair with the observation files downloaded from OS (the same process as I've used many times before...).
Opening the OS Rinex files doesn't show many obvious differences between those from projects earlier in the winter (that worked).
However, I do note that the warnings mentioned:
- # / TYPES OF OBSERV: Number of types listed differs from count field.
- # / TYPES OF OBSERV: Number of types listed differs from count field.
and this is one area of the header that is different:
In a file I previously processed successfully there was the line:
7 C1 L1 S1 C2 P2 L2 S2 # / TYPES OF OBSERV
but now there are two lines:
10 C1 P1 L1 D1 S1 C2 P2 L2 D2# / TYPES OF OBSERV
S2 # / TYPES OF OBSERV
Could TGO not be disentangling those statements correctly?
Use The Online teqc And Reduce to L1, L2, C1, P2
Then try to import the RINEX file. It is probably not liking the C2.
BTW are some satellite observations P2 and others C2 but not both?
Paul in PA
First Open The RINEX And Take A Look...
Tim,
(I made the RinexDates utillity with Dario Canosa and John Minor)
I noticed that you can still import your original measurments (dat file) and downloaded rinex files. You'll get the usual import dialogs and will see if your data is ok (I hope) but you cannot process the data in TGO.
The transition from febr. to march is always the time we get trouble with the calculated date offset fot the RinexDates program. (Had to do with some leap years that had to be taken in account)So that can be a cause too.
I don't do any static myself here in Belgium...
Christof,
Use The Online teqc And Reduce to L1, L2, C1, P2
Paul - thank you thats brilliant. Editing the OS downloads with teqc to reduce back to the shorter list of data that they used to contain did the trick! A real life-saver...
If I am understanding the original file correctly, there didn't seem to be any c2 data at all - the 2nd and 5th fields seem consistently blank.
First Open The RINEX And Take A Look...
Thanks for your comments Chris. I very much appreciate RinexDates - it has been (and still is) fantastic. In this instance Paul's suggestion to edit out the excess data fields using TEQC did the trick - the fact it is the first week of March seems to have been pure coincidence. I'm guessing the import routine for RINEX on TGO just can't handle a two-line data type definition - at least putting it back to a single line with fewer data fields cured the problem.
Now to document what I did so I know what to do again with the next batch of data...
Thanks again!!
First Open The RINEX And Take A Look...
🙂
that's good news,
It would be nice to update the main RinexDates post with your problem and solution, or to add a link to this thread.
[msg=101542]Main RinexDates thread[/msg]
thanks,
&
Happy surveying!
Christof.
