Hello guys,
I have noticed that this might be interested for you all (or some). I have bought cheap (<50EUR cheap) Trimble 4000SSE gps receiver. I have noticed that this receiver has been affected by the "recent" week rollover problem. That is because this equipment is very old and was made to survive only ONE week rollover.
I am not surveyor. I bought the unit to examine it. Take it apart and look inside - porn :). I have been also taking apart the firmware of the unit. Looking specifically for OPTIONS and week number calculation.
I have found both. And I was able to find and fix the week number calculation (by adding another 1024 to it). I also found a way to upload changed firmware to the unit.
I would like to know if there is interest in this firmware? I would come up with some way to distribute it. I don't want to release it in the wild, I don't want my work to be "sold" by random people on fleabay for example.
I have a couple 4000sse that I have used to contribute data to the GPSonBM program, so am interested in learning more about these units. Also have one that doesn't work, that may need a firmware reload.
I'd be interested, too.?ÿ I have a couple of 4000SSe receivers as well as some 4000SSi units that might be susceptible to the same fix.?ÿ
I don't use these?ÿ old receivers often, and there's a utility available to correct the dat files, but having the files come out of the receiver with the correct date information would be convenient.
Can you please check your versions ? I have only done work on this firmware:
Version 7.32 is compatible ONLY across the Maxwell Technology
based 4000SE/SSE/Si/SSi/RS/DS receiver product line. Maxwell
based receivers are either dual frequency SSE or SSi, or single
frequency receivers with part numbers that start with 21000-xx
or greater.
If you need the 7.19b it will take some time 🙂
I have mostly 7.32, with a sprinkling of 7.19 and 7.28.?ÿ But I think I can move all of them up to 7.32.?ÿ (I also just discovered that I need to replace the lithium cells in several units.)
Mine are 7.32 (plus one that doesn't work and I forget whether it shows a version.)
@jim-frame One of my 4000SSi receivers gave the "lithium battery dead" warning momentarily upon being turned on this past week for the first time since April. But, it still retained the data from the April session, it appeared to work normally, and it collected 6 hours of new data which OPUS-S processed successfully (it retained the new data while it was disconnected from the external battery after finishing collecting the data, before powering up on the OSM for offloading the new data). I'm trying to recall what's supposed to happen when the lithium battery is dead. Maybe my receiver's lithium battery is low enough to trigger the warning but not yet so low as to cause data loss, firmware loss, etc.
I'm trying to recall what's supposed to happen when the lithium battery is dead. Maybe my receiver's lithium battery is low enough to trigger the warning but not yet so low as to cause data loss, firmware loss, etc.
I'm thinking the same thing.?ÿ When I was checking firmware just now I ran into that message on one of the receivers, plus found a few others that had already gone all the way to "Remote Monitor Active" (a sure sign of dead batts).?ÿ I just placed an order for 10 Saft LS14250-AX at AtBatt.com.
Does the firmware need to be reinstalled after that?
Yes, once the internal batteries die the firmware disappears, unless the receiver is connected to continuous external power.
Those are lithium thyonil batteries, voltage will not tell you the state of battery. I think they just have timer to go off when you need to replace the battery. Normally lithium thyonil batteries will last for 10years or so. I have seen one recently which is 20years old and still good. But my 4000sse had one battery already dead. (there are 2 batteries for main board, and 2 batteries on each addon board) So i replaced all of them as its not really convenient to open the box very often.
Good thing is that there is no calibration to be erased and you only loose firmware with data. Replace batteries and reload firmware and you are good to go 🙂
@jim-frame Jim, when you've reloaded firmware before, were you using the self-extracing .exe files from UNAVCO's website? Were you using an ancient computer (Windows 95?) to run the loader? If so, a physical machine or a VM? Using a built-in serial port on the computer, or a USB/serial adapter?
And, have you supplied continuous power to a receiver that was not yet in the "Remote Monitor Active" state? I've not yet disassembled either of my 4000SSi receivers, so I'm curious whether one of the external power sockets will still be connected to the firmware board after disassembly (i.e. making it easy to use the normal cables to feed power to that board during surgery), or whether I'll need to clip or solder a temporary connection to somewhere on that board.
Thanks!
I've never tried to keep one powered on when replacing batteries.?ÿ It might be possible, but logistically it doesn't seem like a practical approach -- there's a lot of physical disassembly required to get at the batteries.
It's been a few years since I've loaded firmware, and the last time I did it I used an ancient Dell laptop running XP to do it.?ÿ I keep that around just for this purpose, but in the event that it doesn't fire up I'll have to explore other options.?ÿ As @robots suggests, there are probably ways to use a modern PC for the purpose, I just haven't tried any of them yet.
@robots I have made the same discovery as you! So far, I just changed the byte @ 0x1CACE from 0x4 to 0x8 with the ROM monitor, and then set the 'configuration changed' flag at 0x3FE to 'CODE', which is enough to get the change to survive exiting monitor mode, but not enough to survive a full reboot.?ÿ
?ÿ
That's what I figured out today, my next step is to figure out how to re-checksum the firmware image so that my modified image will pass the ECC without being "corrected".
Honest talk time: My plan is to release the fixed firmware into the wild, along with information on how I generated it. If it's publicly available, then the people trying to sell it on eBay have nothing of value to sell. If you want to save me some time, it'd be cool if you released your work into the wild, either way, it's going to be public soon enough.
And for those of you following along at home, here's how to use my crummy technique to temporarily fix your 4000SSe/SSi:
Download the firmware update package from Trimble, and from a DOS prompt run this:
loader.exe -M
4000SE/SSE/SSi & 7400MSi REMOTE MONITOR, V4.32
Initializing COM1
Finding receiver baud setting. Trying: 38400 baud, odd parity
Establishing link at 38400 baud, odd parity
PPU Version = 3.34
Receiver type=05
Link established. Defaulting to 9600 baud, no parity
SE/SSE/SSi H/W target receiver detected.
enter command: d 1cace 1 08
download data to target memory
starting address:byte count:Byte[0]:
enter command: d 3fe 2 c0 de
download data to target memory
starting address:byte count:Byte[0]:Byte[1]:
enter command: r
Wait for the receive to reboot, once it gets a satellite fix it will have the correct time.
If the receiver is rebooted again, it will warn that it found an error in the firmware, then correct the "error".
Okay, so that was easier than I thought. Details coming soon, but in the meantime, the Trimble 4000 Version 7.32 firmware corrected for WNRO until 2038ish is available here:
there?ÿ is bit that will rechecksum the whole firmware for you 🙂
@robots I saw it in there, but I couldn't figure out how to trigger it. I ended up just writing a piece of code to recalculate the checksum from the .X image.
