Found it. The book says neutral start on/off. Not solenoid 1 and 2. The choices are 600, 700, 750 900 depending on MT, on/off A/C, on/off neutral safety.
Last edited:
3P's TCCS Disassembly/Analysis
- Thread starter 3p141592654
- Start date
Well as of late I find myself not having much time for anything, let alone working on the ecu. So here's the source code for the emulator.
It is an ugly beast like all of my code, so keep sharp objects away from yourself as you look upon it, for you will want to gouge your eyes out.
It is an ugly beast like all of my code, so keep sharp objects away from yourself as you look upon it, for you will want to gouge your eyes out.
In another thread someone was asking about the knock sensor system in the ECU. JJ gave a nice answer, but I wanted to go over a few finer details.
As noted, the knock sensors are just microphones and looking at the resulting signal on a scope just looks like a lot of noise. The ECU has a dedicated processor that gates and filters the knock sensor inputs. The main processor in the ECU talks to the knock processor and tells it which crank sector it is in (each crank sector is 30 degree interval, so we have TDC, TDC+30deg, TDC+60 deg, TDC+90deg, and then back to TDC again). Depending on the crank sector, the knock signal is analyzed over specific frequency bands to look for either knock events, or normal combustion sounds. This took enough processing 20 years ago that a dedicated CPU needed to be used. If knock is detected, the data is fed back to the main processor for further crunching.
The ECU does not respond to knock for all loads and rpm. Instead, it defines three zones of interest, and keeps track of the knock response separately in these zones. The maximum timing retard for each zone is stored in permanent memory, so it learns the knock sensitivity of the engine over time, and this is used for faster correction when knock is detected.
The maximum amount of timing pulled when knock is detected is fixed by a 2D map of load and rpm. The maximum knock that can be pulled is 15 degrees. Generally speaking, it does not go to the max value right away, but responds proportionally depending on the knock strength.
A timer is used to maintain the timing retard well after the knock event has stopped. This means that once knock is detected, the timing pulled lingers on the assumption that going back to base timing is just going to cause the knock to return. I'll discuss the algorithm and show a datalog example on my next post.
For now, I'll just post the max timing that can be pulled dependent on load and rpm. This map is at address DDC8h and has 13 rpm columns (1600 to 6400) and 7 load rows (36% to 78%). This is from a 7MGTE A/T gray plug ECU.
As noted, the knock sensors are just microphones and looking at the resulting signal on a scope just looks like a lot of noise. The ECU has a dedicated processor that gates and filters the knock sensor inputs. The main processor in the ECU talks to the knock processor and tells it which crank sector it is in (each crank sector is 30 degree interval, so we have TDC, TDC+30deg, TDC+60 deg, TDC+90deg, and then back to TDC again). Depending on the crank sector, the knock signal is analyzed over specific frequency bands to look for either knock events, or normal combustion sounds. This took enough processing 20 years ago that a dedicated CPU needed to be used. If knock is detected, the data is fed back to the main processor for further crunching.
The ECU does not respond to knock for all loads and rpm. Instead, it defines three zones of interest, and keeps track of the knock response separately in these zones. The maximum timing retard for each zone is stored in permanent memory, so it learns the knock sensitivity of the engine over time, and this is used for faster correction when knock is detected.
The maximum amount of timing pulled when knock is detected is fixed by a 2D map of load and rpm. The maximum knock that can be pulled is 15 degrees. Generally speaking, it does not go to the max value right away, but responds proportionally depending on the knock strength.
A timer is used to maintain the timing retard well after the knock event has stopped. This means that once knock is detected, the timing pulled lingers on the assumption that going back to base timing is just going to cause the knock to return. I'll discuss the algorithm and show a datalog example on my next post.
For now, I'll just post the max timing that can be pulled dependent on load and rpm. This map is at address DDC8h and has 13 rpm columns (1600 to 6400) and 7 load rows (36% to 78%). This is from a 7MGTE A/T gray plug ECU.
Thank for all your work 3p, very usefull 
It's going to be really interesting for me as you come to maps studies.
I'm going to make my own supervision and fuel piggyback (just applying a constant correction according to octane level).
I wish I could help, if you know and have the maps data, I may help doing charts like above.
++
RolluS
It's going to be really interesting for me as you come to maps studies.
I'm going to make my own supervision and fuel piggyback (just applying a constant correction according to octane level).
I wish I could help, if you know and have the maps data, I may help doing charts like above.
++
RolluS
So when this thing gets cracked will it be free for all to use? Do you need anydonations towards the project at this point?
I have to give credit to everyone who is working on this! It is amazing reading all the information that has come up. It just is so amazing to fully understand it the way you guys are writing it out!
A++
Thanks,
Devin
A++
Thanks,
Devin
For small proto board runs, nothing beats dorkbots...
http://dorkbotpdx.org/wiki/pcb_order
5$ per sq inch, 3 boards, double sided with silkscreen.
Not sure what "free to use" means mecevans. The ECU code has been available for over a year on assembla.com. Certainly you don't expect the expander board hardware to run custom code and diagnostics to be free!
http://dorkbotpdx.org/wiki/pcb_order
5$ per sq inch, 3 boards, double sided with silkscreen.
Not sure what "free to use" means mecevans. The ECU code has been available for over a year on assembla.com. Certainly you don't expect the expander board hardware to run custom code and diagnostics to be free!
For those that can't wait to get their engines tuned, the following quality and professionally designed full-control hardware is available:
* Haltech - http://www.haltech.com/
* Vipec - http://www.vi-pec.com/
* Link - http://www.linkecu.com/
* Autronic - http://www.autronic.com/
* Wolf - http://www.wolfems.com/
* HKS - http://www.hksusa.com/products/?id=1965
* MoTeC - http://www.motec.com.au/
3P - don't worry, mate, I got the 1JZ-GTE professionally tuned for a bloody good price, with a quality name-brand ECU.
BK.
* Haltech - http://www.haltech.com/
* Vipec - http://www.vi-pec.com/
* Link - http://www.linkecu.com/
* Autronic - http://www.autronic.com/
* Wolf - http://www.wolfems.com/
* HKS - http://www.hksusa.com/products/?id=1965
* MoTeC - http://www.motec.com.au/
3P - don't worry, mate, I got the 1JZ-GTE professionally tuned for a bloody good price, with a quality name-brand ECU.
BK.
I've got a LIPP housing, which is not an exact copy of the Lex. Some sort of calibrated flow meter test setup is needed to answer the question. Right now, the only accurate comparison on the car is idle, and that is the least accurate measurement because the bypass air is the largest as a fraction of total air flow.
Just going by site....the screw only goes about 1/2 inch across the top edge which is 2 1/2 inches across. It hardly covers anything in the big cavity. My 7M meter isn't even close to it. It goes halfway, and the bypas cavity is much smaller. Which I thnk most people know. But the stock Lex meter the screw is barely in the chamber. So as I am going to say in the other message, I have mine backed out almost all the way, and it runs perfect.
Are you able to pinpoint where fuel injection events occur in relation (via crankshaft rotation) to ignition?
I suppose this only matters at low rpm/load, but it would still be good to know.
I suppose this only matters at low rpm/load, but it would still be good to know.
Yes, I know that piece of code that sets the injection start point. Unfortunately, it is not a constant, it is calculated based on a formula that scales with the duty cycle of the injector, so it varies with injector duration and rpm. I will dig out the formula and post it.
Hi,
I'm new here, just finished reading this whole thread last night. I have a 1KZ-TE ECU on the way from Japan and I want to get ready for descrambling it if needed. Its a "avance" ECU supposedly. I assume it is using techtom hardware or something very similar.
Can someone explain how to use the TechTom Descrambler? Specifically what does the 16 bit "software_id" refer too?
I want to try to descramble a rom that I already have.
Thanks!
Todd
I'm new here, just finished reading this whole thread last night. I have a 1KZ-TE ECU on the way from Japan and I want to get ready for descrambling it if needed. Its a "avance" ECU supposedly. I assume it is using techtom hardware or something very similar.
Can someone explain how to use the TechTom Descrambler? Specifically what does the 16 bit "software_id" refer too?
I want to try to descramble a rom that I already have.
Thanks!
Todd
toddm;1735067 said:
The "software_id" is a 16 bit number (in hex) that is stored in the ROM at a known position. The very same number is also stamped on the chip. For early chips the markings are:
D15180x-xxxx
7433-yyyy
where yyyy is the "software_id".
On later chips the markings are:
D15180x-xxxx
5A41x-x-yyyy
The descrambler uses the fact that the software_id is at a known location to filter out all the descrambled combinations that don't have software_id in the correct place.