Is there any way to fix this static file?

Some Things To Do

Do not start collecting data until you have solid lcok on sufficient satellites. OPUS does not look too deep into a file before it gives up. I usually start a new file after evrything is going smooth and discard the short startup file.

If you have not used your receiver in some time, give it a good chance to update the ephemeris before putting it to work. Coolecting data too soon in this case could encourage the receiver to save a raw position from it's last location for the current file. This does no harm to the data, but OPUS uses the raw position to select CORS for it's solution. If you cover a lot of territory you may not get the nearest ones without specifically requesting them.

If you already have a file, trimming off of the beginning can help. If it is only a matter of minutes I might trim until I have data for six or even better seven satellites. Absolute minumum is 5. Because I am usually submitting to OPUS-RS I also look at my C1/P1 and P2 observables. It is possible to have good L1 & L2 but the other observation can be blank or out of normal. Again as an absolute minimum I want5 statellites with all four observables clean. Another one that is slow to clean up the C1/P1 & P2 can usually get by.

If I knew I had to submit to OPUS-S I would never leave the field with a 2 Hr 2 min file. Letting it run longer gives me some room to edit if I have to.

Send me your RINEX "O" and "N" fi;es and i take a peek for obvious problems.

Paul in PA

Some Things To Do

I tried to email you the file but it came back as undelivered due to the size of the file.

I ran the T01 file thru the convert to rinex program again and it worked. I am not sure what happened the first go around. here are the file if you want to check them out. Thanks for the reply.

RINEX FILE: 6921073p.13o TIME: 23:01:54 UTC
SOFTWARE: page5 1209.04 master32.pl 082112 START: 2013/03/14 15:19:00
EPHEMERIS: igs17314.eph [precise] STOP: 2013/03/15 00:30:00
NAV FILE: brdc0730.13n OBS USED: 23935 / 26319 : 91%
ANT NAME: TRMR6-2 NONE # FIXED AMB: 147 / 154 : 95%
ARP HEIGHT: 2.153 OVERALL RMS: 0.016(m)

REF FRAME: NAD_83(2011)(EPOCH:2010.0000) IGS08 (EPOCH:2013.1995)

X: -917930.534(m) 0.004(m) -917931.298(m) 0.004(m)
Y: -5387579.864(m) 0.013(m) -5387578.425(m) 0.013(m)
Z: 3278288.592(m) 0.004(m) 3278288.423(m) 0.004(m)

LAT: 31 7 38.20532 0.002(m) 31 7 38.22227 0.002(m)
E LON: 260 19 51.06065 0.005(m) 260 19 51.02310 0.005(m)
W LON: 99 40 8.93935 0.005(m) 99 40 8.97690 0.005(m)
EL HGT: 594.309(m) 0.013(m) 593.117(m) 0.013(m)
ORTHO HGT: 617.673(m) 0.024(m) [NAVD88 (Computed using GEOID12A)]

UTM COORDINATES STATE PLANE COORDINATES
UTM (Zone 14) SPC (4203 TX C)
Northing (Y) [meters] 3443900.396 3162105.552
Easting (X) [meters] 436203.227 763340.234
Convergence [degrees] -0.34592264 0.34209362
Point Scale 0.99965020 0.99988415
Combined Factor 0.99955692 0.99979084

US NATIONAL GRID DESIGNATOR: 14RMV3620343900(NAD 83)

BASE STATIONS USED
PID DESIGNATION LATITUDE LONGITUDE DISTANCE(m)
TXSA 82901.0
TXBI 75771.0
TXLL 104257.8

NEAREST NGS PUBLISHED CONTROL POINT
CA1124 LOVELESS N310738.843 W0994038.872 792.6

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.

WOW! A 9 Hour File?

I have DSL and never known a file to be rejected.

I had someone else send me RINEX files today, the first line of observations said, "the antenna is now moving".

I have edited that out and will shortly give it a second go.

Paul in PA

WOW! A 9 Hour File?

No rest for the wicked. I let the base run on "RTK and INFILL" while I am working large acreage jobs so the files vary from 4 to 12 hours. I think the solution that I have seen is to rerun it through the conversion software until it finally takes it. I might not have had the correct settings on the first submittal.

Sometimes things just don't work right. I usually do the static work for the projects and had a bad file last year that would not process through OPUS, but all the others were okay. Nothing was unusual with the setup and there was excellent visibility.

We sometimes use our old Ashtech Z12 for static observations. When you set them up, you go to screen 8 to enter your site information. If you are slow entering the site info, they will add a line to the RINEX file indicating a new occupation. If I am the operator, I just go to screen 7 after I have entered all of the site information, and press E123E and it wil start a new file with all of the correct site info. This is also a cleaner file with all the satellites in the first epoch.

We have a monument named FOSTER WE USE THE 4 character I'd FOST for that point. Because we often called Foster Faster, one of the guys accidently entered the site is as FAST once. About 5 minutes into the session, he realized what he had done and changed the site I'd. Then he noticed that there was a place to enter the antenna height after the session, so at the end of the session, he entered the HI as 2.000 again. We use fixed height tripods. Hit his caused a third new site marker to be added to the RINEX file because he got distracted and did not get the wrong site I'd entered fast enough

We were collecting this data for OPUS Projects. One of the real neat things about OPUS Projects is that it reads the OPUS report, and if you are within a certain tolerance of a point, it assignes your observations to that point. Thre tolerance that I use is one meter. The most convent thing is to get the correct site id on the first observation. Then OPUS projects does not care if you call it FOST, FAST, or F#@K it will assign the observations to FOSTER.

We have found one monument where this could be a problem. We found an NGS BM that was in a culvert head wall, and someone had done a reset on it, and set a stamped cap about 2 feet away, in the same head wall. Both marks are listed in the NGS database.

To fix the RINEX files, I just delete the extra lines indicating a new setup and save the edited file with a new name. You could also fix it with TEQC.

I am late to this party but I'd like to add my 2 cents CDN.

I have seen this when the field crew sets up or tears down the antenna while the receiver is logging data thus it is recorded as kinematic data in your static file. A simple first step to try is to not use the first and last five minutes of the static file. This will cure much of what ails you on most occassions.

You can edit the anomalous data out from a RINEX file or use TEQC to reset the time start/stop.

The crew may alos have simply yanked the power cord at the end of the survey so there is no 'end of file' marker. The editing techniques above applied only to the end of the file can fix it.

Scott

Maybe...

Okay here's my 2-bits...

There was/is nothing wrong with the file (obviously), you simply submitted it to OPUS TOO SOON. At least that's my take on it...

Note the Start/Stop data in the RINEX header:

START: 2013/03/14 15:19:00
STOP: 2013/03/15 00:30:00

You were 30 minutes into March 15, THEREFORE OPUS could not (or would not) process this file UNTIL a Rapid (or precise) Ephemeris was available for BOTH days (usually about noonish on the 16th. Anytime before the Rapid Ephemeris covering March 15 is available, this is EXACTLY the error statement that you will get. Yeah, Yeah, I know, it doesn't say that! But nearly every static file that I have sent through OPUS the last few years, spans GPS Midnight, so I have seen this error hundreds of times.

It appears to me, that OPUS will not combine an Ultra-Rapid and Rapid Ephemeris in the same solution. You can get around this by trimming the March 15th data off the end of the file, or simply waiting until the Rapid Ephemeris is available on March 16th.

At least that's my theory.

Loyal