View Single Post
Old 09/05/2007, 10:13 AM   #17 (permalink)
2kgteclass
mumbles the madman
 

Join Date: Mar 2007
Location: RHODE ISLAND
Vehicle: 2000 Eclipse GT
Posts: 229
2kgteclass : who are you?2kgteclass : who are you?
Quote:
Originally Posted by fasteclipse00 View Post
Would/could I damage my ECU, by taking it apart and taking a picture?
You could if you arnt really carefull taking it apart and putting it back together, but I was hoping someone had one that they already swapped out that they dont need. Dont go putting your car in danger for it. The picture might help with some stuff, but for what I want to do I will definitely need a lab rat eventually. If it comes down to it I will open mine up and take a picture.

Quote:
Originally Posted by fasteclipse00 View Post
If other people wouldn't mind going in with me I would donate some money to get you a Fed Spec GT 5spd ECU. There are some on car-parts.com that are around $75.
Again, I was really hoping someone would have one sitting on a shelf, it doesnt even have to work. I just need to be able to trace each pin on the ecu board connector to the cpu and read the numbers off the other chips on the board so I can get their datasheets and find out what they do.

Quote:
Originally Posted by fasteclipse00 View Post
The programming is really out of my leage. Everything you guys has posted might as well have been jibberish. Also, I don't even know where to start looking to even get the vocabulary down.
Unless you have some limited experience with microcomputing and digital electronics, its a whole other world of information to learn.

If you do have any experience I would love to have some help on this project, It will most likely be written in the Eclipse Java API because it is platform independent for the most part and is available for free on Eclipse.org. My programming is a bit rusty so I will probably struggle a bit with coding at first. Once you get past the whole 1s and 0s thing, simulation of a microprocessor, especially once we find out what mode it is operating in will be a pretty simple endeavor.

My goals for this ecu simulator are-

GUI- should graphically show states of each pin on the ecu and cpu, should show contents of each register and indicate when each map is referenced. Should keep track of cpu usage stats to determine the potential for adding functionality and optimization of code.

H8 disassembled code should be traceable forewards and back. must be able to set breakpoints and jump into and out of subroutines. should have some type of text driven scripting for input simulation, this is so we can feed it all the variables that the car normally would(ie. TPS, Airflow, O2, RPM) and see what the code does with it.

This project is a bit beyond the scope of just getting the flash to work. It will undoubtably help with that too, but once completed, I am pretty sure that there are unused pins on the ecu harness that could be utilized for some purpose. For instance, we could conceivably have the ecu trigger a methanol injector, or nitrous, or both. I would like to have my ecu use wideband o2s as primarys instead of narrow band. Or possibly use wideband o2s during open loop and actually run closed loop on the wideband instead of open. We could make the ecu run subinjectors or even monitor egts and adjust timing accordingly. The possibilities are limited only by the ammount of unused potential of this cpu and the effort put forth by people who can put that potential to good use.

One problem I run into all the time is with my headers. Stock the primary o2s are about 3" away from the exhaust ports, this provides nearly instant reactions to closed loop adjustments. So when bank one goes lean, almost instantly the o2 goes lean and the ecu can adjust, when it adjusts, almost instantly the o2 goes rich and the ecu pulls some fuel to bring it lean again. With my headers, the o2 sensors are about 3 feet away from the exhaust ports and the volume of gas that must be displaced before the o2 sees the change is huge in comparison. I estimate that the ecu adjusts 12 times before the o2 sensor sees the first adjustment. This causes a pretty wide swing in AFR because the computer is way overcompensating. Somewhere in the rom there is a subroutine for closed loop operation that could be modified to slow down the adjustments so that the swing isnt so wide.
2kgteclass is offline   Reply With Quote