HI Knock counts on Vt 304 engine running 11P

[festy]

how do i see if any knock has happend and how much? as the history table doesnt have an option for it in the drop down box
Can some one run me through how i can add it?

This is why it has changed, you cant log a histogram of delta knock counts to see where knock is happening. Still useful for looking at knock in a monitor view though.

I ran into this with 12P a while ago (http://pcmhacking.net/forums/viewtopic. ... =60#p31620), I could see the knock retard in the logs but not the knock counts, eg here (blue = knock counts, aqua = knock retard):

knock_counts.png (5.82 KiB) Viewed 5874 times

The knock (which was simulated in my test) was in short bursts, and the counter was being cleared before the next log message was being sent so I saw knock related retard, but no knock counts.
I ended up ignoring the counts trace and just watching the knock retard, that gives a good indication of when knock events happen.

[Yortt]

When 12p was first released it did not have the ability to log knock retard it only had knock counts. I cannot understand why you would want to log knock counts and not log knock retard.

Is there some benefit in logging counts that I am obviously not aware of, as festy's post clearly indicates there can be knock but no knock counts.

[VL400]

When 12p was first released it did not have the ability to log knock retard it only had knock counts. I cannot understand why you would want to log knock counts and not log knock retard.

Is there some benefit in logging counts that I am obviously not aware of, as festy's post clearly indicates there can be knock but no knock counts.

Other way around, knock counts were added in 12P. Knock retard was always included, and was in the original $12 bin. Knock counts were added so you could setup the ignore counts table.

There cannot be knock retard with no counts, the knock retard value is calculated from the counts. What can happen is the counts get missed when logging, the counts happen quickly but the knock retard is slow to decay which is why it may appear to have retard without counts. Lets say you are logging at 10Hz, or 100ms between logging frames. Knock counts are a delta count over a 12.5ms period, so with 100ms gaps between logging frames there are 8 delta count calculations which you missed 7 of. If only one of those 8 had some delta counts (which would then produce some knock retard), logging only around 1/8th of the calculations there is a pretty high chance of that one delta count calc being missed.

So in 11P v104 the change was made to show the actual knock counter, rather than a delta of this counter. The knock counter item is continually incremented by the number of knock counts. Trouble is its a different way of reading the logs (your looking at a flatline of counts being no knock, and a step/change being knock), and its not possible to have a histogram thats of any use. I changed this in later (unreleased) versions of 11P back to the normal type of logging view with knock count spikes, except its a new ALDL item that sums between logging frames. Once sent over ALDL it resets to 0 and starts counting again. So its a delta counts between logging frames rather than delta counts per 12.5ms. The PCM knock code remains unchanged though.

[sparx-1]

Thanks for the replys,
I have put a vr 4k knock sensor in now so it matches. now i understand why there is no knock history logging.

This is not my engine just curious how 11P does this.
lets just say any engine running 11P @ 2000rpm-90kPa 22 deg advance, detects knock counts and retards the timing buy 10 degrees to 12deg advance. as i understand It will try to add this back in slowly over time. Each time the load and rpm point is passed again, if it tries to do this and the knock counts come back it stops adding timing. lets say the value it stops on after several hrs driving is 15deg advance.
Can any one tell me if it will store that in its memory when i turn the key off and restart the engine or does it default back to the main spark advance value of 22 deg?

[VL400]

If you get keen would like to see the difference of a 100k and 4k sensor. The last time we tried this during beta testing there was no difference on a V6.

Knock control is purely reactive. So its detected knock and timing drops to say to 12deg like your example and is then returned over the next second or two The timing is pulled at a rate of the attack table and returned at the decay table value.

There is no timing being added as such, there is no learning of knock counts to then limit timing. What you command is what gets delivered (aside from the correction tables). It does not remember it knocked at that load point, so will pull timing again next time you pass through. There is no memory at all for knock control in these, there is no high and low octane table. So its important to get your timing setup and not tune by the sensor, its there really as a bad fuel detector.

[festy]

as i understand It will try to add this back in slowly over time. Each time the load and rpm point is passed again, if it tries to do this and the knock counts come back it stops adding timing.

If you look at the log pic I posted earlier at around the 8:12 mark, you can see the amount of timing being pulled is decreasing until 8:14 when there's another knock event detected so it jumps back up to the max knock retard.
Then it starts decreasing again but almost immediately jumps back up because of knock returning.
As VL400 said, it doesn't learn knock retard at all - it's purely reactionary. If it did learn, then it wouldn't handle swapping between high and low octane fuel too well.

[sparx-1]

Thanks for the explination. VL 400 I will see what i can do about loging the different sensors i have 100k sensor in the right side and 4k sensor in the left both are wired back to ecm just have to plug in the one i want to read.

[Yortt]

When 12p was first released it did not have the ability to log knock retard it only had knock counts. I cannot understand why you would want to log knock counts and not log knock retard.

Is there some benefit in logging counts that I am obviously not aware of, as festy's post clearly indicates there can be knock but no knock counts.

Other way around, knock counts were added in 12P. Knock retard was always included, and was in the original $12 bin. Knock counts were added so you could setup the ignore counts table.

There cannot be knock retard with no counts, the knock retard value is calculated from the counts. What can happen is the counts get missed when logging, the counts happen quickly but the knock retard is slow to decay which is why it may appear to have retard without counts. Lets say you are logging at 10Hz, or 100ms between logging frames. Knock counts are a delta count over a 12.5ms period, so with 100ms gaps between logging frames there are 8 delta count calculations which you missed 7 of. If only one of those 8 had some delta counts (which would then produce some knock retard), logging only around 1/8th of the calculations there is a pretty high chance of that one delta count calc being missed.

So in 11P v104 the change was made to show the actual knock counter, rather than a delta of this counter. The knock counter item is continually incremented by the number of knock counts. Trouble is its a different way of reading the logs (your looking at a flatline of counts being no knock, and a step/change being knock), and its not possible to have a histogram thats of any use. I changed this in later (unreleased) versions of 11P back to the normal type of logging view with knock count spikes, except its a new ALDL item that sums between logging frames. Once sent over ALDL it resets to 0 and starts counting again. So its a delta counts between logging frames rather than delta counts per 12.5ms. The PCM knock code remains unchanged though.

Other way around, knock counts were added in 12P. Knock retard was always included I remember specifically I could only log knock counts and not knock when I first used 12p. Does this mean it was part of the 12P but initially the tunerpro scanner could not register it?
the knock retard value is calculated from the counts So the counts are not the number of times it registers a knock event, it is measuring the level of knock?
I still do not understand why you would try to interpret knock counts for determining the knock level for tuning unwanted knock out, when the pcm calculates the degree/intensity of the knock which then reports the level in degrees retard which allows the tuner to make a decision on if and by how much to move timing

[VL400]

Maybe it was an ADX issue, I am just going back through the changelog and counts was an addition. The original hack I did for a $12 BLCF bin was logging knock retard, I have left all standard ALDL items in the message.

The counts are not indicating a single knock event occurred for a cyl, it indicates how long knock happens or how intense it was - how long the block rings for. How much timing gets pulled for a given knock count is determined by the attack table - ESC Attack rate(Deg/12.5Ms) vs RPM. This is why knowing the number of counts is useful, its not just a fixed amount of timing at all load points. Its configurable.

The knock counts are summed over a 12.5ms period. The counter is a 16.5Khz counter, so around 60.6us of knock activity per count. If you have knock for the full 12.5ms sample time, then 12.5ms/60.6us = a max of 206 knock counts for each 12.5ms period (the value you get with no knock filter installed). So with the attack table set to the default V8 0.88deg/12.5ms and you had only the one sample period maxed out at 206 counts 0.88deg would get pulled. If over a couple of samples there was say 467 counts, then 467*60.6us = 28.3ms, 0.88deg/12.5ms attack would have 1.99deg of timing pulled. Change the attack rate and for the same number of counts more or less timing can be pulled.

Knowing how many counts you get over a given period can help fine tune the timing that gets pulled at different RPMs (it also lets you have no knock retard at certain RPM ranges if harmonics start triggering the sensor). But at the end of the day its what ever you prefer to use, we just provide the tools. How you use them is you call.

[Yortt]

Maybe it was an ADX issue, I am just going back through the changelog and counts was an addition. The original hack I did for a $12 BLCF bin was logging knock retard, I have left all standard ALDL items in the message.

The counts are not indicating a single knock event occurred for a cyl, it indicates how long knock happens or how intense it was - how long the block rings for. How much timing gets pulled for a given knock count is determined by the attack table - ESC Attack rate(Deg/12.5Ms) vs RPM. This is why knowing the number of counts is useful, its not just a fixed amount of timing at all load points. Its configurable.

The knock counts are summed over a 12.5ms period. The counter is a 16.5Khz counter, so around 60.6us of knock activity per count. If you have knock for the full 12.5ms sample time, then 12.5ms/60.6us = a max of 206 knock counts for each 12.5ms period (the value you get with no knock filter installed). So with the attack table set to the default V8 0.88deg/12.5ms and you had only the one sample period maxed out at 206 counts 0.88deg would get pulled. If over a couple of samples there was say 467 counts, then 467*60.6us = 28.3ms, 0.88deg/12.5ms attack would have 1.99deg of timing pulled. Change the attack rate and for the same number of counts more or less timing can be pulled.


Knowing how many counts you get over a given period can help fine tune the timing that gets pulled at different RPMs (it also lets you have no knock retard at certain RPM ranges if harmonics start triggering the sensor). But at the end of the day its what ever you prefer to use, we just provide the tools. How you use them is you call.

VL400 thanks for your time to respond in the detail you have, I am starting to understand what knock counts are doing but still have difficulty in why you would use them to tune instead of knock retard information, maybe a real world log where knock counts yield additional information to knock retard.

Maybe it was an ADX issue, this from memory is correct as I was using message 6 ADX at that time

The knock counts are summed over a 12.5ms period. The counter is a 16.5Khz counter, so around 60.6us of knock activity per count. If you have knock for the full 12.5ms sample time, then 12.5ms/60.6us = a max of 206 knock counts for each 12.5ms period (the value you get with no knock filter installed). So with the attack table set to the default V8 0.88deg/12.5ms and you had only the one sample period maxed out at 206 counts 0.88deg would get pulled. If over a couple of samples there was say 467 counts, then 467*60.6us = 28.3ms, 0.88deg/12.5ms attack would have 1.99deg of timing pulled. Change the attack rate and for the same number of counts more or less timing can be pulled. Isn't this the same as removing 1.99deg of timing at the rpm and load point in the timing map as indicated by knock retard

it also lets you have no knock retard at certain RPM ranges if harmonics start triggering the sensor. Good to have this ability but the big question how to you determine harmonics are the cause of knock.

Please don't think I am trying to be argumentative here and you have probably covered it with your comment But at the end of the day its what ever you prefer to use, we just provide the tools. How you use them is you call if logging knock counts improve the ability to determine the optimum knock threshold I would like to understand how, strickly from a tuners point of view.