Rankin File sent me the Trimble 4000sst (see for-sale thread), on a trial basis and IÛªm encountering a lot of obstacles. I donÛªt have a real need for this capability, and even his low price strains the toy budget, but I wanted to play with OPUS sessions.
At first it gave nonsense date/times, then eventually started giving consistent values (but wrong, see below) and tracks satellites to give reasonable lat/lon/height values on the display. External and internal batteries are about dead (no surprise), so I can only work on AC power, but I want to see OPUS results before I invest in batteries. I still donÛªt have software working to get a RINEX file.
Some specific issues:
1. Does anybody still use the sst model? Almost all of what I find on line about the 4000 series is about other models which, although old, are newer than the sst, and IÛªd like to know that somebody has been able to keep it working.
2. The time of day appears to be correct. But the date, JD, and GPS week are in 1996, exactly 1024 weeks ago (magic binary number there). Is this a known problem with old firmware, or is this unit broken?
3. The firmware versions it displays are NAV 4.81 (25 Nov 92), SIG 4.20 (9 AprR 90), and Boot 2.00 (21 Nov 89). When I search the web I find UNAVCO recommending the 4000 series have version 7.19b but they donÛªt list the sst among the models to which it applies. Does that version work in an sst, does a separate update exist for the sst, or is this model stuck with whatÛªs there?
4. If a firmware update is available, what program(s) are recommended for loading it? RemCon (Trimble Remote Controller) seems to be one tool for doing it, but doesnÛªt find the receiver unit. At the moment I canÛªt get Trimble Data Transfer to run on my XP computer, and need to try a different computer. After RemCon gives up, I can use GPLoad (9600, 8 odd 1 on both) and it talks to the unit just fine, so I know the ports and cable are working. Is there some reason RemCon and Data Transfer programs shouldnÛªt work?
5. If I eventually replace the internal batteries, do I lose the installed firmware? If I take it off external power for a few minutes it says ÛÏNV RAM CorruptÛ and erases it, losing any measurement data and the ephemeris. But it still has its firmware. Jim Frame made an excellent post on replacing internal batteries. What I donÛªt understand is his reference to reloading the firmware after replacing the batteries. Does it really forget the firmware during this operation, and if so why hasnÛªt it forgotten it already along with the measurements? I haven't found any firmware specifically for the sst model, so I might make a brick out of it if I tried something.
6. GPLoad transfers files. ConvertToRinex opens the .dat file and shows reasonable header entries, but when I tell it to convert, it objects to the week number (see above), which I donÛªt know how to find and fix in the .dat file. WinTeqc gives me ÛÏUnhandled exception Û? startIndex cannot be larger than the length of string.Û If I tell it to ignore that error, I get a message ÛÏtranslation may have started with GPS week 1867 rather than 843Û so it is thrown by the bad week also.
7. WinTeqc also says ÛÏNotice rx is a 4000ST, 4000SST, or Geodesist-PÛ from which I infer these are significantly different from later 4000 series models. WinTeqc said to use TRRINEXo for this data, which I find on an ftp site from University of Bern, Switzerland. I havenÛªt fully explored that yet. Has anyone used it?
------
IÛªm struggling, so need advice on whether the quest to use the unit for OPUS is doable and how to get around some of the obstacles.
Breakthrough on #6/7:
It was set to "Standard Format." What else would you pick to start out with?
No, that's not what it needs. "Compact Format" gives me files that ConvertToRinex and WinTeqc will deal with. So on to the next stage, learning about RINEX.
I may be able to text-edit each RINEX file to patch the week problem?
The battery vs. firmware reload is still an important issue.
Bill93, post: 341174, member: 87 wrote: 1. Does anybody still use the sst model? Almost all of what I find on line about the 4000 series is about other models which, although old, are newer than the sst, and IÛªd like to know that somebody has been able to keep it working.
I've never laid hands upon an SST, so my comments may not be useful. But my belief is that the improvements in the SSe and SSi were so significant that the SST isn't a close competitor.
2. The time of day appears to be correct. But the date, JD, and GPS week are in 1996, exactly 1024 weeks ago (magic binary number there). Is this a known problem with old firmware, or is this unit broken?
Sounds like a GPS week rollover firmware problem to me.
4. If a firmware update is available, what program(s) are recommended for loading it?
winflash.exe is what I use for the SSe and SSi firmware uploads.
5. If I eventually replace the internal batteries, do I lose the installed firmware?
That's the way it works with the SSe and SSi models. In theory you could bridge the old batteries with a power source while removing the old and installing the new -- I think this is what Leica techs do with the old T-series theodolites -- but it would be a major hassle, and even a momentary loss of power would hose the firmware.
------
IÛªm struggling, so need advice on whether the quest to use the unit for OPUS is doable and how to get around some of the obstacles.
My advice is to go with a 4000SSe or SSi. They're pretty cheap, and work really well.
Never used an SST. The SSI I have here works just fine. I did have to reload the firmware after soldering in new batteries. Not a big deal compared to having to unscrew so many screws on the memory modules, unsoldering the old batteries, etc. That wasn't particularly fun. I suspect it'll get the date wrong immediately after the next rollover which is cumming up soon. I suspect some of my other newer receivers will as well.
astrodanco, post: 341245, member: 7558 wrote: I suspect it'll get the date wrong immediately after the next rollover which is cumming up soon.
It's coming up soon, if by "soon" you mean 2019.
It may be possible (though perhaps not likely) that the firmware update that addressed the first week rollover is also capable of managing the next one.
I'm probably not a lot of help, but we had an older 4000 system, but I don't remember what one, but we had to invest some money during he Y2K thing when it happened, otherwise the dates would all be screwed up.
Howdy,
I used the 4000SST in the early 90's. It was a good instrument for its time. Unfortunately, in addition to its age it has the tragic flaw of logging the L2 observable via squaring. The SSE and SSI receivers in the 4000 series logged the full L2 wavelength.
What does this mean? It makes the determination of integer unknowns more difficult and introduces noise. Relying on my memory (problematic at times) I recollect that you need to insure that the squaring status is included in the RINEX file. Given that these receivers are rare, if not gone, in the geodetic world, I wonder whether the L2 squared code is automatic when converting the .DAT file to RINEX.
In its heyday, it was used for some significant projects. On large extent projects using a mixture of SST and SSE/I receivers we took care to use the SSTs on the shortest baselines.
Hope this contributes,
DMM
I used 4000 SST's for several years until they were superseded by the SSi's. They were fine workhose receivers that we used primarily for static but also for post-processed kinematic without a controller. I would think that UNAVCO's TEQC would be very helpful for converting to RINEX and data QC. There are two issues I expect you will have to deal with regarding point 2. There was the GPS week rollover around 1999 then the Y2K changes. There were software patches floating around back then to fix both and it was a simple fix. There is also a website of a firm in the UAE that has parts and works on old Trimble receivers. You might see what they say: carpow.com. All the best. Those were excellent GPS units.
I first learned using SSTs. I remember collecting data and we all needed to aim our antennas in the same direction to take out possible error due to phase center issues.
I don't know anything about making good use of one today.
Tom Adams, post: 341346, member: 7285 wrote: we all needed to aim our antennas in the same direction to take out possible error due to phase center issues.
That's still SOP for me.
Tom Adams, post: 341346, member: 7285 wrote: aim our antennas in the same direction to take out possible error due to phase center issues.
I still do that to this day AND all CORS are aimed to the north also, so I continue that practice.
GeeOddMike, post: 341318, member: 677 wrote: it has the tragic flaw of logging the L2 observable via squaring
The Leica System 200's (299) also had that "flaw", as I recall the current Leica software will not even process the L2 squared data from the old 299's, you may find that OPUS will choke on that data too as that is about 20 year old technology in receiver design?
SHG
