-
rollover or year 2000?
Our 530’s appear to have survived the rollover and I was pleasantly surprised. I could not connect to our base using RTK to confirm a precise position as we are broadcasting RTCM 3.x and the receiver firmware only accepts 2.3. Anyone know a workaround?
Also, anyone having problems with the rollover or is it more like the year 2000 issue?
-
25 Replies
-
The short answer to your problem would be to change your base to output RTCM 2.3 and then the rover could accept it. Depending on what kind of base you have you could create a second mount point if you are using the internet to connect to it. If you are using radios then every other rover that connects is going to lose the GNSS ability when you degrade to RTCM 2.3. Another option is to have two radios connected to different ports running on different frequencies with different corrections.
Thanks for the post. I am glad to hear things are still working.
-
Our 530’s appear to have survived the rollover
Um, I think the rollover happens about midnight UTC minus leap seconds as Saturday ends. It’s still Saturday.
. -
You have survived nothing yet, your Doomsday may be UTC midnight 4/06/2019, tonight.
I am off for two 2 hour plus OPUS observations, plus tie ins to two previous control points on the same filed map. Will probably set on the two new points again on Monday just to check my receivers. Have 7 GPS points in this subdivision to date and with all side shots to other monuments find nothing off more than 0.10′. More than required for swimming pool plans, essentially the GPS is for elevations. The filed map tie ins are investments in future surveys. Most of this work is in one local township that has low impervious coverage limits and on average 40% of pool plans in that township have required variances. Many of those were over the limit before a pool was even planned. Mitigation of runoff is in my wheelhouse.
Paul in PA, PE, PLS
-
Darn and I thought the 530’s survived – will check them tomorrow.
Josh, I need L5 and Galileo for some sensors. I will try and stream both a 2.3 RTCM and a 3.2 RTCM over different ports using same static ip and report back. The 530’s have served us well as has our base station. GPS is alive and well as I had 8 good sv’s this morning.
-
I teased the dog, I recorded from 22:30 to 00:55. That appears to be problematic. I??ll take another obs tomorrow.
But my gear has been returning 1999 dates for a while. Editing the rinex has not been an issue.
-
Our 20 yr old Leica 530’s survived . Was able to record both static and RTK data this morning and checked same in GeoOffice. Would be good to have firmware that read in RTCM 3.x or if I can figure out how to broadcast both RTCM 2.3 and 3.x from our Spider base.
-
Looks bad for me.
I logged normal static data from 22:30 to 23:59 on 06Apr. My older receiver does return 1999 date, but I edited the date per usual. Opus error reports ??fewer than 3 base receivers data available?.
Very sad. Hopefully today??s trial will be better.
Maybe the rollover messed up batch uploading of cors files.
-
I had 2 receivers for more than 2 hours yesterday, but they had not been run since 2018, due to the very wet winter. Both were very slow to download ephemeris and collect enough satellites. Both returned 1999 dates which I had edited and have good solutions in my post processor. Did not senf off to OPUS because it was past UTC midnight before I had them ready, so in caution I will do it latter today. Because they have sat so long I may also have internal battery issues, which I have been expecting since I bought them well used. Both will go on the exact same points Monday afternoon.
Paul in PA
-
My older Astech had the correct date (no edit required) in December! Then a few weeks ago it returned 1999, quick rinex edit and as good as ever. Yesterday not so much. AUSPOS and OPUS wouldn’t process data from 06Apr, 22:30 to 23:59 not even a weeksec rollover.
Thats disturbing. So I’ll mem reset and try for a cold start. I’m stuck with OPUS, I do have gnss free version. I’ll do that too for a differential baseline.
-
It was Y2K all over again here in Salt Lake. I did not think I would be able to sleep, not knowing if the receivers we have sold would be running on Monday. So, after dinner, starting at UTC 00:020 4/7/2019 I recorded 2 hour files on:
- SP80
- X90D-OPUS (with 2.32 firmware)
- X90D-OPUS (with 2.34 firmware)
- X91+Satel
- qty 2 iG8
- qty 2 PF500
- a C12 reference station
- qty 3 P3E network bases
Ran RTK on the X91+, SP80, all the network reference stations and the iG8’s
RTK looked great on all, static files all had the correct date and processed with nice solutions this morning in OPUS. Attempts to process the files last night gave me a scare and generated the OPUS error message:
1021 The year and day-of-year could not be determined from the submitted data set.
1021 The data set may be corrupt. OPUS can not continue the processing.
1021 Aborting...Processing the same files this morning returned ‘most excellent’ results. So, I am thinking that this 1021 error message really means “there is no CORS data available that overlaps your observation, please submit again tomorrow.” But, since I was expecting time/date issues the 1021 message did give me a scare.
And … I am very happy ???? to report that my old friend ‘GNSS Solutions’ soldiers on and generated exceptional results on all the post WNRO processed static files.
Here is a picture of my partial setup behind the office:
Like Y2K it was a lot of worry and drama. I am sure that others will hit the end of a line with older equipment and I am sympathetic to their loss. Thankfully all of the OEM engines we have been using lately survived.
Except that the MagellanPro,Ashtech,Spectra equipment required firmware updates. But after the update they all survived too. I kept a pile of older Ashtech/Spectra equipment un-updated so that I can play with it later this week.
Continue on, there was nothing to see here…….
-
Opus error reports ??fewer than 3 base receivers data
That’s a very common message if you submit before OPUS has time to collect CORS data, so I wouldnt read much into it and resubmit later.
. -
I’ve seen it before, just not 12-14 hours after midnight Z.
-
I have a Z-Xtreme and a Z-Reference Station, same inside I believe. I use them for control about every other week, so if I have to change dates from now on I can live with that. I also used 3 ProMark 2s yesterday and they were OK. I have been told they will be OK with rollover. Should find out tomorrow afternoon.
My OPUS came back OK, except the one receiver used an older raw position and I got CORS from far away. Edited the raw and am happy.
One of my 45 minute post process vectors came in “fail” with only 6 common satellites. Excluded it and used the other 3 vectors for that point. Cannot figure it out because all observation points were in the open. It was PM2 to PM2 so I looked into it. It was a PM2 that the first have of the file thought it was Kinematic, so I told it no. Turns out that for a long time 3 satellites did not have L1 observations, although the C1 data was there.
Paul in PA
-
Mark, I had a ProMark 2 yesterday come back with the first half of the file Kinematic. I said no and gave it a file name. I got a poor vector from it, turns out looking at the RINEX that for 3-4 satellites it was not solving L1, but C1 was OK. Instead of an L1 value it kept repeating 0.00018, is that an error code? Also had some occasional 15, 16 or 17.
I plan on trying some Zs tomorrow.
Paul in PA
-
Still no base receivers 20 hrs after midnight. And I’ve never seen that message after 1-3 hrs post midnight.
I think the data in the Ashtech is damaged.
One receiver down, one more to test
-
The ZSurveyor has older build: B0.
There is at least an E version, I hope it’s still available to flash the receiver. I was so happy until yesterday
-
Well the ZSurveyor data appears scrambled. The much older z12 data works just fine, date edited of course.
Spparently the Ashtech archive is gone. So if you know of any source for later Z firmware loads I’d be grateful. I guess I should’ve been more attentive.
-
Hi Mark, I upgraded the firmware of my MobileMapper 100 receivers to the required version. The date and time are correct in the receiver however once I download to GNSS Solutions, I’m getting a start time (time of first record) of August 22, 1999. The filename shows the correct year and Julian day and everything processes fine. Any thoughts…..?
Rich
-
Look here: https://ashgps.com/2/Z-Xtreme/index.htm
Specifically: https://ashgps.com/2/Z-Xtreme/Firmware/Z-Xtreme_ZE_21.zip
-
GNSS Solutions is working well for me when I import ‘good dated’ RINEX.
However the latest RINEX Convertor (V 4.7.1) is not converting G files correctly. (I have already dropped a note to the factory.)
So my guess is if you are importing G files into GNSS Solutions they are being converted incorrectly.
On my PF500’s the internal RINEX converter (the one that automatically processes the G files into RINEX on the attached thumbdrive) is working correctly. So, hopefully a new RINEX converter will fix this issue.
I suspect I will have additional information tomorrow. 🙂
Log in to reply.