This group is for LSU members who use Trimble in the field. This group is for discussions and tutorials related to Trimble user. LSU is not directly affiliated with Trimble and all logos and imagery are copyright of their respective owners.
I am attempting to update an R8 receiver for the upcoming GPS week rollover. Currently it has v2.31 and according to Trimble v2.32 needs to be installed to handle the rollover. After downloading the WinFlash utility and while it is configuring the software update I get the following error:
Device Failure [824] The software for the Trimble R8/R6 on Com1 cannot be upgraded due to the firmware and hardware mismatch.
Any ideas on what to do next?
You need to be a member of Land Surveyors United - Surveying Education Community to add thoughts!
Replies
Trimble has indicated that there is an issue with their firmware that will cause the 5700 and R7 models to become inoperable after the GPS week roll over on 14 FEB 2016. The issue also affects the 4700/4800 series receivers too, but there is no solution to fix it. If your receiver is running with a firmware less than 2.3 it will need to be updated in-order for it to operate again.
To assist the UNAVCO community we have written instructions on how to upgrade your firmware to 2.32 and a copy of the program that is needed to upgrade to 2.32. The attachments are available below. If you have bad data, instructions are also below too on how to correct for the week offset.
Please note that it is most likely that you will need a warranty code password to update you receiver. The receivers expiration warranty date can be found using WinFlash. If is older than 1/2004 you need to send your list of serial numbers to Trimble and request the codes.
UPDATE 16 APR 2016: Email addresses for requesting codes:
UNAVCO Community members : [email protected]
non UNAVCO Community members :[email protected]
The following is a statement from Trimble that explains the issue.
Trimble message:
On February 14, 2016, certain older versions of Trimble firmware will experience what is akin to a GPS week rollover. Trimble 4700 and 4800 GPS receivers, that are long obsolete and end of service, will not handle this rolloverevent properly and will experience erratic and unreliable behavior for time and date reporting. As those receivers will interpret the GPS time in error by 1024 weeks, receiver data outputs will have the wrong time reference. This will negatively impact subsequent systems that are communicating with that receiver, potentially including the rejection of data packages.
More recent Trimble GPS/GNSS receivers types, including Trimble 5700, NetRS, NetR3, NetR5, NetR8, and NetR9 with current firmware are not impacted by the upcoming rollover on February 14, 2016.
Further testing has shown the 4000SE/SSE/SSi will also handle the rollover without issue.
For the single 5700 receiver listed, this can be updated to firmware v2.30 or higher and will be fine. All NetRS receivers reported showed firmware versions which are not impacted (v1.1-0 or higher). All firmware versions for the NetR3/5/8/9 platforms are unaffected.
Unfortunately, there is no technical solution available for the Trimble 4700 and 4800 GPS receivers to correct this issue.
Regarding communications, every receiver model is being handled by their respective Business Areas within Trimble as far as how they communicate the rollover to their users. In our case, while these impacted receivers reside within other Business Areas, we are reaching out to our users in cases where we're aware they are running such units to give a more advanced heads up.
############################################################################
IMPORTANT: For users who have bad data that was collected after 14FEB16.
You can correct for the week offset in the data by using TEQC to create your RINEX data. By using the "-week" flag in TEQC, you can force the correct week to be used when creating RINEX files.
e.g teqc -week #### FILENAME.dat > FILENAME.obs (where #### is the GPS week number that that the data was collected on).
For example, here is a RINEX file created using just the raw data file and no TEQC flags:
-Unknown- -Unknown- OBSERVER / AGENCY
0440100569 TRIMBLE 5700 1.24 REC # / TYPE / VERS
00000000 TRM41249.00 NONE ANT # / TYPE
-1282457.3621 -4718377.6066 4084178.4582 APPROX POSITION XYZ
0.0530 0.0000 0.0000 ANTENNA: DELTA H/E/N
1 1 WAVELENGTH FACT L1/2
7 L1 L2 C1 P2 P1 S1 S2 # / TYPES OF OBSERV
17 LEAP SECONDS
SNR is mapped to RINEX snr flag value [0-9] COMMENT
L1 & L2: min(max(int(snr_dBHz/6), 0), 9) COMMENT
1996 7 12 18 32 30.0000000 GPS TIME OF FIRST OBS
END OF HEADER
Here is the same data but this time the '-week 1885' flag was used:
-Unknown- -Unknown- OBSERVER / AGENCY
0440100569 TRIMBLE 5700 1.24 REC # / TYPE / VERS
00000000 TRM41249.00 NONE ANT # / TYPE
-1282457.3621 -4718377.6066 4084178.4582 APPROX POSITION XYZ
0.0530 0.0000 0.0000 ANTENNA: DELTA H/E/N
1 1 WAVELENGTH FACT L1/2
7 L1 L2 C1 P2 P1 S1 S2 # / TYPES OF OBSERV
17 LEAP SECONDS
SNR is mapped to RINEX snr flag value [0-9] COMMENT
L1 & L2: min(max(int(snr_dBHz/6), 0), 9) COMMENT
2016 2 26 18 32 30.0000000 GPS TIME OF FIRST OBS
END OF HEADER
Great, it works efficiently, thanks a lot