Knock control - load vs RPM table found
I too am very pleased with this effort. I have had a phantom knock issue for as long as I can remember. I have increased the load threshold from 70 to 90 in the 2000-3500 rpms area and it has eliminated what can only be described as stumble when the knock counts peaks at 35 and the ECU pulls tons of timing. I have noticed that I still get high knock counts at 100 so I will proceed with carefully increasing this threshold.
My only concern is that this basically eliminates the safety net in these low load areas. What timing would be considered excessive in these non-boost, closed loop fuel areas (I am fairly sure that my maps in these areas are still set to stock levels)?
My only concern is that this basically eliminates the safety net in these low load areas. What timing would be considered excessive in these non-boost, closed loop fuel areas (I am fairly sure that my maps in these areas are still set to stock levels)?
DC- I would just look at other members timing maps that are posted and compare them to yours. Just look at the mods listed and find a good average but on the lower side. There is a whole thread posted with other members timing maps. Sorry to take this thread off topic. This thread needs to stay focused on the knock mapping issue and disassembly for the others that are putting there effort into it.
Some datalogs/testing
Real world testing confirms the disassembly findings.
Here is one of a few forthcoming graphs.
As well as knock sum it shows:
Knockfiltadc - knock sensor voltage (which has two gain settings - it suddenly is divided by 3 mid pull - will explain more later)
Knockbase - usually about double the knockfiltadc (will explain more later).
If you log these with MUT (6A and 6B) it is far too slow and you miss all the peaks, complete waste of time.
Using DMA logging acceleration (which produces so much data in a short run that it nearly overwhelms Excel 2003's 65535 row limit!) we can see some of the peaks that trigger knock sums when they are sufficiently above knockbase. Even with much faster logging than MUT we are not logging every single ignition event - at 6000 RPM we have about a quarter of them, so on the graph some of the spikes don't cross the knockbase line, but with only a little faith you can see the spikiness that triggers the events.
The single knock sum of 7 was heard in the cabin - I thought it would be interesting to switch the boost controller from off to 26 PSI mid pull, it did produce transitional knock and the ECU picked it up and corrected it very quickly. I don't get this in normal driving.
The other knock sums of 1 or 2 are my usual sporadic knock sums on this tune, in some places you can see the crossing above the noise threshold that triggers them.
Here is one of a few forthcoming graphs.
As well as knock sum it shows:
Knockfiltadc - knock sensor voltage (which has two gain settings - it suddenly is divided by 3 mid pull - will explain more later)
Knockbase - usually about double the knockfiltadc (will explain more later).
If you log these with MUT (6A and 6B) it is far too slow and you miss all the peaks, complete waste of time.
Using DMA logging acceleration (which produces so much data in a short run that it nearly overwhelms Excel 2003's 65535 row limit!) we can see some of the peaks that trigger knock sums when they are sufficiently above knockbase. Even with much faster logging than MUT we are not logging every single ignition event - at 6000 RPM we have about a quarter of them, so on the graph some of the spikes don't cross the knockbase line, but with only a little faith you can see the spikiness that triggers the events.
The single knock sum of 7 was heard in the cabin - I thought it would be interesting to switch the boost controller from off to 26 PSI mid pull, it did produce transitional knock and the ECU picked it up and corrected it very quickly. I don't get this in normal driving.
The other knock sums of 1 or 2 are my usual sporadic knock sums on this tune, in some places you can see the crossing above the noise threshold that triggers them.
This one shows RPM on the x-axis, knock sum in blue, knockbase in yellow and knockfiltadc in magenta.
Again there is not a perfect correlation between knock sum increases and knockfiltadc crossing knockbase. This is again due to not sampling all the ignition events that have triggered knock sums. Sometimes a breach is not big enough to trigger knock sum either.
The main point of this graph is to show the sudden drop in knockbase and knockfiltadc in the middle of the full throttle pull from 3000 to 7000 RPM.
The gain is suddenly divided by 3. The SH2 CPU changes an output port that switches the gain on the knock amplifier in the ECU before it reaches the CPU. This switch is triggered by knockbase reaching about 140.
Again there is not a perfect correlation between knock sum increases and knockfiltadc crossing knockbase. This is again due to not sampling all the ignition events that have triggered knock sums. Sometimes a breach is not big enough to trigger knock sum either.
The main point of this graph is to show the sudden drop in knockbase and knockfiltadc in the middle of the full throttle pull from 3000 to 7000 RPM.
The gain is suddenly divided by 3. The SH2 CPU changes an output port that switches the gain on the knock amplifier in the ECU before it reaches the CPU. This switch is triggered by knockbase reaching about 140.
Eric, first graph was a variety of driving including idle, cruise, full boost, lots of different pulls. The graph in post #65 is of one pull through 3rd gear (a small part of the earlier graph.
OK, this final graph is a nightmare, but if you get it you understand knock control!
The nightmare graph that summarises all the important stuff and has the keys for calibrating the system. It is not easy to explain, but I will try and then you can ask questions! I will post the graph in this post and then write an explanation of it in the next one. It is the same pull through 3rd that I showed in the previous post, but with lots more information...
This is so awesome, it's not even funny. I think this work that John has just done, in my opinion, puts stand alones way behind the stock ECU now. I personally always thought the stock ECU was better anyway, but with this new control and understanding of knock by the stock ECU, I don't know why anyone would waste money on a standalone again.
Congrats and thanks to jcsbanks!
On a side note, John, I think it may be time to make the DMA patch for all of the ROMs now, so that we can log baselines noise levels more accurately. Since my ROM doesn't have any space anyway (96940011), and I can't find the three new tables, maybe I should start looking at 96530006.
Congrats and thanks to jcsbanks!
On a side note, John, I think it may be time to make the DMA patch for all of the ROMs now, so that we can log baselines noise levels more accurately. Since my ROM doesn't have any space anyway (96940011), and I can't find the three new tables, maybe I should start looking at 96530006.
Last edited by l2r99gst; Nov 26, 2008 at 09:33 AM.
So it is a full throttle pull from 3000 RPM to 7000 RPM approx (x-axis).
The very spiky trace in blue is the knock voltage if you like. I presume it will be bandpass filtered and rectified. Then a gated integrator of the knock sensor signal for each ignition event.
Yellow is a moving average of the knock voltage. Cyan is a moving average of that. This is then used to calculate knockbase which is in magenta.
The mult, add1 and add2 are looked up by RPM from the tables I posted earlier in this thread.
Knockbase=(mult*knockvar2/8) + Add1 or Add2
Add1 is used before the gain is reduced (at about knockbase 140 or about 4800 RPM on this particular trace), Add2 is used after the gain is reduced.
Testing this for example at 6000 RPM reading the numbers off the graph:
knockbase=(19*40/8)+7=102 which is about what knockbase actually is on the graph at about 6000 RPM.
The very spiky trace in blue is the knock voltage if you like. I presume it will be bandpass filtered and rectified. Then a gated integrator of the knock sensor signal for each ignition event.
Yellow is a moving average of the knock voltage. Cyan is a moving average of that. This is then used to calculate knockbase which is in magenta.
The mult, add1 and add2 are looked up by RPM from the tables I posted earlier in this thread.
Knockbase=(mult*knockvar2/8) + Add1 or Add2
Add1 is used before the gain is reduced (at about knockbase 140 or about 4800 RPM on this particular trace), Add2 is used after the gain is reduced.
Testing this for example at 6000 RPM reading the numbers off the graph:
knockbase=(19*40/8)+7=102 which is about what knockbase actually is on the graph at about 6000 RPM.
Once knockbase is calculated, the calculation of the increase in knocksum (if there is more than a small difference between knockfiladc and knockbase) is:
(x*(knockfiltadc-knockbase)/(knockbase*8))+1 clipped to 7, with the knocksum itself being clipped to 36. x has two values - 16 or 32 depending on whether you are below or above the load threshold table that started this thread off.
On some ECUs the increase in knocksum is clipped to 0 if you are below the load threshold, which effectively disables any increase in knocksum below that load. In others it appears unclipped, but will still be less than half as sensitive.
There are other fine details that are not terribly important.
(x*(knockfiltadc-knockbase)/(knockbase*8))+1 clipped to 7, with the knocksum itself being clipped to 36. x has two values - 16 or 32 depending on whether you are below or above the load threshold table that started this thread off.
On some ECUs the increase in knocksum is clipped to 0 if you are below the load threshold, which effectively disables any increase in knocksum below that load. In others it appears unclipped, but will still be less than half as sensitive.
There are other fine details that are not terribly important.
Last edited by jcsbanks; Nov 26, 2008 at 09:53 AM.
Edit: For example, just eyeballing the data from post #65, we would get something around (I know the spike may be higher due to not being able to log fast enough):
knock sum increase = 32*(150-138)/(138*8)+1 = 1.35
So, the knocksum is being increase by 1.35 counts. You graph seems to agree with this.
Last edited by l2r99gst; Nov 26, 2008 at 09:56 AM.
It is per ignition cycle. Agree on your eyeballing. There is a possible mistake in this knock sum calc because it would be very hard to actually get a knocksum increase of 7. I'll recheck and may have to edit post #70 further (the summary makes it look a lot simpler than this code nightmare really is, it scared me off for about 2 years, it is only today that I have tried to produce the equations). The idea of the increase in knocksum being related to the excess noise over base and multiplied up is correct though.
A routine that is very complex that does some arithmetic (bit of a nightmare subroutine that I made an assumption on!) needs to be put through the simulator to see how it converts the extra noise to knock sum. I'll do that now with some dummy data and post again, I will edit #70 when I have done so and post here.
The calc as originally posted is correct when you try lots of numbers through the simulator. Basically to get the maximum knock sum increase of 7 per ignition event you have to have knockfiltadc at 2.5 times knockbase. That is one heck of a whack (not surprising when you consider the jolt that a strong knock gives) and explains the need for the switchable gain. Of course they are cumulative, so you only need five knocks to reach 35 knock sum, or 6 to peg it at 36.
The way some engines false knock they must be having massive increases in noise. Hopefully the system won't saturate.
Perhaps I should find a way to log just RPM, load, knocksum, knockbase and knockfiltadc really quickly to confirm. Presently I'm held back on sample rate by each row of my DMA log being called by MUT. The shorter the row the more overheads that MUT needs. I suppose I could put RPM, load, knocksum and knockbase at the beginning of the row and then just log knockfiltadc 60 times in quick succession, I would hope to get every ignition event that way.
The way some engines false knock they must be having massive increases in noise. Hopefully the system won't saturate.
Perhaps I should find a way to log just RPM, load, knocksum, knockbase and knockfiltadc really quickly to confirm. Presently I'm held back on sample rate by each row of my DMA log being called by MUT. The shorter the row the more overheads that MUT needs. I suppose I could put RPM, load, knocksum and knockbase at the beginning of the row and then just log knockfiltadc 60 times in quick succession, I would hope to get every ignition event that way.
Last edited by jcsbanks; Nov 26, 2008 at 11:05 AM.
So it looks like to tune a noisy engine:
We will log a pull with no real detonation. Adjust the multiplier such that knock base is greater than knock filtered?
Does this sound correct or do you think ADD1 or ADD2 should be used? Seems to me that the background noise multiplier is the obvious choice. Also good job on the explanation, I understand it (I think) clearly, and I'm hard headed.
We will log a pull with no real detonation. Adjust the multiplier such that knock base is greater than knock filtered?
Does this sound correct or do you think ADD1 or ADD2 should be used? Seems to me that the background noise multiplier is the obvious choice. Also good job on the explanation, I understand it (I think) clearly, and I'm hard headed.


