Reading RPLS is free for the whole profession. Members post, reply, and get the members-only rooms.
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.
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
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.
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!
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.?ÿ
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.
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.)
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
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.
Larry, I recently acquired a pair of Hemisphere S320 receivers to replace my older Topcon Hiper Pro receivers.?ÿ So far so good, but I am now navigating for the first time how to submit to OPUS based on the BIN file logged onto the SD card on the S320 base.?ÿ Looks like I might need to convert the BIN to RINEX.?ÿ What software do you use for this??ÿ And, what is the "rinex fixer" utility you mention??ÿ Any help would be appreciated...
EDIT: I found Hemisphere's "Rinex - Desktop" conversion utility, version 1.9.3, under Utility Software on the page below:
https://www.hemispheregnss.com/firmware-software/
and managed to convert the BIN file to RINEX 2 observation file, and submitted to OPUS.?ÿ Barring an unanticipated failure, this looks like it'll work...Would still be interested to know about the rinex fixer and how/when you use it...
Al
@big-al
I do not have Hemi320, a friend does. The bin-> rinex did produce a valid obs file, no issues.
However, the quirk was that the NAV file was not valid. His NAV file was week-rollover afflicted, the dates 1024 weeks retarded. It drove me nuts. (I discarded it, and used a manually edited nav file. Of course you can download a broadcast eph/nav file. Or copy a correct nav file from another source.)?ÿ
my rinex fixer is for week rollover afflicted rinex 2.11 OBS files only. My Ashtechs return incorrect dates for the obs and nav files. I ??fix?? the obs file for opus submission, so the nav file is not used. And the Hemi rinex obs for opus was good. (Assuming you have the same version) ?ÿ?ÿ
It was the unbelievable output from the Hemisphere rinex that hit me: the obs correct, the nav incorrect. So, for fun, check the dates in hemisphere rinex nav file output and see if they??re correct. It was a funny glitch to see that the obs and nav had different dates.?ÿ