I collected over an hour's worth of data yesterday with a Topcon GP-DX1 and sent it to OPUS-RS. The response was as follows:
9009 ERROR! OPUS terminated abnormally in one of the processing modules.
9009 PPS - zero coordinates for initial point.
9009 OPUS cannot process this dataset.
9009 Aborting...
I re-sent it this morning, same thing. I don't understand the "PPS - zero coordinates" reference -- the RINEX header does have a plausible approximate position, if that's what it means. teqc shows the data to be somewhat noisy, but I would have expected a solution.
Any hints?
P.S. I know that one value for PPS is "Precise Positioning Service," but I didn't think that would pertain because it refers to units capable of decrypting the P-code. I did a search on it anyway to see if there might be some applicability, and came upon an abstract of a 1994 DOD document explaining PPS. One of the sentences made me chuckle: "In the past, PPS users wore green suits, and SPS users were everyone else."
Jim,
Send me your RINEX file for a look. Respond to my email.
For a do it yourself solution, open your RINEX file in WordPad and look at the first observations, the C1/P1 and P2 values. Early on there may be zeroes or small values. Delete a few minutes and you should be good to go. OPUS-RS needs 4 types of clean data (L1, C1/P1, L2 and P2) and it will not look past the first few epochs before bailing out.
Paul in PA
> Send me your RINEX file for a look. Respond to my email.
Sent -- thanks!
Not Here Yet
Did you reply to the email I sent you, because the board email link will not pass on attachments?
Paul in PA
Date Not Right, Data I Am Unsure Of
4 C1 L1 L2 P2 # / TYPES OF OBSERV
1994 3 22 22 34 30.000000 TIME OF FIRST OBS
END OF HEADER
94 3 22 22 34 30.0000000 3 11
26 MARKER NAME
USER COMMENT: COMMENT
Trimble Micro-Centered w/GP ANT # / TYPE
-2631688.1751 -4246074.3643 3952244.7011 APPROX POSITION XYZ
LATN 38 32 13.65939 LONE 238 12 34.72275 -14.931(m) COMMENT
LATN 38 32 13.65939 LONW 121 47 25.27725 -14.931(m) COMMENT
0.0000 0.0000 0.0000 ANTENNA: DELTA H/E/N
Slant Height(measured) = 2.0000(m) COMMENT
ARP to Slant Point Offsets: COMMENT
Radial = 0.00000(m); Vertical = 0.00000(m) COMMENT
--> RECEIVER COLLECTING FAST STATIC DATA <-- COMMENT
94 3 22 22 34 30.0000000 1 7 15 16 18 21 22 3 6 0.000458666
22208834.99218 64527.31618 -224499.69517 22208825.92217
23800400.50818 75522.44118 -198379.32016 23800392.68816
20673141.35218 11999.98818 -246905.06217 20673129.87917
21058966.56218 10551.48818 -199873.62917 21058954.56617
21538083.79718 -79256.98418 -288173.79317 21538070.67217
23187972.94517 -125303.98417 -261821.62916 23187966.06616
22111785.93818 -73330.73018 -274059.27317 22111777.06617
First off "1994" date error.
The C1 and P1 data are clean. They are the measured distance from the satellite in meters.
The L1 and L2 are combinations I do not recall seeing, as I recall it usually has the same sign.
Work on the date and resubmit.
Paul in PA
Date Not Right, Data I Am Unsure Of
> Work on the date and resubmit.
I didn't even think to look at the date. Apparently these receivers were never updated to accommodate the GPS week rollover. Once I fixed the dates (on every observation record, not just in the header), OPUS processed it with excellent results.
Processing every RINEX file (the native output format of the Topcon GP-DX1) would be a nuisance, even if automated. I'm assuming the firmware would need to be updated to accommodate the week rollover. I'll pose the firmware availability question in another thread.
Thanks, Paul, for pointing me at what should have been an obvious problem!
For Now Use A Global Find and Replace
First Find and replace " 1994 " with " 2013 " to keep from change that odd occurence of 1994 in a string.
Next Find and Replace " 94 " with " 13 ".
But what about the month and day, was the date totally wrong?
Paul in PA
For Now Use A Global Find and Replace
> But what about the month and day, was the date totally wrong?
Yes, off by 1024 weeks (7168 days). Easy enough to fix for one file via Find/Replace, but not something I'd want to do by hand all the time. I can automate it without too much effort, but that would still mean pre-processing every RINEX file. I'd much rather update the firmware.
For Now Use A Global Find and Replace
Jim
Out of curiosity, try running the rinex file through RinexDates. Your seek and replace procedure is very similar to the RinexDates procedure. If you don't have a copy you can get it under the "Services" tab above.
For Now Use A Global Find and Replace
> Out of curiosity, try running the rinex file through RinexDates.
I downloaded v1.6, but when I tried to set the compatibility XP wasn't an option -- only Vista and Windows 7 were available choices. My OS is Win7 64-bit, if that matters.
I tried running it anyway, and wasn't able to adjust the antenna height value. I didn't see any options for changing the dates, so just hit the Process button. It wrote out a file, but instead of moving it forward 7168 days it moved it backward by exactly 6 years. I don't know if that result is due to the compatibility issue or something else.
I'm open to suggestions.
For Now Use A Global Find and Replace
I'm running RD on win7 prof 64 bit. Reversing the file 6 years is what RD is supposed to do. I forgot you wanted to go forward in time. There isn't any antenna ht adjustment capabilities.
You could contact Christof and probably get the code for RD then alter it to go forward. Might save you some work. I'm not a programmer so I probably don't know what I'm talking about. You ever have that problem?
