AHA !
Much success. Both methods worked !
- via serial port, with modified "LOADER.EXE"
- via frontpanel. I found the key sequence : power on normally; go to the Modify menus, press "More" to get to the last page, then enter "567355"?ÿ . Easy to remember, that's "OPTION".
- enter password (indeed, generated from the unit's serial # and specific option value, so in my case "EE68EF4DF8" to activate the 1PPS option. This code will not work on any other unit of course.
?ÿ
Funny story : I modified my battery caddy to add a more convenient DE9 serial connector, but I realized too late that the caddy uses the "PWR2-3" connector which only has?ÿ the signals for serial port #3. That is one of the options that needs extra hardware. My unit lacks that, so I now have a decorative serial port!
Since the code and serial numbers seem to both be 10-digit numbers in hexadecimal, I wonder if it could be as simple as a value for the feature XOR with the serial number to make the code?
Hi Bill, you're on the right track ! It is a bit more convoluted though, there's a few extra steps of mangling involved. Do you still have a working 4000 ?
?ÿ
(Side-note : just tested "Trimble DataTransfer" (Windows-based), couldn't get it to run under Wine but it works fine in a VM, with the gps hooked up via an USB-serial converter.
Could you help me ?, I would like to enable RTCM and CMR output for a base station based on an old 4000ssi that does not have that option enabled, Thank you.
Oops ! I thought I had notifications enabled for this thread, but I never knew someone else posted. I assume you're the one who emailed me ?
On vaguely related note, I took one of my 4000SSi units out last week for the first time in over a year, and discovered that it no longer knows what day it is.?ÿ Or month.?ÿ Or year.?ÿ Not a big deal to correct the RINEX file, but the interesting thing is that it changed from one wrong date (in 2017) to another (in 2018) partway through the file.?ÿ I guess the firmware finally lost its ability to cope with the week rollover.
I ran my 4000sse units this spring/summer and found the dates differently wrong versus sessions in December, but consistent during the sessions. I'll have to watch for that date jump in files.
Still able to get correct .o20 with the week option in TEQC so can run through OPUS. I don't get .nav output, though.
I lost the ability to read .dat files into the old Topcon Tools to get vectors with short sessions. Have to convert to RINEX first now for TT.
Still able to get correct .o20 with the week option in TEQC
I haven't been bothering with TEQC for this, just find/replace in Notepad++.?ÿ The time-of-day is correct, it's just the year-month-day that are wrong.
I went down the same rabbit hole as fenugrec. He's a smarter guy than me because based off of his post dates it only took him a day to figure this out. It took me a little longer. But the end result is this handy little tool that can be used to enable just about any feature on a 4000 series receiver, or at least the 4000SSi. I haven't tried with any others:
http://beefchicken.com/gps/trimble/4000/optioncodegenerator/
Happy upgrading.
Wow, that's an impressive effort!
For me it generates more questions than answers, though.?ÿ Like, what the heck does TailBuoy do??ÿ And why would Caltrans want half-cycle L2??ÿ And how on earth did you ever figure out the encryption parameters?
In any event, nice work!
I suspect Tailbuoy relates to a communication protocol similar in function to RTCM but optimized for the signal environment when communicating the data by radio from a towed buoy over a rough sea surface, a problem for seismic exploration.
https://www.ion.org/publications/abstract.cfm?articleID=4910
?ÿ
The BeefChicken domain name and how you came upon it is pretty funny.?ÿ Thanks for sharing!
For me it generates more questions than answers, though.?ÿ Like, what the heck does TailBuoy do??ÿ And why would Caltrans want half-cycle L2??ÿ And how on earth did you ever figure out the encryption parameters?
I thought the Tailbuoy and Caltrans options were especially interesting too. I guess the size of Caltrans' GPS network warranted special attention ?ÿfrom Trimble.
As for how: I could tell by looking at the raw data in the firmware file included with the update utility that the file wasn't encrypted, but I could also tell it wasn't a raw binary image either. But I could see fragments of strings that I would see displayed on the receiver's LCD screen, so I knew it wasn't far off. I quickly learned that the firmware image was encoded in a well documented format for a HP 64000 development system that breaks the memory image up into a bunch of 244 byte fragments. I threw together a tool to reassemble the fragments, then I fed the reconstructed memory image into a disassembler that understood Motorola 68332 machine code.
From there, I started with the most promising string: "ILLEGAL PASSWORD". I found where in the code that string was being referenced, then work backwards from there to find the subroutine that was being called that determined if a password was valid. I found the subroutine that was being used to validate the password, and manually translated it instruction for instruction into a higher level programming language. I used an excerpt of the 68332 assembly subroutine modified very slightly to run in a 68000 simulator to verify my assumptions. Once the logic of the password validation process became clear, it was easy to figure out the inverse process of generating a code that would satisfy the algorithm.
I left out a bunch of steps that really only serve to document my ineptitude when it comes to reverse engineering, but there is one other interesting discovery one that anyone can try at home:
The firmware update tool (loader.exe) includes an undocumented command-line parameter, '-M', that puts the receiver into ROM monitor mode. From monitor mode, it is very easy to read (and write!) memory locations of a powered-up receiver, which was immensely helpful with validating assumptions. The monitor mode also includes a command to dump the current option configuration. By monitoring the data on the serial port while this command was being run, I was able to determine the memory addresses where the options and serial numbers were stored. The location that was being read for the serial number was consistent with a 'mystery' location being read by the password verification code, for example.
Final observation: the firmware image includes references to GLONASS. It appears in strings that aren't being used by the code, but it's a sign that Trimble maybe had versions of the 4000 receivers that supported GLONASS.
Nice web UI Keelan - way more fun than my tool that stayed at the "crude but functional" stage.
Since that's all out in the open I might as well post mine too; trimble4000_genopt
I find front-panel entry more elegant than the patched 'loader.exe' method, so I won't bother uploading that.
?ÿ
My idea for the WNRO issue was to try finding a really old firmware version before the first rollover ~1999 IIRC, to see how they fixed it. I wasn't able to find anything older than 7.19b and I looked pretty darn hard. I didn't bother asking Trimble directly of course. Now the project is shelved since I have a 5700 that I don't have to work 100h to get working...
As for how:?ÿ [long detailed explanation of stuff of which I understood maybe 75% in concept only]
I've always figured this sort of reverse-engineering was possible, and I'm way impressed at your ability to muscle through it all.?ÿ Although I'm a fairly advanced do-it-yourselfer -- willing to tear open things that were never meant to be torn open by any but the initiated -- I'm going to chalk this kind of task up to the realm of I'm-never-going-to-get-there.?ÿ I'm grateful for the insight into the process, though!
My 4000SSI is also still working. Still tracking Satellites and calculating positing. Tested 30 minutes ago with 10m antenna cable and Microcentered L1/L2 antenna. Has WNRO-patched firmware installed Version 732B.X .
Do you have same Firmware and maybe options installed on working and not working units.
Maybe some old almanach?
Maybe something from "advanced test mode" can help, but i dont know that exactly. At your own risk.
https://beefchicken.com/gps/trimble/4000/secrets/
?ÿ
I put 732b.x on all of them, most work, but 3 (so far) have the "no sv" problem.?ÿ?ÿ
I haven't been very methodical in my approach, so I'm not sure about the following, but I *might* have gotten one to work by reverting to 719c.x, but I know that didn't help on the others.
I'm pretty sure it isn't an almanac problem, as I've let them all cook for at least 20 minutes, in some cases a couple of hours.
?ÿ
?ÿ
interesting that this is happening to "several" of your units.
"Several" turns out to be two.?ÿ One of them now has dead internal batteries, which I'm loath to replace since the investment in batteries would be for nought unless a fix for the no-track condition becomes available.
If one of you diagnostic wizards would like to take a crack at identifying the problem, I'd be willing to ship the dead-battery unit to a CONUS address without expectation of return regardless of outcome.?ÿ You'd have to load firmware and keep it powered up during testing, but if you can solve the problem you'd have a functional 4000SSi for the cost of diagnosis and new lithium cells.?ÿ Let me know if interested.