Community Forums

Community Forums

Share:
Notifications
Clear all

OPUS Error 1020  


ChazB
Posts: 3
Member
(@chazb)
FNG
Joined: 1 month ago

I am having trouble with the date and time associated with data we logged with the intent of submitting an OPUS. The date and time appear to be incorrect even though they where correct on the TSC2 controller when logged. I tried downloading TEQC but am having trouble figuring it out and how to change (if possible) the date and time associated with the files. OPUS keeps returning the solution in error with the error code 1020. Ill post the top part of the RINEX if it helps.

 

2.11 OBSERVATION DATA GPS(GPS) RINEX VERSION / TYPE
cnvtToRINEX 2.30.0 convertToRINEX OPR 29-Jun-20 14:52 UTC PGM / RUN BY / DATE
----------------------------------------------------------- COMMENT
CP3 MARKER NAME
MARKER NUMBER
GNSS Observer Trimble OBSERVER / AGENCY
0220326010 R7 2.21 REC # / TYPE / VERS
TRM41249.00 ANT # / TYPE
-1399127.6849 -4195379.5367 4581944.7834 APPROX POSITION XYZ
1.5870 0.0000 0.0000 ANTENNA: DELTA H/E/N
1 1 0 WAVELENGTH FACT L1/2
4 C1 L1 L2 P2 # / TYPES OF OBSERV
2000 11 8 16 57 0.0000000 GPS TIME OF FIRST OBS
2000 11 8 22 58 20.0000000 GPS TIME OF LAST OBS
0 RCV CLOCK OFFS APPL
13 LEAP SECONDS
19 # OF SATELLITES
G02 2084 2079 2062 2062 PRN / # OF OBS
G03 356 349 351 351 PRN / # OF OBS
G05 1417 1416 1395 1395 PRN / # OF OBS
G06 1485 1483 1485 1485 PRN / # OF OBS
G12 1849 1833 1791 1791 PRN / # OF OBS
G13 355 354 331 331 PRN / # OF OBS
G15 327 327 311 311 PRN / # OF OBS
G16 76 76 75 75 PRN / # OF OBS
G17 876 874 875 875 PRN / # OF OBS
G18 732 731 730 730 PRN / # OF OBS
G19 1185 1185 1185 1185 PRN / # OF OBS
G20 206 205 195 195 PRN / # OF OBS
G21 197 197 196 196 PRN / # OF OBS
G24 909 902 885 885 PRN / # OF OBS
G25 1706 1698 1682 1682 PRN / # OF OBS
G26 545 545 544 544 PRN / # OF OBS
G28 429 428 423 423 PRN / # OF OBS
G29 1390 1389 1388 1388 PRN / # OF OBS
G31 318 316 316 316 PRN / # OF OBS
CARRIER PHASE MEASUREMENTS: PHASE SHIFTS REMOVED COMMENT
END OF HEADER
00 11 8 16 57 0.0000000 0 6G06G12G17G19G24G28
21677097.41416 -1057320.14516 -801197.07458 21677096.57858
24030555.76615 -868483.09415 -670637.05156 24030551.68056
20908506.37517 519647.59417 386388.52059 20908502.30159
20023973.88317 -50000.63717 -41516.22759 20023967.59859
21812555.50016 -361826.10916 -276412.50858 21812554.04358
22063766.66416 772602.48016 577445.59858 22063762.66858
00 11 8 16 57 10.0000000 0 6G06G12G17G19G24G28
21671961.508 7 -1084311.520 7 -822229.30548 21671960.59448
24024191.797 5 -901920.832 5 -696692.39546 24024188.72346
20911166.836 7 533626.051 7 397280.81349 20911162.25849
20023878.125 7 -50503.434 7 -41908.01649 20023872.05949
21810953.820 6 -370243.488 6 -282971.50448 21810952.47348
22067672.930 6 793128.945 6 593440.23048 22067668.55548
00 11 8 16 57 20.0000000 0 7G03G06G12G17G19G24G28
24392299.85214 -12336.77714

 

The date and time shown here says it was logged in 2000... however it was logged on June 24th around 9 am through 4 pm. Any help is appreciated. This project is a 4 hour drive away and we would hate to have to go recollect to properly correct it into a state plane job.

8 Replies
Paul in PA
Posts: 5966
Member
(@paul-in-pa)
5,000+ posts
Joined: 10 years ago

Something you are using is not up to date, but you can easily fix it.

Open your RINEX "O" file in WordPad and do a "replace all". Replace 2000 11  8 with 2020  6 24, or it might be replace 00 11  8 with 20  6 24, since I am not sure how every line reads. It may be neccessary to do the same with your RINEX  "N" file.

