mrfred

iTrader: (50)

I started working my way through the ignition retard limit code last week when I realized that the ignition timing parameters at MUT05 and MUT06 are not the actual values used by the ECU. In the first part of the ignition advance determination code, the code takes the ignition timing from the ignition timing advance tables and then applies all the environment related trims. I'll call this IgnLookup. This value gets rescaled to what I'll call IgnECUTemp

IgnECUTemp = 231 - 256/90*IgnLookup

After this occurs, the code then adds knocksum and some other value I'm still working to understand:

IgnECUTemp = 231 - 256/90*IgnLookup + KSUM + UNK

This is how KSUM affects timing. Then the code applies the ignition retard limit:

IgnECUTemp = constrained{231 - 256/90*IgnLookup + KSUM + UNK}

A few other calculations are performed that I'm working to understand, but ultimately, this Temp value gets written to another ignition timing variable:

IgnECU = IgnECUTemp

It appears that this IgnECU value is used to generate the actual ignition spark timing. It is also used to create the value that we have been logging for ages:

IgnMUT06 = 81 - (IgnECU - 42)*90/256 [This is the (x-20) scaling.]

IgnMUT05 = 61 - (IgnECU - 42)*90/256 [This is the (x) scaling.]

So, what's the big deal? I suspect that the Evo actually adjusts timing to fractions of a degree, but because MUT05 and MUT06 are always integer values, we never see it.

If anyone wants to try logging the IgnECU value, a MUT channel needs to be setup. I think most people are still using the x-20 scaling (MUT06), so the easiest thing to do is to overwrite MUT05:

Open up your MUT table in ECUFlash and write the following value to MUT05 according to your ROM:

8859 ROMs: 0x6DE3
9653 ROMs: 0x8C17
9417 ROMs: 0x8BEB

Save the ROM and flash it to your ECU.

Then create the following entry in your EvoScan Data.xml file:

<DataListItem DataLog="Y" Color="" Display="ECU Timing Advance" LogReference="ECUTimingAdv" RequestID="05" Eval="61 - (x - 42)*90/256" Unit="deg" MetricEval="" MetricUnit="" ResponseBytes="1" GaugeMin="-20" GaugeMax="50" ChartMin="-20" ChartMax="50" ScalingFactor="1" Notes="" Priority="1" Visible="False" />

FTY Motorsports

iTrader: (2)

so will this let us adjust timing to fractions of a degree like subarus?

mrfred

iTrader: (50)

Eventually, it may be possible, but it would take a decent size patch to do it.

acamus

Nice, now we finally have the formula for degree per knocksum

KSUM * 90 /256 = ignition retard

scheides

iTrader: (10)

Seems about right with what I've heard, 1/3 degree per knock sum, or 1 full degree per 3 counts.

l2r99gst

iTrader: (2)

Yep, I think I have posted that several times in the past. Nice to finally see it disassembled in the ECU. (Edit: Actually a quick search shows that John mentioned this as well when he was disassembling the knock/ignition routines).

mrfred, I could probably log that variable today on the way to the gym if you want some data. No reflashing necessary with LiveMap, so it makes it easy. But, just looking at the formula, the results are obviously going to be in fractions of a degree.


Eric

mrfred

iTrader: (50)

Because the base timing is all done with integer values, fractional amounts of timing will mostly likely only show up when there's knock, so if you could generate some knock while you're logging, that would be great.

donour

iTrader: (6)

I can see that, though a scaling factor in the lookup routine might get you 80% there, no? Most of the timing maps that I've seen only use about 20% of the 8bit space.

d

donour

iTrader: (6)

Really? I have to concede my ignorance here. What do the interpolation routines look like?

d

l2r99gst

iTrader: (2)

That's not a problem. I can generate knock pretty easily, I think.

But, what I was saying is that, based on your formula, that new eval is going to be in fractions of a degree, no matter what. It will be a multiple of 90/256, which always has some decimal value to it.

For example:

03whitegsr

iTrader: (8)

Very interesting, great work mrfred. It produces some pretty interesting results.

Here is a quick table of how the values in the main ignition table would equate to actual ignition advance, if you disregard any corrections, KSUM and the unknown variable. I also wasn't sure what the contraint was, so I did not try to include it at all.



Here is what happens if the ignition advance is held constant and the KSUM increases.


The table seems to be about 5 degrees low across the board. Maybe it's just coincidence, but does that unknwon table tend to add in 5 degrees under most situations? Actually, doesn't the ECU see the falling edge of the crank trigger 5 degrees early? Thus 0 in the table and the signal being 5 degree BDC would actually cause 5 degrees of retard?

mrfred

iTrader: (50)

All the timing tables are scaled 1:1 with actual degrees timing, and because the ECU only deals with integer values, the final result is an integer value even after interpolation between cells. This value is then converted into units closer to the ECU timing units (different only by an offset).

I see what you're saying. Because of the math, you'll see fractional degrees, but when you log, I suspect when there is no knock, you'll see 0, 1.05, 2.11, 3.16, etc. When knock occurs, you'll see values in between these.

JohnBradley

iTrader: (30)

I am not sure if it is in use in the test cars, but make sure to disable the EGR advance table (set to 0) to make sure you arent getting errant readings. For awhile I had suspected the Timing Alpha value to be the EGR advance since it was a value that had no other table that would match up. I have long since stopped logging it, but I have the data in the "what does your Evoscan xml look like thread".

I will look for the appropriate values if it will help.

03whitegsr

iTrader: (8)

Just throwing out a thought here, and I realize this is a little difficult as it would require probably rescaling a whole bunch of other tables and may cause issues with conditionals.

But essentially changing the code here:
IgnECUTemp = 231 - 256/90*IgnLookup

to

IgnECUTemp = 231 - 256/180*IgnLookup

Would essentially give 0.5 degree resolution without changing the knock sum effects?

JohnBradley

iTrader: (30)

https://www.evolutionm.net/forums/5485240-post9.html