Notifications
Clear all

First time converting to RINEX...

37 Posts
11 Users
0 Reactions
11 Views
(@steve-adams)
Posts: 406
Topic starter
 

I am trying to convert my ".pcd" file to RINEX, for submission to OPUS.

This pcd is from around 2 hrs of static observations with a Sokkia Radian IS (L1/L2).

From reading the NGS sites, I think I need to use TEQC.(Do I?) I downloaded the Windows version, and have experimented with some syntax... can anybody point me in the right direction towards getting this pcd file converted?

PS: Don't worry, I am not going to use this info in a survey, just trying to learn about OPUS.

Any help is appreciated!

Thanks,

Steve

 
Posted : October 27, 2010 6:07 am
(@loyal)
Posts: 3735
Registered
 

Last time I checked, TEQC did NOT support the Novatel [binary] .pdc file format. You will need to use either a Sokkia or Novatel .pdc to RINEX converter.

If you want to shoot me the file, I'll convert it for you.

Loyal
ldogeo-at-aol-dot-com

 
Posted : October 27, 2010 6:17 am
(@steve-adams)
Posts: 406
Topic starter
 

Thank you Loyal, I will...

 
Posted : October 27, 2010 6:19 am
(@kris-morgan)
Posts: 3876
 

Your software should do it for you. TGO converts all of mine to Rinex prior to submission to OPUS.

Should be just a couple of keystrokes. Remember to have the extension to be *0y0.

 
Posted : October 27, 2010 6:27 am
(@loyal)
Posts: 3735
Registered
 

Kris is correct ASSUMING that you have Sokkia Spectrum Software (I think that's what it's called). I know lots of folks who PRIMARILY do RTK work, and don't buy the Post Processing Software though. Sokkia may have a stand-alone utility to do this as a down load, or posibly the utility will work without the "dongle" (or whatever Sokkia uses).

Loyal

 
Posted : October 27, 2010 6:52 am
(@steve-adams)
Posts: 406
Topic starter
 

Thanks Kris.

Thanks Loyal,

That is prolly the case (they usually just do RTK.)

I will check the Sokkia site to see if they have anything.

Thanks,

Steve

 
Posted : October 27, 2010 6:59 am
(@kris-morgan)
Posts: 3876
 

Loyal, you're right. It was an add on (I think called Wave Processor) for TGO. Good call. I sometimes forget that it's a cafeteria style ordering when considering GPS and it's uses.

 
Posted : October 27, 2010 7:02 am
(@paul-in-pa)
Posts: 6044
Registered
 

Why Not Just Submit The PCD File And Let OPUS Convert It?

OPUS says it handles any GPS file, it costs nothing to give it a shot.

Paul in PA

 
Posted : October 27, 2010 7:23 am
(@kris-morgan)
Posts: 3876
 

Paul

I don't think that OPUS handles native files anymore. Used to, we could submit the *.dat files from the 5700 and R8, then they did an upgrade and now requires for rinex.

 
Posted : October 27, 2010 7:24 am
(@gregpendleton)
Posts: 139
Registered
 

I think that makes you a Born again RINEX.

 
Posted : October 27, 2010 7:34 am
(@steve-adams)
Posts: 406
Topic starter
 

Paul

Paul,

OPUS told me that it no like that pcd file, told me to convert to RINEX.

Thanks,

Steve

 
Posted : October 27, 2010 7:37 am
(@foggyidea)
Posts: 3467
Registered
 

You can download the Sokkia Planning, or the demo version of Spectrum that will allow you to convert to rinex without a charge...

 
Posted : October 27, 2010 7:42 am
(@steve-adams)
Posts: 406
Topic starter
 

Don,

Excellent suggestion for Planner. Converted great. I really appreciate it.

Does one have to submit the file that ends "o" to OPUS? Loyal converted for me and sent two files; I think I submitted the file that ends with "n" and maybe that's why it wouldn't accept it.

Thanks, Steve

 
Posted : October 27, 2010 8:42 am
(@paul-in-pa)
Posts: 6044
Registered
 

Yes, The "o" File

OPUS already has "n" files so does not need them. OPUS should have noticed that you sent an "n" file.

The "n" file would be used if someone wants to convert the RINEX back to proprietary format. However if someone were to send you an "o" file without an "n" file you could go to the ftp CORS and grab the daily generic "n" file rename it to match the "o" file before the . and you are ready to convert back. Also any other "n" file you have for that day or receive from ufcors also works.

Paul in PA

 
Posted : October 27, 2010 8:45 am
(@joe-nathan)
Posts: 399
Registered
 

Yes the file that ends in "o" is what gets submitted. It is usually the larger the two rinex files.

Good luck.

 
Posted : October 27, 2010 8:52 am
(@loyal)
Posts: 3735
Registered
 

Sorry about that Steve... I should have explained the two files. OPUS doesn't need (or want) the .yyn file, but if you want to import the RINEX data into most post processors, they will want BOTH files.

