There is no reason that the 1024 GPS week should be affected at this time. The current cycle runs till April 2018. Did Trimble build in a kill date.
Paul in PA
Paul in PA, post: 358731, member: 236 wrote: There is no reason that the 1024 GPS week should be affected at this time. The current cycle runs till April 2018. Did Trimble build in a kill date.
Paul in PA
That's what I am wondering. It's week 1884 currently, so if they were using a mod function that returns week 860. Must be some part of the bios which has hit a overflow for a particular field.
According to trimble, the extended GPS week number in message 0x41 is limited between 860 and 1883. The work around suggested is to add 1024 if week number < 1800 https://goo.gl/13tR3i
This was disturbing news, because I do have some older units that still work just fine, 2 4700's and 1 4400. We rarely use the 4400, but I do use the 4700's for long static sessions.
So. I took one of my 4700's out today and collected some data. It is indeed showing 1996. It is actually the current week (1884) minus 1024=860.
I modified my fixdat program to add 1024 to the week number in several records in the dat files:
record type 5 subtype 1 (session information)
record type 12 (receiver configuration)
record type 19 subtype 5 (GPS WEEK TIME SYNCHRONIZATION)
record type 21 (ephemeris)
I don't know if all of those are necessary, but those are the locations I know for sure have week numbers in them. I suppose I could do one at a time to see. The actual data records (type 17) only have seconds of the week, so they get the week number from one of the above, I believe it is 19-5. But, the ephemeris records are probably important also to be the correct week.
It worked, the file translates fine to rinex with the correct date/time, imports into TBC with no problem, and processes fine.
A very simple fix, why wouldn't Trimble do this? Because they don't like that we are still using 20 year old receivers. On the other hand, it is a testament to the quality of the receivers that we are still able to use them and get good results from them (except for this bug). I also have newer receivers, R8's and an R10, so it is not like I never update, I just see no reason to scrap a perfectly good dual frequency receiver.
I will do some more testing to make sure, but I am heading to Denver tomorrow for the Lidar conference.
John Hamilton, post: 358831, member: 640 wrote: I modified my fixdat program to add 1024 to the week number in several records in the dat files
Where can one find the DAT format reference?
Is it a software available to fix the date in dat or rinex files anywhere?
I asked Trimble support if they will fix the issue by releasing a new firmware.
this is the answers received from them.
"
from the technical side we can't do here anything.
You may have to talk to your Sales man regarding and exchange of these receivers.
BR
Roland
..............................
here we can't help you out, you have to talk to your Sales man regarding your problem.
BR
Roland
...............................
i don't know who i can contact here to get a solution for this too old product.
You can talk to your sales man if there is maybe another solution.
BR
Roland
.................................
i don't think that Trimble will do here something on these very old units.
They are a long time out of service.
BR
Roland
"
This is clear for me .... the firmware is TIME-BOMB
For the one who want I just posted some test data on dropbox.
If someone want to access my 4700 base station just give me a message and I'll arrange remote access (serial over NET - LANTRONIX).
I do not know how to send a link to my dropbox location ... and the files are too big to be attached.
In The Sandpit, post: 358788, member: 99 wrote: That's what I am wondering. It's week 1884 currently, so if they were using a mod function that returns week 860. Must be some part of the bios which has hit a overflow for a particular field.
I'll go outside for a small test with 3x4700 receivers and one base station. All with 1.41 firmware (the last available). Then I'll try to share with you the data.
John Hamilton, post: 358831, member: 640 wrote: This was disturbing news, because I do have some older units that still work just fine, 2 4700's and 1 4400. We rarely use the 4400, but I do use the 4700's for long static sessions.
So. I took one of my 4700's out today and collected some data. It is indeed showing 1996. It is actually the current week (1884) minus 1024=860.
I modified my fixdat program to add 1024 to the week number in several records in the dat files:
record type 5 subtype 1 (session information)
record type 12 (receiver configuration)
record type 19 subtype 5 (GPS WEEK TIME SYNCHRONIZATION)
record type 21 (ephemeris)
I don't know if all of those are necessary, but those are the locations I know for sure have week numbers in them. I suppose I could do one at a time to see. The actual data records (type 17) only have seconds of the week, so they get the week number from one of the above, I believe it is 19-5. But, the ephemeris records are probably important also to be the correct week.It worked, the file translates fine to rinex with the correct date/time, imports into TBC with no problem, and processes fine.
A very simple fix, why wouldn't Trimble do this? Because they don't like that we are still using 20 year old receivers. On the other hand, it is a testament to the quality of the receivers that we are still able to use them and get good results from them (except for this bug). I also have newer receivers, R8's and an R10, so it is not like I never update, I just see no reason to scrap a perfectly good dual frequency receiver.
I will do some more testing to make sure, but I am heading to Denver tomorrow for the Lidar conference.
I have some experience in programming (C,C++) so if someone is able to provide the right GPS technical support a general fix for the bug will be the output of the collaboration. (Yoda style:-D).
Thx,
Radu
A friend 10+ Km from my location will do the same with one or two receivers.
I'll add to the test the data from the closest permanent station.
Here is a fix for this problem. I am offering a program to fix the problem, similar to the fixdat program I wrote for the TGO date problem.
This problem is a bit different in that you cannot fix it by going to TBC.
FixWeek (zip file)
or
FixWeek (self extracting executable)
If you click on the first link, it will download a zip file. Unzip it, and run setup to install the program. During the installation it should create FixWeek in the start menu. The other link will download a self extracting setup.
When you run the program, navigate to a directory with the dat files. Once it finds dat files, it will display them in a box with check marks. Uncheck any dat files you do not want processed. It does check to see if the week number is greater than 1024, so it shouldn't change any files that are correct. Note that it does make backups of the original file.
I can assure you this does not contain anything malicious, no viruses, etc. I don't know of any easier way to distribute it, but there are probably some out there who are not able to install it due to company or agency IT policies. Nothing I can do about that.
I just made this, so please let me know if it does not install correctly, or if there are any problems or bugs.
It is working ... tested using 6x4700 1xR8-2 2xLeica 1200.
Tkx. A lot ...
It should be implemented in the new Firmware if they will release one.
It'll never happen...the firmware that is...they want you to buy a new receiver. Like I said, I have newer receivers, and use them constantly. My favorite is the R10. But why throw away a perfectly good static receiver.
I have new receivers as well.
I hope they have not infested the ne one with the some kind of "bug". 😀
gschrock, post: 358876, member: 556 wrote: Thank you John! Many beers owed.
I only had a few left and gave those to a university that uses them campaign style occasionally for plate velocity studies - they will be happy to have your fix. I sure got a lot of mileage out of those old bricks, but was desperate to upgrade as any gear from that era were not working as well as newer gear for our real-time and monitoring needs. On our third wave of upgrades so we have many from the middle era for static (hope those last another 5+ years).
Hey Gavin, No problem. I have bugged you plenty of times with questions, so we are even!
Jim Frame, post: 358842, member: 10 wrote: Where can one find the DAT format reference?
I am looking for *.dat binary messages description too, if someone can share that would be great, thanks.
Also wondering if 4600 are affected as well.
Beside God we trust only static measurements!
Long Live Trimble Users around the world!!!!
I'll ask a friend about how the 4600 is working after feb. 2016 event.
Test results
BUCU - Leica1200
M & T 4700 except
T2-1 R8-2
SUBNET 'TestTrimble' POINTS: ADJUSTED COORDINATES in WGS84( BLH )
-----------------------------------------------------------------------------------------------------------------------------
Point Coordinates Sigmas(mm) Corr.(%)
# Name Comment Latitude Longitude height(m) s(N) s(E) s(U) N-E N-U E-U
-----------------------------------------------------------------------------------------------------------------------------
1 BUCU 44å¡27'50.19686"N 26å¡07'32.65697"E 143.1994 0.0 0.0 0.0 0 0 0
2 M-1 44å¡25'52.21937"N 26å¡02'06.99051"E 126.0964 1.1 0.6 1.9 -10 16 -16
3 M-2 44å¡25'52.14936"N 26å¡02'06.46343"E 126.1224 1.4 0.8 2.3 5 2 -11
4 M-3 44å¡25'52.21933"N 26å¡02'06.99076"E 126.0933 1.9 1.1 3.1 11 -33 -15
5 RADU 44å¡28'06.41681"N 26å¡03'44.63895"E 142.1309 0.0 0.0 0.0 0 0 0
6 T1 44å¡28'09.02353"N 26å¡03'43.79732"E 123.7366 0.5 0.3 0.9 -8 2 -16
7 T2 44å¡28'08.93869"N 26å¡03'43.83727"E 123.7262 0.8 0.5 1.4 -14 25 -16
8 T2-1 44å¡28'08.93877"N 26å¡03'43.83726"E 123.9403 0.7 0.4 1.1 13 -22 -24
9 T3 44å¡28'08.82089"N 26å¡03'43.88835"E 123.7343 0.6 0.4 1.1 -4 8 -30
10 T4 44å¡28'08.87657"N 26å¡03'43.81989"E 123.6634 0.6 0.4 1.0 5 -16 -26
-----------------------------------------------------------------------------------------------------------------------------
