Hello everybody - I actually just found the time to resurrect my investigation. I had an old power up logic analyzer trace on the control and data lines on the ER1451 odometer ROM and just wrote a perl script to convert the serial trace into ROM access commands. The trace is incomplete, but it was good enough to start developing the script. Once I have a complete conversion script I can easily pass many analyzer trace dumps to it and try to decode what's going on. However, my first pass looks pretty daunting. These chips hold 700 bits of data organized into 50 14-bit words. I was assuming that there would be a lot of unused space in the ROM as even counting at the 'tic' level (Pulses from the speed sensor), you probably don't need that many bits to hold a number up to 200K miles or so(I've believe that I read that these "roll over" somewhere in the 200K range, possibly equating to whatever 100,000 Kilometers is in miles. There seems to be a LOT of data in use, though. More than it would appear to just hold the main ODO and if stored in there also, the trip odo. There may be some funky encoding scheme going on, or maybe multiple copies in a rotating buffer with pointers and the like to attempt recovery of a corrupt reading? It looks alot more complicated than I was originally hoping.
My plan of attack is to use my bench 12V supply with my spare cluster, which I have already sucessfully been able to feed a square wave to to simulate speed sensor pulses and rack up miles on the ODO (As well as exceed the speed limit!) I'll do several rounds of Racking up miles and saving traces that are both read and written to the ROM, including iterations where I only feed a single speed 'tick' to the cluster to see which bit(s) change from one round to the next along with the recorded ODO reading for that trace. Hopefully, with enough data collected, I'll be able to reverse engineer how the miles are stored.
My take on the * (Asterisk) that appears on some clusters is that the symbol is the electronic equivalent of "Not actual miles". I've heard that when you "roll over" the cluster, it starts at zero only with the asterisk. And when you get a new chip from the dealer it also starts at zero and has the asterisk. I also think I've heard evidence that a cluster that has been corrupted, but not to the point of the "------" of death, will also show the asterisk. I'll see what I can find out about that as well. Once I have a theory on the encoding; I can program test ROMs and see what the cluster reading looks like for different programming. I too have a schematic for a ER14xx programmer from a Russian website. I'm going to modify the design a little as it uses a coil type step up transformer to make the -37V programming voltage required. (For you EE2 out there - It takes a 12V DC, feeds it to a 555 as an oscillator to make it 12V AC, the off to a transformer to step it up to 3X or 36V, then MINIMAL filtering with a Diode and Cap. Looks pretty sketchy from a noise perspective and bulky with the transformer. I plan to find a suitable switching boost regulator to make a cleaner programming voltage)
I have a handful of ROM chips, but they are ER1400, which are 100x14 instead of 50x14. I believe that they will work fine, though and just have the upper 50 words unused as the access is random anyway and not sequential. ER1451's are impossible to find and even the ER1400's I have come across are getting expensive($25-$30 per chip) as there apparently is some demand for these in the vintage arcade game market. So, another project I plan to try is to make a small FPGA controlled emulator that will make a modern serial flash chip behave like the ER1400. Not really expecting to save cost here though, but it will make a bountiful supply chain available again, and with the plus if not needed the -36V supply at all! Also, I could make a programming "Back Door" that will make it easier to flash the mileage since most potential customers will need a custom mileage from their existing vehicle programmed in.
There will be waivers on use of course, but with the age of these cars, no one is going to really profit from false odometer readings. If the car has 200K on it, it's going to show - EVERYWHERE. And if a car looks like crap, but claims to have 40K on it, I'm paying on the actual condition anyway. Believe me, I've seen quite a few supposed low miles cars that looked like crap so there's no way I would have paid a premium on them anyway. Condition is everything when cars get to be this age. Still, there will be some waiver of liability on my part if someone provides false mileage for their chip. I'd really just be selling them a ROM with some arbitrary data requested by the customer in it and no guarantee of the usefulness or even the end use of the data provided.
On a side note, I'm also planning a re-engineering of the 84-87 Logic Module controllers. I believe that with modern technology applied to these old cars, not only can you provide better performance, but also smoother engine running. I believe the reason some of these older ECU based cars aren't as stable as their modern counterparts is the fact that the older, slower CPUs can't adjust to changing conditions as fast as newer, faster ECUs can. I'm probably going to stick with 8-bit for now, though as I'll have to port the existing source code and then tighten the loop timing and scale everything appropriately. I should be able to provide a 10x tighter control loop which should greatly improve engine response and still fit a few extra goodies like logging in. Since I'm in SMOG controlled California, the ECU will need to behave like a factory unit when hooked up to the tester's equipment, so that will be a challenge. Maybe I'll have a "SMOG Mode" switch. However, I expect the replacement computer to allow for lower emissions than stock, so I may even go after CARB certification. I'm sticking with the older LM
units for now because (1. They're located in the passenger cabin and won't need to be underhood resiliant. 2. They are basically just the Brain, with the Brawn in the power module under the hood. And 3. All of my Turbo Dodges are LM
equipped). Other people are working on SMEC
designs anyway, so I won't be duplicating other's efforts. I'm actually hoping to have the time to create a complete suite if interacting components to replace the electronics on my '84 Laser Digital Dash/31 Function Monitor/12-button Nav equipped car, with a single computer doing all of the work including the ECU and the Dash, Monitor, and Nav just being display units accessed by the main computer. The replacement equipment will be a combination of LED and LCD to replace the Vacuum Flourescent original displays. We'll see how far I get, this could take a while. The Odo Chip is a nice start, though and get's me working with my newly acquired test equipment. http://www.turbododge.com/forums/ima...tras/hello.gif