![]() |
Transient Ignition Retard Tables from RomRaider
I know a lot of folks have been wondering just what was done for the 01C rom. It's not subtle!
Here are the transient ignition retard tables from ZA1JA00C and ZA1JA01C (USDM) factory ROMs as read by Ecuflash and RomRaider betas. This table contains the only difference between the roms (which share a nearly common definition) according to RR. Many thanks and mad respect to the RR and Ecuflash crew!! (I am merely a happy end user). Edit: updated definitions, but still alpha. Thanks Td-d!! http://i1143.photobucket.com/albums/...H/tables-2.jpg |
How does the timing on the newer rom differe in layman's terms?
Also, if Subaru/Toyota isn't willing to flash early adopters to the latest rom, can you just buy an ECU and have the latest rom included? |
Quote:
The newer tune pulls timing during hard redline shifts where the old tune doesn't. Cars tuned to the edge of knock can experience "shift knock" due to transients that the air/fuel/spark delivery system can't keep up with. The transient retard system provides a way to compensate this and keep the engine knock safe. It's a very good capability to have. That said, looking at these tables, I question the "hole" that remains between 3800 and 5600 rpm. As far as flashing a rom with a new table: no problemo, and this is what I would do if I had an 00C car (no ECU replacement necessary, it's simply software). As far as flashing a rom with a different definition, well, you go a little slower here. Some WRXs (for instance) go through a few different roms with different definitions on identical hardware, and in these cases I've flashed a different generation rom over another -- usually because I didn't have a complete definition of the rom that was on the car. Scared me to death the first time I did this, but no issue. As long as the ECU hardware or anything attached to it hasn't changed functionally, it can probably be done (check twice, flash once, and for heaven's sake get a better opinion on it than mine). I have no earthly idea why Toyobaru has any reluctance to flash 00C cars. This is dirt simple and fast to do with RR and ecuflash, it ought to be just as fast for a dealer. |
Yeah no kidding. Something isn't right there.
All I see is, aside from the lower left square. They subtracted 20 across the boards. |
I've just been looking at these same tables in tunerpro. 00C matches, 01C varies from the RR table (there are a bunch of 90 degree offsets).
Looks like there will be some revisions to the definitions. |
Quote:
|
Quote:
This helps prevent DI seal failure; the older tune is the cause we lost multiple STOCK engines. |
@Ralph Spoilsport
If this stuff interests you, then have a search for @mad_sb 's discussions on the topic. Tables have been previously shared and explained. |
Quote:
[...] Stuff deleted pending RR definition update |
I had the 00C calibration on my car from the factory, ran a 00C ecutek calibration from visconti, and most recently an 01C ecutek calibration from fa20club.... the tip in throttle stumble is only there on the 01C calibration for me, throttle response on the 00C calibrations was always far better at least for me
|
Just to update those who may not be following the RR thread closely:
Quote:
|
|
I've added Transient Ignition Retard ECT, RPM, Load, and TPS Threshhold tables - above (RPM and Load) or below (ECT, TPS) these threshholds, the retard table does not kick in.
|
Quote:
http://i1143.photobucket.com/albums/.../bad_table.jpg http://www.ft86club.com/forums/data:...AASUVORK5CYII= |
I can confirm that the scaling is incorrect on the OFT for A01C (offset at -30, should be -50). Need to direct Shiv to this thread.
|
I really don't understand why they won't flash 00C cars. I have an 00C car and I bought OpenFlash primarily so I could correct this issue.
|
Quote:
|
Quote:
Code:
ROM:000CECF8 Table_Transient_Ignition_Retard:.data.w 7 ; DATA XREF: sub_6F170+6Eohttps://dl.dropboxusercontent.com/u/...2020.56.40.png |
Quote:
The offset for shiv@vishnu 's 00C and 01C bins is the same, but so are the values in the table. |
Quote:
In 00c, the value of the first cell is 0x39. So to get the 'human readable' decimal version, convert 0x39 to decimal = 57, then multiply by the multiplier (0.3515625) which equals 20.0390625, and then add the offset (-30) which equals -9.9609375. Now, with A01c, you want the table to also pull 9.96* at that cell. So you put in 9.96, which using the incorrect scaling as per above would translate back into 0x39. Except, the way the ecu is reading it now, is 0x39*0.3515625*-50 - so actually, you have told the ecu to pull 29.96*. So yes - asking the ecu to pull 30* as opposed to 10* makes a big difference. |
Quote:
WHY THE CRAP WOULD THEY CHANGE THE CONVERSION in the later ECU? And is it really just for that table alone? |
Quote:
Quote:
|
Why wouldn't they change the definition? It's their prerogative, they don't own the 'community' anything.
As to why, though, who knows. Maybe something else hooks into it that required it. |
Quote:
Quote:
|
Quote:
|
Quote:
|
Bring this thread from the dead. Just an FYI, both Scion and Subaru have posted a TSB to update people to the ZA1JB01C calibration file. I just got mine updated. It feels like the initial throttle has a little "lag".
|
Quote:
|
Quote:
|
Quote:
|
I took a glance at the 'Transient Ignition Retard Engine Load Threshold' table in RomRaider today and noticed that it's currently set at 0.05 g/rev. This is both on a stock ZA1JA01D rom and OFT Stage 2 UEL. The description says transient ignition retard is disabled above this threshold. Wouldn't this effectively mean that transient ignition retard is disabled all the time? According to my logs, if the engine is running, it's pulling at least 0.1 g/rev. What am I missing here?
|
Should be disabled below - thanks for alerting me to the error in the description.
|
| All times are GMT -4. The time now is 03:21 PM. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2026, vBulletin Solutions Inc.
User Alert System provided by
Advanced User Tagging v3.3.0 (Lite) -
vBulletin Mods & Addons Copyright © 2026 DragonByte Technologies Ltd.