Community Forums

rollover or year 20...
 
Share:

rollover or year 2000?  

Page 1 / 2

hpalmer
Posts: 86
Member
(@hpalmer)
50+ posts
Joined: 9 years ago

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
1 Reply
Bill93
Member
(@bill93)
Joined: 9 years ago

5,000+ posts
Posts: 5362
Posted by: hpalmer

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.

Reply
Josh4
Posts: 19
Member
(@josh4)
5+ posts
Joined: 3 years ago

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. 

Reply
Paul in PA
Posts: 5714
Member
(@paul-in-pa)
5,000+ posts
Joined: 9 years ago

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

Reply
3 Replies
hpalmer
Member
(@hpalmer)
Joined: 9 years ago

50+ posts
Posts: 86

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.

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

500+ posts
Posts: 585

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. 

Reply
hpalmer
Member
(@hpalmer)
Joined: 9 years ago

50+ posts
Posts: 86

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.

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

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. 

Reply
3 Replies
Bill93
Member
(@bill93)
Joined: 9 years ago

5,000+ posts
Posts: 5362
Posted by: Larry Scott

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.

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

500+ posts
Posts: 585

I’ve seen it before, just not 12-14 hours after midnight Z. 

 

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

500+ posts
Posts: 585

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

Reply
Paul in PA
Posts: 5714
Member
(@paul-in-pa)
5,000+ posts
Joined: 9 years ago

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

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

500+ posts
Posts: 585

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. 

 

 

 

 

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

5,000+ posts
Posts: 5714

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 

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

500+ posts
Posts: 585

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  

 

 

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

500+ posts
Posts: 585

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. 

Reply
Mark Silver
Vendor
(@mark-silver)
Joined: 8 years ago

500+ posts
Posts: 563
Page 1 / 2