Any post-leap-second reports?

I collected 2 hr 15 min on each of 6 receivers this morning in what has become a post-leap-second addition ritual. All processed in OPUS-STATIC with excellent results. (X90D-OPUS, X900S-OPUS, X91+, X900, I80, SP80).

I also got fixed solutions off my PF500 base, my N71 base, and the two CORS stations that I run.

My buddies in Europe have not had any disaster events, yet.

So I guess it is safe to go to work on Tuesday.

I have thought about getting a simulator, but I don't know if you can trust the signal modeling software.

These leap second addition events are stupid, unneeded and put unneeded strain on infrastructure. Hopefully someone smart will just let them build up until there are five minutes worth and fix it all at once. And I will be retired, so I won't care.

Our R8 setup just tested out fine.

Mark Silver, post: 406972, member: 1087 wrote: These leap second addition events are stupid, unneeded and put unneeded strain on infrastructure. Hopefully someone smart will just let them build up until there are five minutes worth and fix it all at once. And I will be retired, so I won't care.

Well, if I understand correctly, this is mostly a problem for multi constellations, GPS time isn't changing, just the offset to UTC and since GLONASS uses UTC, it becomes an issue. If all constellations used the same time reference, I believe the issue would be moot to post processing. Or am out in left field with that line of thinking? Occasionally you read an article about doing away with multiple "times", BUT there would probably be a large one time learning curve for systems that depend on UTC.

SHG

Everything seems to be working just fine for me today.

I have an R8s how can i test and make sure everything is as should? I just read a report from the company i bought my equipment dating back to a couple of summers ago leap second incident stating a restart of the units will bring everything back to normal.

Mark Silver, post: 406972, member: 1087 wrote: I collected 2 hr 15 min on each of 6 receivers this morning in what has become a post-leap-second addition ritual. All processed in OPUS-STATIC with excellent results. (X90D-OPUS, X900S-OPUS, X91+, X900, I80, SP80).

I also got fixed solutions off my PF500 base, my N71 base, and the two CORS stations that I run.

My buddies in Europe have not had any disaster events, yet.

So I guess it is safe to go to work on Tuesday.

I have thought about getting a simulator, but I don't know if you can trust the signal modeling software.

These leap second addition events are stupid, unneeded and put unneeded strain on infrastructure. Hopefully someone smart will just let them build up until there are five minutes worth and fix it all at once. And I will be retired, so I won't care.

Thanks Mark, I am glad that you are watching out for us X-90 OPUS users.

Happy New Year.

T.W.

therock003, post: 407048, member: 12282 wrote: I have an R8s how can i test and make sure everything is as should? I just read a report from the company i bought my equipment dating back to a couple of summers ago leap second incident stating a restart of the units will bring everything back to normal.

Locate known points

Mark - does your report on the X90 and the i80 mean I am free and clear to operate either with no worries? Or do I need to run some checks?

Sent from my iPhone using Tapatalk

BushAxe, post: 407087, member: 11897 wrote: Mark - does your report on the X90 and the i80 mean I am free and clear to operate either with no worries? Or do I need to run some checks?

Sent from my iPhone using Tapatalk

I think they are fine, I purposely did not wait for a new ephemeris to download, just turned them on. Then 2:15 later turned them off and submitted 1 hour later.

MightyMoe, post: 407079, member: 700 wrote: Locate known points

Of course but how big of an error are we talking about in case there is one. Like could it be 0.5-1m and more on a fixed solution?

With Sokkia GSR2700ISX had no issues today i tested it.
The receiver was connected to my countrys cors and it obtained fix without problems using 16 sats.
I anyway did a factory reset for it to get the new almanac and had no problems after that also.

therock003, post: 407122, member: 12282 wrote: Of course but how big of an error are we talking about in case there is one. Like could it be 0.5-1m and more on a fixed solution?

I wouldn't expect to see anything at all, I can't see how this could mess with a GPS receiver.

MightyMoe, post: 407144, member: 700 wrote: I wouldn't expect to see anything at all, I can't see how this could mess with a GPS receiver.

From what i understand its a GLONASS thing. If you have issues that aren't overcome by clearing NVRAM and waiting for new ephemeris turn off GLONASS and see if things run. Then you probably need to load new firmware.
That's my best guess..

thebionicman, post: 407149, member: 8136 wrote: From what i understand its a GLONASS thing. If you have issues that aren't overcome by clearing NVRAM and waiting for new ephemeris turn off GLONASS and see if things run. Then you probably need to load new firmware.
That's my best guess..

That makes sense, early on with GLONASS there was a glich and using GPS and GLONASS together would create a small error, using GPS alone things were fine but adding GLONASS to the solution there would be a consist error that was about .15', uploading new firmware fixed the issue. I suppose it was a matter of working out differences in the two systems.

MightyMoe, post: 407150, member: 700 wrote: That makes sense, early on with GLONASS there was a glich and using GPS and GLONASS together would create a small error, using GPS alone things were fine but adding GLONASS to the solution there would be a consist error that was about .15', uploading new firmware fixed the issue. I suppose it was a matter of working out differences in the two systems.

GLONASS uses it's own time which is very very close to UTC, GPS uses GPS time and now they are 18" different. They also use different reference frames, PZ90 and WGS84 respectively. New constellations coming on line I believe also use different reference frames and times, so you end up with a real mix and match of reference frames and times used that all have to be reconciled to produce a position.

SHG

It was -20 this morning and the heater was off in the office, might run some tests later in the afternoon when it warms up

Test for R8 .001N, .004E, .011V in feet.

R10 was similar.

Leap second didn't cause any issues.

Interesting results from Monday static. I tested RTK Sunday. Cleared NVRAM and let both units cook 40 minutes. All appeared ok.
Monday I had issues with radio for a few minutes and ended up starting the base several times. I pulled three static files off, all back to back.
The first went through OPUS RS and came back 2cm horizontal and 4 vertical. The second two files were much tighter as they were longer.
Solution 1 was 50,000 by 10,000 meters different. The observation times and file names matched up perfect. Good thing radio was being finnicky...

I cranked up my Topcon Hiper Lite Rover this morning and collected a point while connected to the FDOT RTN without a problem. However, when I set up my Base unit to do some RTK observation, the data collector kept saying no GPS position at the base. I then noticed that it was having problems tracking on the base unit. It was indicating that it was only tracking 3 sats while the rover was tracking 8-9 at the same time right next to it. I cleared the NVRAM on the base and let it run for 20 minutes to get a new almanac. After that it was fine. Strange that both my units are the same model running the same firmware, but only the base had a problem.