One problem persist. In the receiver the time activation part is not triggering the file logging as it did it before. I must do the start and stop part manually using GPS Configurator or Via reset. Is it any solution available to avoid manual part?
GEO_XXL, post: 358875, member: 8981 wrote: I have new receivers as well.
I hope they have not infested the ne one with the some kind of "bug". 😀
Not yet...they will be fine until the date that Trimble determines them to be "obsolete".
GEO_XXL, post: 358893, member: 8981 wrote: One problem persist. In the receiver the time activation part is not triggering the file logging as it did it before. I must do the start and stop part manually using GPS Configurator or Via reset. Is it any solution available to avoid manual part?
I have my R8's set to auto start on power up, as can be configured in GPS Configurator. The 4700's also start automatically, but GPS Configurator will not work on those units. I think you can only set that via GPS Configuration Toolbox for the older units.
It was instructed to time activate via App File loaded into receiver using Configuration Toolbox.
John, I note that you haven't responded to the inquiries about the DAT format specification. Are you subject to a non-disclosure agreement with Trimble, or did you reverse-engineer the spec on your own? Just curious!
Jim: I was given those formats in the late 80's by a friend who worked at Trimble since the beginning. I agreed not to share them, just my word, nothing signed. But I am a man of my word. I would not feel comfortable giving them out. Plus, I don't want any troubles with Trimble (or is it Troubles with Tribbles?).
Since the .dat format is so old maybe Trimble would release that information. But then again, maybe not, that might ruin their planned obsolescence of the older units (or did I just do that). I started dealing with Trimble in 1986 when they had maybe 50 employees. None of those people are still there, so I don't have any current contacts to get the .T01 or .T02 specs, if they would even consider that. I don't think they would, because unavco teqc requires a dat file or a tgd file, so they obviously don't have access to those formats either. But I would like to have them for my own use. I write a lot of programs to make my life easier, and dealing with .dat files is one thing I taught myself over the years.
I hesitated before offering this program to anyone free, because I knew people would start asking for the formats, same as they did when I put fixdat out there. I was actually harassed by a foreigner to give him the formats.
I think Trimble is wrong to not offer a fix, so that is why I decided to offer this workaround free of charge to anybody who wants it.
I have said this before, one of my dislikes about Trimble is their proprietary stance on a lot of things. But I could never switch to another brand now, too old. I feel like the Bernie Sanders of the survey world, old, cranky, wearing wrinkled clothes, etc. Even socialist-giving things away for free.
It is true that other manufacturers have proprietary software and formats. Of course, there is always Rinex. And Trimble did release CMR out to everyone. But let's face it, Rinex has everything that you need in it, so why be so protective of internal data formats? Maybe someone who works for a receiver manufacturer can weigh in.
All that said, it is not a simple thing to deal with unless you are familiar with binary record formats. When Trimble only had the LOGST program for logging from a base (at the beginning of the CORS era), the local DOT asked me to write a program to capture the RT17 stream out of a 4000SSE receiver and create .dat and rinex files. It took me a while (I had plenty of other work to do as well), but I finally got it working quite nicely. They installed it at their CORS around the state (5 at the time). Then, Trimble started producing nice windows software for CORS, and when windows XP came out my program needed updating, but I decided not to support it anymore, too busy with other stuff that paid a lot better. But, by doing that I learned a lot about the data stream and dat files (and rinex as well, although that is pretty straightforward).
Maybe you should get some help fixing the old programs.
I need a working tool for CORS data logging. Let me know if you want to share the workload for that specific part. I have some experience in C,C+ ...
GPS Configurator is working fine with my 4700.
I'm able to get CMR output from my receivers using it ... 🙂
RT17 is described in this https://dl.dropboxusercontent.com/u/98820835/user_guide_bd970_eng.pdf&apos ;">user manual , raw data on page 128.
CMR https://dl.dropboxusercontent.com/u/98820835/Trimble-CMR.pdf&apos ;">here, GPS only.
TSIP https://dl.dropboxusercontent.com/u/98820835/TSIP%20Reference%20Manual%20-%20Rev%20C.pdf&apos ;">format, not sure what it is.
Ok
I'll start with rt17..
Thx
could not find any trace of 17 and 21 messages. they may be similar to rt17 messages, but not sure, was digging http://www.trimbletools.com/jcmbsoft/html/file_list.html&apos ;">here but no luck. yeah looks like they are hidden well.
I am experiencing this problem with my 5700. How do I update the firmware? Is the data I already collected no good at this point?
John Hamilton, post: 358870, member: 640 wrote: 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.
http://www.terrasurv.com/fixweek/FixWeek.zip&apos ;">FixWeek (zip file)
or
http://www.terrasurv.com/fixweek/Install_Fixweek.exe&apos ;">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.
Thanks John
I gave all my old equipment to my daughter. She has since bought an R10 so she seldom uses my stuff anymore but like you said, why throw out equipment that still gives great results.
Maybe Wendell can make a permanent spot for your program like he did for Christof's Rinex Dates in "Software and Cad" category.
A lot o thanks John ...
Dan Patterson, post: 358934, member: 1179 wrote: I am experiencing this problem with my 5700. How do I update the firmware? Is the data I already collected no good at this point?
Sounds like you are in the same boat as me. 5700's with current (2.32) firmware are apparently ok, however mine are v1.24 with a warranty expiry of 11/2001. v2.32 requires a warranty date of Aug 2004 I think. Data up to the end of GPS week 1883 is fine, and any static data since then can be fixed using John Hamilton's routine. If you are only using them for static it's a workable solution.
I am very doubtful these will be able to be resurrected, it's unlikely Trimble will allow users to sign up to a current maintenance agreement on receivers which are past end of support. The lure of getting a few dollars might sway them, but they would get more if people buy new receivers. Time to go see what's in the market.
In The Sandpit, post: 358959, member: 99 wrote: Sounds like you are in the same boat as me. 5700's with current (2.32) firmware are apparently ok, however mine are v1.24 with a warranty expiry of 11/2001. v2.32 requires a warranty date of Aug 2004 I think. Data up to the end of GPS week 1883 is fine, and any static data since then can be fixed using John Hamilton's routine. If you are only using them for static it's a workable solution.
I am very doubtful these will be able to be resurrected, it's unlikely Trimble will allow users to sign up to a current maintenance agreement on receivers which are past end of support. The lure of getting a few dollars might sway them, but they would get more if people buy new receivers. Time to go see what's in the market.
Well if they aren't going to support the 5700, which I only use for static control observations, then I will just get a CHC instead. (In this case I am using a few static observations to confirm network solutions on some control). I don't need to drop a lot of money on a new static receiver.
first document i linked to, actually contains information about dat messages, p 128:
Report Packet 57h can contain one of the following types of raw data, depending on
options selected in Command Packet 56h:
-Expanded Format (*.DAT Record Type 17 style data) raw satellite
measurements
-Concise Format (*.DAT Record Type 17 style data) raw satellites measurements
-Position data (*.DAT Record Type 11)
John Hamilton, post: 358908, member: 640 wrote: I was given those formats in the late 80's by a friend who worked at Trimble since the beginning. I agreed not to share them
FYI, I inquired of UNAVCO about the DAT format spec -- I figured they had it, as teqc can read DAT files -- and was told that they signed an NDA with Trimble.
Although I haven't tried it, the UNAVCO source says that you can produce good RINEX files from the wonky DAT files by using the -week option in tecq to specify the correct GPS week.
Some interesting information from the teqc documentation:
Trimble *.dat files: there is no GPS week information in Trimble's DAT observation records--though the GPS week appears in other records which are usually in a *.dat file. Additionally, when using teqc with DAT files as target files--not stdin--teqc will attempt to find a name-matching MES file to help resolve the GPS week problem. But, again, there is no guarantee that a matching MES file is present.
This begs a question for John H: what does your FixWeek application use to determine the correct week number?
Just compare the two timestamps from the corrected and uncorrected files and you-l get the module ...
This will not fix the problem ... you need to correct other records as well. I found the Algorithm somewhere on the net.