Running 5.90.1 in TBC. Long day and brought my data into TBC tonight to take a quick glance at RMS values and double observations on some of the control I am establishing. Have more work tomorrow long drive long day. Anyway I am getting this invalid leap second on my start and end time for my vectors. I can change to gps time all is fine. I have not seen this in years. We are running 2023.10 in access. I did a job before new years with same equipment no issues.
I've seen this too but it's been a while. I saw it on some daily RTK data that the crew started with a HERE position for OPUS.
I've only ever changed it to GPS/Local time and saw no issues. I'm interested to read what others think on this topic.
This error has popped up here and there in TBC for a while now.
At various times it has been linked to old firmware in the receiver, a bug when converting from native JOB format to JXL format, outdated TBC versions, and sometimes one of the under-the-hood components of TBC needs updating.
(Like many larger firms, our PCs are locked down six ways from Sunday, so we can only install update packages that have been "pre-approved" and modified to not need admin rights to install. Unfortunately, this leads to the occasional bad install where one of those components does not get loaded.)
When it's a TBC issue, you can switch the time settings like @squirl mentioned and everything will work just fine.
I do know that at one time, running the "Configuration Utility" would sort it out, but I think that utility is now defunct.
I would either install TBC 2023.1, or reinstall 5.90.1. Either way, make sure you run the Cleanup Utility before installing a fresh version.
I had to start with a HERE position but we do this all the time and it just pops up from time to time. I like taking the daily files and as/qc and also flipping it around to help the crews know what time to re observe the control the next day as I can quickly look and make a good estimate of when and order for them to get a time separation for next day especially when they have had a long day. Now I have to do math for myself and lol figure gps time to local since I am doing this project. Got it done today. lol
So I did rtk base and rover a site BM was set in the corner of a concrete pad that had a metal huge power pole so whole entire south west quadrant is pretty much blocked I had some down time yesterday waiting on sue markings so I said what the heck. I did two observations 4 hrs apart yesterday 180 epochs to BM. Today did one this morning early.03’ vertical from yesterday’s. Different base location today. The engineer on site asked for verification the BM on the plans matched the finish floors published. 3 different buildings. So I set up on one of my control points bs another turned rounds to another and the BM that’s should be in a not gps place I shot the finish floors and all did all the differences. Any way my conventional set from a decent gps position and the other two knows matched the gps rtk on the BM by .03 ft. I was actually amazed. I did this for fun gps ing it and was kinda hoping for the opposite so I could use it as a teaching tool for crews. I have another site next two days but looking forward to the least squares on this one. Hz and vt all seems good from field perspective and a quick qa/qc. The rtk units are just getting amazing now days. Oh I did a top shot with r12i on finish floor leaning r12i for giggles and got .05 ft different than robot . This is a tall metal building with a conveyor running over head Should not be that close.
Thanks. I am in the same boat. Big company and updates are a no no. lol. I put in a ticket to schedule a reinstall for next week as soon as I put these fires out on sites. Smiling drive tomorrow new site new challenge lol. Will be setting control and tying down finish floors and site BM to see if they match. lol. To much fun working solo to sort this out.
I am getting same error using TBC 5.9.1. I was evaluating several NETR9's we have logging data around the country and thinking this was a recent bug. I was just about to submit a ticket in the Trimble RTN forum, then found this post! Thanks RPLS!.
My tests reveal that regardless of FW version on NETR9 and even the lates FW version on an Alloy, this invalid leap second error persists, but only after JANUARY 1, 2024. Prior to the julian year, any data off of same receiver (multiple tests again), no leap second error. Error resolved when switching Project time to GPS, but that is not a desirable fix.
I also consistently run the Cleanup tool prior to all major updates (e.g. 5.9). I wonder if this error persists in v. 2023?
Seems they need to fix this bug. lol. I have a ticket into my dealer about this. Still no word
I wonder if this error persists in v. 2023?
I'll tell you as soon as I get my damned IT department to upgrade me!
It used to be the accountants ran firms. Now it's the accountants and the IT departments.
@rover83 The Dilbert cartoons used to have an occaisional character 'Mordac - the Preventer of Information Systems'
I'm sure I've worked with him in real life
Well all I know is I have checked many files and different versions of Trimble Access. Everything that starts in 2024 has this issue in two states. That I have checked so far. We all run the same version of Trimble Business Center. So something in the version 5.90.1. The distributor only asked if that was the only jxl file I saw it in. I said nope I can send you a bunch more. He said no need. I am just glad Someone else is seeing it. That at least lets me know my old brain didn’t do something dumb.
A quick fix for Invalid Leap Seconds until trimble will update Configuration utility.
Open C/Program Data/Trimble/LeapSecondsConfig/LeapSeconds.xml
Edit that xml and change the date at 2024-07--01
Yeah I did just that and such to get it fixed. Temporarily. Thanks for placing the info here.
I edited the XML file awhile back, and I think it worked at the time, but today I'm getting the "invalid leap seconds" message again. 🙁
I think in the last few updates tit has failed. I have not used TBC in over 6 months now and have got calls from others that have been seeing this. It’s a nuisance more than anything else. I did get my issue resolved by using the cheat sheet basically what others here provided and the support at dealership. But that was back at the beginning of the year.
I always tracked the time of shots taken for control and property corners as part of my qa/qc process. And this affected that for local time. I think I worked around it by changing it to global or whatever and such until I got it fixed.
Do you get a prorated discount on your fees for the time you cant use TBC?