Knock control - load vs RPM table found
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.
Looking at previous info on DSM knock chip, that actually looked at every peak in the waveform, but it used analog components to do so. What I haven't done is look at the nature of the interrupt that calls the knock control routine. It may be that it isn't every spark but even more frequently than that. If so that would be puzzling how the ECU would keep up with a call to quite a long interrupt routine every time. I think I may attach a counter to the interrupt routine and then log it, see if it varies by RPM etc.
We could change the multipliers and adders to just get rid of knock sum on a known knock free engine. I was hoping that we could log the waveform a bit better though.
I just tried a high speed log of only knockfiltadc at idle and blipping the throttle. It is not changing incredibly fast, probably is every spark or in that order of magnitude.
I think things can be done with MUT logging, just by increasing the multiplier at those RPM where there are rises in knocksum due to (confirmed with detcans) false knock.
I think things can be done with MUT logging, just by increasing the multiplier at those RPM where there are rises in knocksum due to (confirmed with detcans) false knock.
I'm just trying to figure out the relationship of when you would want to change the multiplier and when you would want to change the adders. It seems that the adders are as a correction method when the amplifier is changing gain levels. What are your thoughts?
I was really hoping that small changes would do the trick. I don't want to vary drastically from stock to help quiet noisy motors. I think these large spikes are obvious signs of real knock. As such I think that riding the knock filtered real close with the knock base will provide maximum protection for when these pings cause a spike and set the knock sensor.
Do you think it could be, that the learning curve is such that the ecu tries to trim to this normal low amplitude background pulses? Then things go drastically wrong when a huge ping is encountered? This is exactly how I would want things to happen if I was designing a system.
Hopefully just a small change in the multiplier can raise the knock base so that noisy motors don't cause problems. However the large pings will still ruin the party, and maxim protection will still be achieved.
This looks to be very tunable.
I was really hoping that small changes would do the trick. I don't want to vary drastically from stock to help quiet noisy motors. I think these large spikes are obvious signs of real knock. As such I think that riding the knock filtered real close with the knock base will provide maximum protection for when these pings cause a spike and set the knock sensor.
Do you think it could be, that the learning curve is such that the ecu tries to trim to this normal low amplitude background pulses? Then things go drastically wrong when a huge ping is encountered? This is exactly how I would want things to happen if I was designing a system.
Hopefully just a small change in the multiplier can raise the knock base so that noisy motors don't cause problems. However the large pings will still ruin the party, and maxim protection will still be achieved.
This looks to be very tunable.
I think it will depend on the noise level of the engine, the adders can fine tune where the multiplier is kinda like "gain" as you said. If it's needing a big adjustment maybe start with the multiplier and then tune it in with the adders.
This is SO freaking awesome. I'm going to build some Det Cans this week and try to get rid of my maxed out knock counts at 3K low load.
This is SO freaking awesome. I'm going to build some Det Cans this week and try to get rid of my maxed out knock counts at 3K low load.
As many people with built motors seem to have problems around 3-3.5K in the RPM band, I believe it's related to the noise and harmonics associated with that specific RPM, load has little to do with it. For me I'm in break-mode and only see low-loads, but justboosted02 for example is hitting mid to high 200's in load and getting false knock so that doesn't work. Ideally you still want knock control in that RPM range, you just want to adjust the ECU's understanding of ambient noise throughout the RPM range. Which points back to redefining the shape of the Knockbase curve.
I think we can ignore the change in levels and I don't think it causes knock sums. It is just coincidence in one of the graphs I posted that it happened just before. The level change is just to have headroom to see big spikes and to help signal:noise ratio in a very volatile raw signal. It's switching is slick and comprehensively controlled by the ECU.
What surprised me is actually how "loose" the knockbase curve is compared to the filtered background levels, but when you see just part of the volatility in the knockfiltadc signal (and there is much more we can't see because of sample rates) you realise that a big knock would have to 2.5x knockbase which in turn is 2-3 times a heavily filtered knock sensor signal. So you might have to be more heavy handed than we think to get rid of false knock, but I would only use what is necessary to get several clean runs to keep the sensitivity.
It is likely that with real knock that goes undetected because of the knockbase being too high that it will soon escalate and be corrected. You've got the balance between false knock and not knocking too long. Some engine still may not be able to use knock control if the knock is quieter than the noise floor of the engine no matter what we do as the hardware simply couldn't handle it. However, we should be able to use knock control anywhere a standalone can do it, and have a much more sophisticated version than the simple AEM style setup.
I think increasing the multiplier by say 20% at a time is probably the way to go. Then you only have one table to adjust.
I would think of this as a knockbase predictor - ie the adaptive system is retrospective since it can only influence the knockbase upwards after the heavily filtered and slightly delayed (the digital filtering used adds a delay) noise level has increased. However, the right programming of the multiplier (and/or adder) by RPM will give a combination of adaptive and predictive. I would give an analogy with boost control in that it works well with a good wastegate duty table which has been built based on testing/experience of the system already. You could make a boost control system that just had a target and with clever PID it might be OK, but still able to be improved with the correct baseline readings. I think the knock control "knockbase" is really the same.
By the way, we can all log knockbase on MUT 6B, and knockfiltadc is on 6A. Both are in Evoscan recent versions. Bear in mind you won't see a fraction of the volatility of 6A though, just for interest to log it really.
What surprised me is actually how "loose" the knockbase curve is compared to the filtered background levels, but when you see just part of the volatility in the knockfiltadc signal (and there is much more we can't see because of sample rates) you realise that a big knock would have to 2.5x knockbase which in turn is 2-3 times a heavily filtered knock sensor signal. So you might have to be more heavy handed than we think to get rid of false knock, but I would only use what is necessary to get several clean runs to keep the sensitivity.
It is likely that with real knock that goes undetected because of the knockbase being too high that it will soon escalate and be corrected. You've got the balance between false knock and not knocking too long. Some engine still may not be able to use knock control if the knock is quieter than the noise floor of the engine no matter what we do as the hardware simply couldn't handle it. However, we should be able to use knock control anywhere a standalone can do it, and have a much more sophisticated version than the simple AEM style setup.
I think increasing the multiplier by say 20% at a time is probably the way to go. Then you only have one table to adjust.
I would think of this as a knockbase predictor - ie the adaptive system is retrospective since it can only influence the knockbase upwards after the heavily filtered and slightly delayed (the digital filtering used adds a delay) noise level has increased. However, the right programming of the multiplier (and/or adder) by RPM will give a combination of adaptive and predictive. I would give an analogy with boost control in that it works well with a good wastegate duty table which has been built based on testing/experience of the system already. You could make a boost control system that just had a target and with clever PID it might be OK, but still able to be improved with the correct baseline readings. I think the knock control "knockbase" is really the same.
By the way, we can all log knockbase on MUT 6B, and knockfiltadc is on 6A. Both are in Evoscan recent versions. Bear in mind you won't see a fraction of the volatility of 6A though, just for interest to log it really.
I think we have to get people playing with a combination of load threshold, multipliers and adders and see what works. Small knock problems will be easily sorted with one of these measures. The worst cars will need them all. At least we've got just four tables to focus on and understand how they work.
I'll have a look at Eric's ROM for the locations of these tables, mrfred also has details of my 88570008 tables. If these guys know what is going on, it will hopefully allow good support and discussion when the false knockers test further.
I'll have a look at Eric's ROM for the locations of these tables, mrfred also has details of my 88570008 tables. If these guys know what is going on, it will hopefully allow good support and discussion when the false knockers test further.
As many people with built motors seem to have problems around 3-3.5K in the RPM band, I believe it's related to the noise and harmonics associated with that specific RPM, load has little to do with it. For me I'm in break-mode and only see low-loads, but justboosted02 for example is hitting mid to high 200's in load and getting false knock so that doesn't work. Ideally you still want knock control in that RPM range, you just want to adjust the ECU's understanding of ambient noise throughout the RPM range. Which points back to redefining the shape of the Knockbase curve.
For MUT logging, evoscan seems to have better graphic resolution than LW2 and LW3 (for direct non-protocol logging though - different story). To get more LW MUT resolution you have to limit the # of channels.
96940011: No tables - that is why you couldn't find them Eric
Adders are two single values:
137c = 7 (triple gain)
1380 = 2 (single gain)
Multipliers are three values:
1DE4 = 20 [if bit 4 set, bit 0 clear in flag]
20B0 = 18 [if bit 4 set, bit 0 set in flag]
137A = 13 [if bit 4 clear, bit 0 don't care in flag
The choice of multiplier depends on bit 4 and bit 0 in flag FFFF8C42 as noted []
Not knowing this ROM I can only speculate about how the flags are set, but you might be tempted to think they are RPM related with 13 at low, 18 at mid and 20 at high as these number exactly match my IX. I suspect the Evo VII/VIII will be the same.
Adders are two single values:
137c = 7 (triple gain)
1380 = 2 (single gain)
Multipliers are three values:
1DE4 = 20 [if bit 4 set, bit 0 clear in flag]
20B0 = 18 [if bit 4 set, bit 0 set in flag]
137A = 13 [if bit 4 clear, bit 0 don't care in flag
The choice of multiplier depends on bit 4 and bit 0 in flag FFFF8C42 as noted []
Not knowing this ROM I can only speculate about how the flags are set, but you might be tempted to think they are RPM related with 13 at low, 18 at mid and 20 at high as these number exactly match my IX. I suspect the Evo VII/VIII will be the same.
Last edited by jcsbanks; Nov 26, 2008 at 02:53 PM.
Thinking more about the multiplier vs adder, I think I would go with the multiplier, if you look how it is stock the multiplier has far more effect in areas where you'll get false knock (between 1.6 and 2.5x) than the adder (+2 or +7).