I just had to do it with a GPS observation I did today. My problem is the internal battery in the GPS receiver needs to be replaced and I have not gotten around to having that done, since I am not doing GPS every day or even week. I think today was the first time since May 6 and the second time since January.

Paul in PA

Reply
Rover83
Posts: 331
Member
(@rover83)
250+ posts
Joined: 4 years ago
Posted by: @chazb

0220326010 R7 2.21 REC # / TYPE / VERS
TRM41249.00 ANT # / TYPE

I agree with Paul, there is something going on with the receiver itself.

If that is truly v2.21 of the R7 firmware, that is around 15 years old. At the very least it does not account for the latest GPS week rollover of last year, not to mention leap seconds. I would get the warranty up to date and download the latest firmware.

Reply

Javad Triumph-LS with 4 Super-Engine RTK

ChazB
Posts: 3
Member
(@chazb)
FNG
Joined: 1 month ago

Thanks for the input guys. Yes the receiver appears to be very out of date. Its not a setup we use often but in this case we thought it would be nice to do 3 static observations at the same time. And now here I am having to manipulate the data to work... I attempted to replace the date string with a new string. It appears to have worked fine but when I submit it to OPUS it now thinks the data set is less than 7.5 minutes long and will not process it. 

 

EDIT: Added another space between the date and time strings and it has been submitted just fine. We will see what OPUS gives me.

 

EDIT2: Opus came back and the redundant ties to each point line up great. Thanks again for the help!

Reply
Larry Scott
Posts: 790
Member
(@larry-scott)
500+ posts
Joined: 6 years ago

A friend of mine has a Hemisphere GPS receiver. The native binary files appear to be correct. But when he exports to rinex they’re 1020 weeks retarded. And the Nav too. A simple TextPad search replace and opus is completely happy. It’s a software fail probably not a receiver fail, but I don’t know for sure. The manufacturer probably knows all about it by now.

All of my receivers are week rollover afflicted. Z12s. I have a fixer app that with 2 clicks and done. Knowing the issue, I have no fear using them in all applications. But I always use static, kinematic (aerial mapping) post process kind of guy. 

Reply
4 Replies
Jaccen
Member
(@jaccen)
Joined: 1 year ago

100+ posts
Posts: 181

@larry-scott

What software is he using to generate the RINEX from the BIN file?  What antenna is he using?  We use the S320 weekly and have not had any issues uploading to NRCAN's PPP.  The software is a bit fussy on making sure you select the correct antenna.  I tested OPUS about a month ago for giggles and it worked fine for us.

Reply
Larry Scott
Member
(@larry-scott)
Joined: 6 years ago

500+ posts
Posts: 790

@jaccen

It’s a bit more odd than that. (I misspoke in my earlier comment.)

We were measuring a typical static line and he sent me his data in Rinex. The obs file was 100% ok. Opus returned no error.

however the nav file he sent had incorrect date; week rollover effected. Gnss would not process our differential observation. I inspected his rinex obs saw proper date: 20  5  8

however the nav file that he sent had: 00  9 23

He re-extracted and the same mismatched dates: obs file correct, nav file retarded. In the header:

RINEXSKX2 2.9.3  HEMISPHERE PGM

HEMS320   ANT # / TYPE

He rarely uses rinex, so he had no idea, and it took me quite awhile to realize ONLY his nav was wrong.

(I have fix my Ashtech ZSurveyor and Z-XII all of the time.)

 

Reply
Paul in PA
Member
(@paul-in-pa)
Joined: 10 years ago

5,000+ posts
Posts: 5966

@larry-scott

Easiest fix for a wrong nav file is to go to NGS CORS RINEX site, pick the broadcast nav file and rename it to match your Observation file. You can also use any other nav file for that day from your own field work if sufficent hours were observed.

If not correct your nav file in wordpad. Be aware that a nav file may include some of the next days data so you will have two wrong dates to correct. 

Paul in PA

Reply
Larry Scott
Member
(@larry-scott)
Joined: 6 years ago

500+ posts
Posts: 790

@paul-in-pa

I’ve crosses those bridges. TextPad repair of obs and nav long ago. Retrieving Broadcast nav file from my favorite UFCORS was SOP years back when ZXII rolled over. Week rollover reared it’s ugly head in Z-XII long before ZSurveyor fell prey. (Which still puzzles me.)

The MISMATCH from hemisphere was wholly unexpected. (It’s fix was a no-brainer, once found.) As the hemisphere obs was correct, suspecting its nav file came only after looking for every other possible defect.

and I have new cmos batts all round, new NiMh batt for ZSurveyor, and 3 identical 701008 geodetic antennae, I think I have fine array of gps for a while yet. I think the antenna is the most critical component. Z data is as good now as any L1/L2 data. 

And the rinex fixer util that a friend wrote for me just streamlines opus submission, which I access quite often. 

Reply
Scroll to Top