I was asked in July to look at a trimble file that, when imported to TBC, had a date of 1879 Yes, EIGHTEEN SEVENTY NINE. Those were the really early adopters of GPS! The only thing I could figure out is that it was due to an older version of software, either rumpkr00 or TBC. I had TBC 3.4, and there was no problem with the date. Whatever version of TBC the person had, I had a newer version. You would think that the software would default to 1/1/1980 (start of GPS time) if the GPS week and seconds of week were corrupted in the file.
Another person sent me a similar problem today, where the date in TBC 3.40 was 1879. He was using an older 5700. When I looked at the data, I couldn't find any problem (TBC 3.60). Since I had 3.40 before, and that was the problem this time, I am not sure what is going on. Maybe a runpkr00 bug. I sent the .T01 file to RTX, it processed fine with the correct date.
Anyone ever heard of this?
Sounds like clock drift, or maybe alternate universe time portal a lÌÁ 'Hot Tub Time Machine'.
Just because I'm paranoid, doesn't mean they aren't out to get me.
"Great white buffalo..." 😉
We had the same thing happen a few weeks ago. I updated TBC and reimported the files and all was well.
Well, Marty and Doc were here recently...
Interesting that updating TBC helped, because the first time I saw this I was not able to replicate it using TBC 3.4 (the user had an older version, I don't remember which), and this time the person HAD 3.40 and saw the problem, and I could not replicate it in 3.60.
Yes, we had that same issue, it is a head scratcher, not sure what is going on, all I can say it that it didn't affect anything.
All the processing would work and we just pushed along.
Basically, I ignored it since it wasn't causing any real problems.B-)
It was no where near the disaster of the ft/ft "calibration" issue back in the day.
Just another of Trimble's little quirks :-S
The person who had the problem in July said that Trimble stated "known problem-upgrade TBC".
I hold out [REDACTED] as the way a software provider should do tech support...using a knowledge base and forums. Carlson also has a lot of good stuff in their tech support website.
Trimble is, in my opinion, severely lacking in tech support for software as far as bugs, etc. The more complicated that software gets, the more important it becomes to get the work out about bugs and fixes.
We had a similar incident a few days ago with a Topcon raw data file. 1.5 hours of data was gathered a few days ago for an OPUS submission. The date of each epoch for the first few minutes was 2007. The month and day was correct, but the year was 2007. We changed the file to RINEX and I corrected the dates in a text editor and it went through OPUS with flying colors. However, you can't help but wonder how the system came up with a date of 2007. Why not 1879, 1942 etc? Anyway, apparently this happens occaisionally with Topcon data when the receiver is "confused" for the first few minutes during startup. The remedy in this case is to let the system run a bit before you start logging data, but that's a bit inconvenient.
I am not familiar with how Topcon stores their data. Trimble uses a week number and seconds of the week. Week 0 was 1/1/1980, so there should NEVER be a GPS date earlier than that. This week is 1868, and today at 10:30 EDT would be 484200 seconds of the week.
It may have been that the Topcon receiver used some date in 2007 as a "default" date until the clock was set.
There have been problems with some hardware and software when the week "rolled over" from 1024 to 1025. If I recall correctly, the problem was that the GPS broadcast uses a truncated value to save bandwidth, so week 1025 was week 1, etc.
John Hamilton, post: 342387, member: 640 wrote: The person who had the problem in July said that Trimble stated "known problem-upgrade TBC".
I hold out [REDACTED] as the way a software provider should do tech support...using a knowledge base and forums. Carlson also has a lot of good stuff in their tech support website.
Trimble is, in my opinion, severely lacking in tech support for software as far as bugs, etc. The more complicated that software gets, the more important it becomes to get the work out about bugs and fixes.
They have their share of them for sure, this one didn't seem to be any issue, or cause problems, but it sure looked weird...........
We have always gotten pretty good service from them, but I can't remember the last time I called anyone up, it's been many years.
I didn't for the 1879 year thing
When I first started using Trimble GPS (1986), there were like 50 people there, so it was easy to get someone to talk to. The people I knew then are gone.
I used to meet with the actual guys, the programmers themselves, I doubt that happens anymore.
John Hamilton, post: 342315, member: 640 wrote: Interesting that updating TBC helped, because the first time I saw this I was not able to replicate it using TBC 3.4 (the user had an older version, I don't remember which), and this time the person HAD 3.40 and saw the problem, and I could not replicate it in 3.60.
To clarify our email conversation a bit, when I had this issue I was running 3.3. Updating to 3.4 fixed it, and I am currently running 3.6 without issue. https://surveyorconnect.com/threads/opus-a-new-to-me-receiver.322531/page-2#post-334942&apos ;">This is the old thread.
This may have had something to do with accommodating the leap second that was introduced on July 1.
Another possible source could be that the receiver is set to start logging on powerup. I've had some squirrely dates/times with this in the past, especially if the receiver hasn't been used in a while (old ephemeris). The solution for that would be to let the receiver run for a few minutes before starting your survey using the controller.
John Hamilton, post: 342387, member: 640 wrote: The person who had the problem in July said that Trimble stated "known problem-upgrade TBC".
I hold out [REDACTED] as the way a software provider should do tech support...using a knowledge base and forums. Carlson also has a lot of good stuff in their tech support website.
Trimble is, in my opinion, severely lacking in tech support for software as far as bugs, etc. The more complicated that software gets, the more important it becomes to get the work out about bugs and fixes.
John,
Back in the day, over 20 years at this point, Trimble had a great tech support system. I had a list of engineers/programmers in Sunnyvale, if I had a problem I just gave them a call. Point in case, in the days of Trim-Vec you could not process data between units collecting at different rates. Some how we ended up collecting at a 15 second epoch on one SST and 5 seconds on another. Got on the phone with one of the programmers the next day and by the next day I had a patch for Trim-Vec downloaded over the phone line. As time went on their support got worse and unless you could get in touch with one of their senior support staff. TGO had a specific bug for years that was acknowledged by Trimble but never addressed. One of the reasons I jumped ship to Leica.
Concerning technical support, it seems to go through cycles with all manufacturers. Trimble was great long ago, as mentioned above. Then they got pretty bad. Then they became pretty good again. Other companies seems to be pretty much the same. In my experience the best time to work with any company is when it is relatively small and suceeding. They're still a small enough group of people to communicate with you and with each other. When they become larger and more successful it usually gets worse. Sometimes it later improves, sometimes not. It's really all about sales not technical support.