GNSS Solutions and ...
 
Notifications
Clear all

GNSS Solutions and multiday rinex files

5 Posts
2 Users
0 Reactions
2 Views
(@tyler-parsons)
Posts: 554
Registered
Topic starter
 

I recently made an occupation with an L1 gps rover which spanned about 2hr 30min, 15 minutes into the next UTC day. I downloaded data from a nearby CORS station from the NGS CORS files for the same occupation period. So far, so good.

There is another nearby CORS station run by the next county which is NOT tied into NGS which I would like to use. The county archives the data as a rinex file (*.15O, *.15N, & *.15G) on a daily basis (also UTC based) at 1 obs/sec making the files quite large, about 200Mbytes each. When I import the 2 separate *.15O into GNSS Solutions, I get 2 separate observation for the CORS station in the Time View, and a length differences spreadsheet between Obs1 (day 1) and Obs2 (day 2)in the Repeat vectors display.

My computer gives an out of memory error using WinTEQC just to load 1 file so loading and merging the 2 days files is out of the question using that program. I am not familiar enough with teqc.exe to use it directly, but I may have to learn to merge files and pare down the size using that.

Does having the 2 separate observation files for a single station create a problem in processing the data, or do I have to (somehow) merge the 2 days files into a single file before importing?

Thanks.

 
Posted : January 14, 2015 7:00 pm
(@paul-in-pa)
Posts: 6044
Registered
 

Open the long RINEX files in WordPad and delete all the times not needed. I've deleted 20+ hours at one time.

What was your observation time interval for your L1? Parse the long RINEX files to match it with teqc.

You should now have a 2 hour and a 15 minute file. Go back to WordPad and copy the 15 minutes of observations and paste into the 2 hour file.

Lastly copy the "n" file for your original 2:15 CORS and rename it to match the non CORS RINEX "o" file name except for the "n". Then bring that newly created RINEX file into Solutions. This renaming step may not be necessary but this guarantees the "n" file goes past midnight.

Paul in PA

 
Posted : January 14, 2015 8:07 pm
(@tyler-parsons)
Posts: 554
Registered
Topic starter
 

I'll try that tomorrow and see what happens. Thanks.

 
Posted : January 14, 2015 8:44 pm
(@tyler-parsons)
Posts: 554
Registered
Topic starter
 

That worked, Paul. Thanks.

That'll teach me to span a UTC day if I want to use the county data though. Finding the correct times in two full 24 hr files of 1 sec data is a *@%*! !!

 
Posted : January 15, 2015 12:35 pm
(@paul-in-pa)
Posts: 6044
Registered
 

Tyler, Sometimes The Only Thing That Works Is Brute Force

Still better than having to reoccupy it.

Paul in PA

 
Posted : January 15, 2015 4:03 pm