I'm finally finding some time to do a little more disassem. For no good reason, I decided to take a look at the timing subroutines to determine if it is possible to write a patch to allow timing maps with ~1/3 deg resolution. The factory timing table subroutines are written to allow only 1 degree timing increments in the timing tables.

After all the timing compensations from the timing tables are applied, the timing value computed from the tables gets sent over to another subroutine. In the 8859 ROM, this is sub_29754, and in this subroutine, the timing value is rescaled to units that represent ~1/3 deg timing increments, adjusted by knock sum, constrained to be greater than -10 deg, and then limits are set on how much the timing can be increased or decreased in one or two loops through the ROM code. The resulting value is then written to several RAM variables, but there is one in particular that appears to be the timing value that is eventually used to set the actual timing. In the 8859 ROM, its FFFF6DE2.

I've looked at where FFFF6DE2 is used in other locations in the ROM, but the code where its used is pretty complicated, calls lots of flags I've never studied, and makes use of DMA RAM. Wondering if anyone (acamus, tephra, Ceddy, etc.) is interested in looking at the code where its used. In particular, I'm interested in whether the ~1/3 deg resolution is preserved all the way up to the point where the ECU fires the plugs.

 

BTW, here's how to log timing in ~1/3 degree increments:

1) The RAM variable is not in the MUT table, so it has to be added. Open the MUT table and change MUT 9F from...
For 88590015 - change from 0x70CB to 0x6DE3
Will add values other ROMs as requested.

2) Save the ROM and upload it to your ECU.

3) Open the EvoScan "Data.xml" file, and in the "Mode 2" section, add the following entry:

<DataListItem DataLog="N" Color="" Display="Timing High Res" LogReference="TimingHiRes" RequestID="9F" Eval="75.8-x*90/256" Unit="deg" MetricEval="" MetricUnit="" ResponseBytes="1" GaugeMin="0" GaugeMax="255" ChartMin="0" ChartMax="255" ScalingFactor="1" Notes="" Priority="1" Visible="False" />

Save the "Data.xml" file. Relaunch EvoScan if it was open while you did the edit to the "Data.xml" file.

Its also possible to add the definition from within the EvoScan interface. Don't know the steps off the top of my head though.

 

The question is, can the ECU actually trigger the spark at sub degree intervals?

 

Knock sum affects timing in the ~1/3 degree increments, so it seems like its possible to control spark to sub-degree intervals, but I feel like its necessary to look deeper to know for sure.

 

I remember John Banks speculated that it might be possible to look at per cylinder knock, as the interrupts work to isolate each firing cycle IIRC. I guess it might be possible to adjust timing for each cylinder or firing cycle as well, do you guys thinks this is possible, or just way to much work for the result?

 

Yeah I remember that as well, Just the other day I was looking at the knock routines in conjunction with the cylinder firing order... But I ran out of time - I will get back to it later

 

Kinda off topic, but does anyone have an exact idea how much of the ECU code has been disassembled completely to date and how much of it do we understand percentage wise?

 

I've probably disassembled only about 1/4 of the code, maybe (probably) less. There's tons of stuff though that doesn't have anything to do with performance, e.g. the OBD routines.

 

So knocksum works in correlation with 1/3 degree increments? So does that mean each occurrence of knock lowers timing by 1/3 degree and that's why we only "see" a timing drop with 3 counts of knock usually?? I'd like to see someone log the 1/3 degree timing while 1-2 counts of knock occur and compare that timing to our regular timing values we log.

 

For 96530006 this is sub_26ACC and RAM FFFF8C16.

Just curious, but would tracking the misfire codes be the best way to figure out the individual cylinder index?

 

Yep, its ~1/3 deg (0.352 deg) timing subtracted per knocksum. That tidbit has been known for quite some time. Surprised that you didn't know it. I'd have already gotten a log comparing the 1 deg resolution variable to the 1/3 deg resolution variable, but I'm out of town until Thursday.

I thought that jcsbanks already figured out the cylinder index. Maybe he just found the RAM variable that stores it but hadn't found the correlation between index number and cylinder number?

 

I could be off, but I thought he hadn't figured out how it related to the actual cylinder number.

But the cylinder index doesn't matter with regards to getting 1/3* resolution, so sorry for taking a great idea slightly off topic.

 

I didn't even know we were aware of the 1/3 degree increments. It's been a busy year for me and my ecuflash forum browsing had to take a backseat. I'm finally getting back on track so hopefully I can keep up with the pace lol.

 

MrFred, I haven't followed things to the very end, but am pretty sure the 1/3 degrees is kept, but there are a few different scalings, 61 - x * 90 / 256, 81 - x * 90 / 256, etc.


I was thinking about this a while ago, and thought the easiest way to do it was placing a Timing Adder/Subtractor right before or after where the Timing Retard is done.

And have a different scaling for the main Ignition table, but with an additional calculation that splits out the regular timing and the adder/subtractor.

 

My thought for the 1/3 deg resolution tables was to simply apply the proper 1/3 deg scaling to the timing tables in ECUFlash, and then do away with the 1/3 deg conversion that is done with the final "table" timing value when it is brought into the subroutine where knock sum, etc, is added. Would be great if it were that simple to do, but we know that the timing table routine does lots of strange math, and I suspect I might have to NOP out some of the stuff in the timing table routine if it was getting in the way and could safely be removed. I need to go back and review that subroutine. Maybe we're talking about the same thing?