Loyal

 
Posted : October 27, 2010 9:01 am
(@foggyidea)
Posts: 3467
Registered
 

Like Loyal said , yes, just the O file..... be sure to check your antenna etc...

 
Posted : October 27, 2010 9:04 am
(@loyal)
Posts: 3735
Registered
 

Good point Foggy

OPUS does NOT read the RINEX "header" data concerning Antenna and HI, and therefore OPUS wants (NEEDS) this data input from YOU.

Be SURE and input the "HI" to the ARP (Antenna Reference Point) and NOT to the phase center, notch, bumper, whatever...).

Loyal

 
Posted : October 27, 2010 9:12 am
(@steve-adams)
Posts: 406
Topic starter
 

Good point Foggy

Uh oh,

I think we measured the HI from the notch.

As Loyal posted to me in an email: "The Peak-Peak variance on the Latitude (I guessed at the Antenna and HI) was HORRIBLE (0.457 meters), "

Here are my OPUS results:

FILE: 00242990.10O 000107067

2005 NOTE: The IGS precise and IGS rapid orbits were not available
2005 at processing time. The IGS ultra-rapid orbit was/will be used to
2005 process the data.
2005
NGS OPUS SOLUTION REPORT
========================

All computed coordinate accuracies are listed as peak-to-peak values.
For additional information: http://www.ngs.noaa.gov/OPUS/about.html#accuracy

USER: jsadams@bartramtrail.net DATE: October 27, 2010
RINEX FILE: 0024299r.10o TIME: 16:39:46 UTC

SOFTWARE: page5 1009.28 master50.pl 100910 START: 2010/10/26 17:01:00
EPHEMERIS: igu16072.eph [ultra-rapid] STOP: 2010/10/26 19:12:00
NAV FILE: brdc2990.10n OBS USED: 4239 / 5220 : 81%
ANT NAME: SOK_RADIAN_IS NONE # FIXED AMB: 53 / 57 : 93%
ARP HEIGHT: 1.6337 OVERALL RMS: 0.019(m)

REF FRAME: NAD_83(CORS96)(EPOCH:2002.0000) ITRF00 (EPOCH:2010.8185)

X: 797049.594(m) 0.074(m) 797048.876(m) 0.074(m)
Y: -5469161.942(m) 0.086(m) -5469160.408(m) 0.086(m)
Z: 3172613.490(m) 0.565(m) 3172613.295(m) 0.565(m)

LAT: 30 1 24.43855 0.450(m) 30 1 24.45941 0.450(m)
E LON: 278 17 29.90849 0.062(m) 278 17 29.89023 0.062(m)
W LON: 81 42 30.09151 0.062(m) 81 42 30.10977 0.062(m)
EL HGT: -23.387(m) 0.354(m) -24.889(m) 0.354(m)
ORTHO HGT: 4.735(m) 0.599(m) [NAVD88 (Computed using GEOID09)]

UTM COORDINATES STATE PLANE COORDINATES
UTM (Zone 17) SPC (0901 FL E)
Northing (Y) [meters] 3321595.649 630678.853
Easting (X) [meters] 431695.634 131672.321
Convergence [degrees] -0.35444422 -0.35444422
Point Scale 0.99965756 0.99999876
Combined Factor 0.99966123 1.00000243

US NATIONAL GRID DESIGNATOR: 17RMP3169521595(NAD 83)

BASE STATIONS USED
PID DESIGNATION LATITUDE LONGITUDE DISTANCE(m)
DE6005 GNVL GAINESVILLE CORS ARP N294111.557 W0821636.736 66425.6
DE6007 JXVL JACKSONVILLE CORS ARP N302902.515 W0814205.330 51061.8
DE6012 PLTK PLATAKA CORS ARP N293948.148 W0814115.861 39964.2

NEAREST NGS PUBLISHED CONTROL POINT
AC5790 V 422 N300125. W0814223. 190.7

This position and the above vector components were computed without any
knowledge by the National Geodetic Survey regarding the equipment or
field operating procedures used.

No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.864 / Virus Database: 271.1.1/3222 - Release Date: 10/27/10 02:34:00

 
Posted : October 27, 2010 9:25 am
(@loyal)
Posts: 3735
Registered
 

OPUS "quaity"

There are several obvious warning flags in the OPUS solution (I am looking at one that I ran with the RIGHT antenna, but [probably] wrong HI):

1. LESS than 90% of the observations were used (81%)
2. The Peak-Peak Variance on BOTH the Latitude and Ellipsoid Height is greater than 0.030 meters (0.481 and 0.305).

I suspect that (at least) part of the problem is the vector to jxvl, but that's just a guess based on a quick look at the extended output report. The more likely problem (usually) is a less than ideal "sky-view" at the remote site. Of course use of the ultra-rapid ephemeris doesn't help either.

Loyal

 
Posted : October 27, 2010 10:01 am
Page 1 / 2