KLR Knock Yes/No Signal

[Tom]

Would I be right to assume the trigger signal occurs every 180 degrees, and that your 30 degree window represents the difference between 40ATDC for the target cylinder and 70BTDC for the next cylinder (aka 70ATDC for the target cylinder)?

I guess the window opens so late because it's listening for the 'ring' from knock that happens before the window opens?

If I have that right, then that would define the max duration of the pulse, but I'm struggling with the minimum. Does the code stop the window at any point before the next trigger? If not, it seem like the pulse on pin 15 could be infinitely short if the integrator hits the threshold immediately before the next trigger. If that is the case, then the minimum would be the few microseconds it takes for the circuit to drive the signal high?

[johnb]

Would I be right to assume the trigger signal occurs every 180 degrees, and that your 30 degree window represents the difference between 40ATDC for the target cylinder and 70BTDC for the next cylinder (aka 70ATDC for the target cylinder)?

I guess the window opens so late because it's listening for the 'ring' from knock that happens before the window opens?

If I have that right, then that would define the max duration of the pulse, but I'm struggling with the minimum. Does the code stop the window at any point before the next trigger? If not, it seem like the pulse on pin 15 could be infinitely short if the integrator hits the threshold immediately before the next trigger. If that is the case, then the minimum would be the few microseconds it takes for the circuit to drive the signal high?

Yes your first paragraph is exactly right.

I'm not sure if I follow what you mean by stop the window. The code turns on the integrator at a certain angle - I suppose we would call that opening the window. Then it reads the value from the integrator via the ADC at another angle. Then the knock routine will use the value read from the ADC to decide if there is knock or not. Then the trigger routine turns off/resets the integrator.

I think the best we can do is probably to identify the second angle (the one where the integrator value is read by the ADC). Figuring out exactly how long after that the knock detection happens would be really hard since it's a question of how many instructions run between the two events. IIRC these angles are somewhat rpm dependent. I'll dig a bit more when I get a chance.

If that's not accurate enough for what you need, then I would say the best way is to set up a test rig with signal generators and capture it on the scope. It's somewhat tedious but not very hard. You need one for the trigger, one for the ignition signal, and one to generate a 5.7Khz pulse at the right time to simulate knock.

I have done it but I can't remember the exact setup. I think you could leave the 5.7Khz signal running all the time rather than trying to time it exactly.

Actually as I type this I remember someone on pelicanparts did some bench testing on this: https://forums.pelicanparts.com/porsche ... t-2-a.html

That thread might already actually have the answers you need!

[Tom]

Would I be right to assume the trigger signal occurs every 180 degrees, and that your 30 degree window represents the difference between 40ATDC for the target cylinder and 70BTDC for the next cylinder (aka 70ATDC for the target cylinder)?

I guess the window opens so late because it's listening for the 'ring' from knock that happens before the window opens?

If I have that right, then that would define the max duration of the pulse, but I'm struggling with the minimum. Does the code stop the window at any point before the next trigger? If not, it seem like the pulse on pin 15 could be infinitely short if the integrator hits the threshold immediately before the next trigger. If that is the case, then the minimum would be the few microseconds it takes for the circuit to drive the signal high?

Yes your first paragraph is exactly right.

I'm not sure if I follow what you mean by stop the window. The code turns on the integrator at a certain angle - I suppose we would call that opening the window. Then it reads the value from the integrator via the ADC at another angle. Then the knock routine will use the value read from the ADC to decide if there is knock or not. Then the trigger routine turns off/resets the integrator.

I think the best we can do is probably to identify the second angle (the one where the integrator value is read by the ADC). Figuring out exactly how long after that the knock detection happens would be really hard since it's a question of how many instructions run between the two events. IIRC these angles are somewhat rpm dependent. I'll dig a bit more when I get a chance.

If that's not accurate enough for what you need, then I would say the best way is to set up a test rig with signal generators and capture it on the scope. It's somewhat tedious but not very hard. You need one for the trigger, one for the ignition signal, and one to generate a 5.7Khz pulse at the right time to simulate knock.

I have done it but I can't remember the exact setup. I think you could leave the 5.7Khz signal running all the time rather than trying to time it exactly.

Actually as I type this I remember someone on pelicanparts did some bench testing on this: https://forums.pelicanparts.com/porsche ... t-2-a.html

That thread might already actually have the answers you need!

My primary goal in asking was just to weed out noise on KLR 15 without ignoring legitimate knock, so calculating the exact minimum pulse is probably not needed if my theory/understanding below seems right to you.

I think just knowing the knock decision is made in code after sampling the integrator via the ADC answers my question for all practical purposes. I was thinking the integrator might directly latch the output in hardware the instant it crossed a threshold, which could (in theory) produce KLR15 pulse right before (e.g., 1us) the next trigger. But if the code enables the integrator, then samples it via an ADC at a scheduled angle, then runs code to evaluate thresholds, then flips Port 1 bit 6, it seems inevitable Bosch built in at least a few timer ticks worth of margin before the next trigger. Since the next trigger time can’t be predicted to microsecond precision (RPM changes, trigger/edge jitter, etc.), it seems virtually impossible Bosch would (or could) schedule the ADC check so late that bit 6 could be flipped only a few microseconds before the next trigger reset. If so, ignoring pulses shorter than ~174 µs (2 timer ticks) on my ATmega input should eliminate essentially all noise-based interrupts while still capturing every real event where bit 6 is flipped by the code. Does that sound right to you?

Getting more insight on the timing might still shed light on how accurate the typical Curtis Counter knock counter is, however. Those devices ignore some pulses under 500us, which may or may not be fast enough to capture all valid knock signals on KLR 15... ?


[And, as a total aside, from your github page and the internet, I finally have a sense for the frequency of knock on my 104mm bore 3 liter motor -- call it 5.5Mhz vs the 100mm bore's 5.7. Knowing that makes me wonder how easy/hard it would be to adjust the KLR code to center on 5.5Mhz rater than 5.7, but that's a topic for another day... ]

[johnb]

Would I be right to assume the trigger signal occurs every 180 degrees, and that your 30 degree window represents the difference between 40ATDC for the target cylinder and 70BTDC for the next cylinder (aka 70ATDC for the target cylinder)?

I guess the window opens so late because it's listening for the 'ring' from knock that happens before the window opens?

If I have that right, then that would define the max duration of the pulse, but I'm struggling with the minimum. Does the code stop the window at any point before the next trigger? If not, it seem like the pulse on pin 15 could be infinitely short if the integrator hits the threshold immediately before the next trigger. If that is the case, then the minimum would be the few microseconds it takes for the circuit to drive the signal high?

Yes your first paragraph is exactly right.

I'm not sure if I follow what you mean by stop the window. The code turns on the integrator at a certain angle - I suppose we would call that opening the window. Then it reads the value from the integrator via the ADC at another angle. Then the knock routine will use the value read from the ADC to decide if there is knock or not. Then the trigger routine turns off/resets the integrator.

I think the best we can do is probably to identify the second angle (the one where the integrator value is read by the ADC). Figuring out exactly how long after that the knock detection happens would be really hard since it's a question of how many instructions run between the two events. IIRC these angles are somewhat rpm dependent. I'll dig a bit more when I get a chance.

If that's not accurate enough for what you need, then I would say the best way is to set up a test rig with signal generators and capture it on the scope. It's somewhat tedious but not very hard. You need one for the trigger, one for the ignition signal, and one to generate a 5.7Khz pulse at the right time to simulate knock.

I have done it but I can't remember the exact setup. I think you could leave the 5.7Khz signal running all the time rather than trying to time it exactly.

Actually as I type this I remember someone on pelicanparts did some bench testing on this: https://forums.pelicanparts.com/porsche ... t-2-a.html

That thread might already actually have the answers you need!

My primary goal in asking was just to weed out noise on KLR 15 without ignoring legitimate knock, so calculating the exact minimum pulse is probably not needed if my theory/understanding below seems right to you.

I think just knowing the knock decision is made in code after sampling the integrator via the ADC answers my question for all practical purposes. I was thinking the integrator might directly latch the output in hardware the instant it crossed a threshold, which could (in theory) produce KLR15 pulse right before (e.g., 1us) the next trigger. But if the code enables the integrator, then samples it via an ADC at a scheduled angle, then runs code to evaluate thresholds, then flips Port 1 bit 6, it seems inevitable Bosch built in at least a few timer ticks worth of margin before the next trigger. Since the next trigger time can’t be predicted to microsecond precision (RPM changes, trigger/edge jitter, etc.), it seems virtually impossible Bosch would (or could) schedule the ADC check so late that bit 6 could be flipped only a few microseconds before the next trigger reset. If so, ignoring pulses shorter than ~174 µs (2 timer ticks) on my ATmega input should eliminate essentially all noise-based interrupts while still capturing every real event where bit 6 is flipped by the code. Does that sound right to you?

Getting more insight on the timing might still shed light on how accurate the typical Curtis Counter knock counter is, however. Those devices ignore some pulses under 500us, which may or may not be fast enough to capture all valid knock signals on KLR 15... ?


[And, as a total aside, from your github page and the internet, I finally have a sense for the frequency of knock on my 104mm bore 3 liter motor -- call it 5.5Mhz vs the 100mm bore's 5.7. Knowing that makes me wonder how easy/hard it would be to adjust the KLR code to center on 5.5Mhz rater than 5.7, but that's a topic for another day... ]

Yes your description of how it works is exactly right - that stuff is all done in the software. But whether 2 timer ticks is a good threshold to use, I'm not sure.

On your last paragraph - it's actually Khz not Mhz but in any case the code doesn't filter for that. It's the hardware that filters it and it might work just fine with 5.5Khz already. Take a look at the filter response in my LTSpice screenshot. From my testing, the filter hardware already has that 5.7Khz quite a long to the left of the peak response, and 5.5 is not that much further. An easy test would be to change the code for the self-test to generate a 5.5Khz signal - if it doesn't trigger a faulty KLR code, then it's definitely able to detect knock at that frequency.

I can only guess as to why they have the filter centered around 7Khz. My best guess is that they're expecting the knock frequency to go up with temperature and pressure, and since detecting knock under high temps/high pressure is even more critical, it made sense to make the system more sensitive in that range.

[Tom]

Yes your first paragraph is exactly right.

I'm not sure if I follow what you mean by stop the window. The code turns on the integrator at a certain angle - I suppose we would call that opening the window. Then it reads the value from the integrator via the ADC at another angle. Then the knock routine will use the value read from the ADC to decide if there is knock or not. Then the trigger routine turns off/resets the integrator.

I think the best we can do is probably to identify the second angle (the one where the integrator value is read by the ADC). Figuring out exactly how long after that the knock detection happens would be really hard since it's a question of how many instructions run between the two events. IIRC these angles are somewhat rpm dependent. I'll dig a bit more when I get a chance.

If that's not accurate enough for what you need, then I would say the best way is to set up a test rig with signal generators and capture it on the scope. It's somewhat tedious but not very hard. You need one for the trigger, one for the ignition signal, and one to generate a 5.7Khz pulse at the right time to simulate knock.

I have done it but I can't remember the exact setup. I think you could leave the 5.7Khz signal running all the time rather than trying to time it exactly.

Actually as I type this I remember someone on pelicanparts did some bench testing on this: https://forums.pelicanparts.com/porsche ... t-2-a.html

That thread might already actually have the answers you need!

My primary goal in asking was just to weed out noise on KLR 15 without ignoring legitimate knock, so calculating the exact minimum pulse is probably not needed if my theory/understanding below seems right to you.

I think just knowing the knock decision is made in code after sampling the integrator via the ADC answers my question for all practical purposes. I was thinking the integrator might directly latch the output in hardware the instant it crossed a threshold, which could (in theory) produce KLR15 pulse right before (e.g., 1us) the next trigger. But if the code enables the integrator, then samples it via an ADC at a scheduled angle, then runs code to evaluate thresholds, then flips Port 1 bit 6, it seems inevitable Bosch built in at least a few timer ticks worth of margin before the next trigger. Since the next trigger time can’t be predicted to microsecond precision (RPM changes, trigger/edge jitter, etc.), it seems virtually impossible Bosch would (or could) schedule the ADC check so late that bit 6 could be flipped only a few microseconds before the next trigger reset. If so, ignoring pulses shorter than ~174 µs (2 timer ticks) on my ATmega input should eliminate essentially all noise-based interrupts while still capturing every real event where bit 6 is flipped by the code. Does that sound right to you?

Getting more insight on the timing might still shed light on how accurate the typical Curtis Counter knock counter is, however. Those devices ignore some pulses under 500us, which may or may not be fast enough to capture all valid knock signals on KLR 15... ?


[And, as a total aside, from your github page and the internet, I finally have a sense for the frequency of knock on my 104mm bore 3 liter motor -- call it 5.5Mhz vs the 100mm bore's 5.7. Knowing that makes me wonder how easy/hard it would be to adjust the KLR code to center on 5.5Mhz rater than 5.7, but that's a topic for another day... ]

Yes your description of how it works is exactly right - that stuff is all done in the software. But whether 2 timer ticks is a good threshold to use, I'm not sure.

On your last paragraph - it's actually Khz not Mhz but in any case the code doesn't filter for that. It's the hardware that filters it and it might work just fine with 5.5Khz already. Take a look at the filter response in my LTSpice screenshot. From my testing, the filter hardware already has that 5.7Khz quite a long to the left of the peak response, and 5.5 is not that much further. An easy test would be to change the code for the self-test to generate a 5.5Khz signal - if it doesn't trigger a faulty KLR code, then it's definitely able to detect knock at that frequency.

I can only guess as to why they have the filter centered around 7Khz. My best guess is that they're expecting the knock frequency to go up with temperature and pressure, and since detecting knock under high temps/high pressure is even more critical, it made sense to make the system more sensitive in that range.

I was just thinking that 2 timer ticks is definitely longer than virtually all noise spikes -- so 174us is long enough for my purposes. Even 87us is probably long enough for 99.9% of spikes really. Given the software approach, do you think there's any realistic way a legitimate knock pulse could be less than that? That would mean Bosch was able to time its ADC check down to the last possible 87us timer tick in a very dynamic environment. They were darn good, but were they that good?

[johnb]

My primary goal in asking was just to weed out noise on KLR 15 without ignoring legitimate knock, so calculating the exact minimum pulse is probably not needed if my theory/understanding below seems right to you.

I think just knowing the knock decision is made in code after sampling the integrator via the ADC answers my question for all practical purposes. I was thinking the integrator might directly latch the output in hardware the instant it crossed a threshold, which could (in theory) produce KLR15 pulse right before (e.g., 1us) the next trigger. But if the code enables the integrator, then samples it via an ADC at a scheduled angle, then runs code to evaluate thresholds, then flips Port 1 bit 6, it seems inevitable Bosch built in at least a few timer ticks worth of margin before the next trigger. Since the next trigger time can’t be predicted to microsecond precision (RPM changes, trigger/edge jitter, etc.), it seems virtually impossible Bosch would (or could) schedule the ADC check so late that bit 6 could be flipped only a few microseconds before the next trigger reset. If so, ignoring pulses shorter than ~174 µs (2 timer ticks) on my ATmega input should eliminate essentially all noise-based interrupts while still capturing every real event where bit 6 is flipped by the code. Does that sound right to you?

Getting more insight on the timing might still shed light on how accurate the typical Curtis Counter knock counter is, however. Those devices ignore some pulses under 500us, which may or may not be fast enough to capture all valid knock signals on KLR 15... ?


[And, as a total aside, from your github page and the internet, I finally have a sense for the frequency of knock on my 104mm bore 3 liter motor -- call it 5.5Mhz vs the 100mm bore's 5.7. Knowing that makes me wonder how easy/hard it would be to adjust the KLR code to center on 5.5Mhz rater than 5.7, but that's a topic for another day... ]

Yes your description of how it works is exactly right - that stuff is all done in the software. But whether 2 timer ticks is a good threshold to use, I'm not sure.

On your last paragraph - it's actually Khz not Mhz but in any case the code doesn't filter for that. It's the hardware that filters it and it might work just fine with 5.5Khz already. Take a look at the filter response in my LTSpice screenshot. From my testing, the filter hardware already has that 5.7Khz quite a long to the left of the peak response, and 5.5 is not that much further. An easy test would be to change the code for the self-test to generate a 5.5Khz signal - if it doesn't trigger a faulty KLR code, then it's definitely able to detect knock at that frequency.

I can only guess as to why they have the filter centered around 7Khz. My best guess is that they're expecting the knock frequency to go up with temperature and pressure, and since detecting knock under high temps/high pressure is even more critical, it made sense to make the system more sensitive in that range.

I was just thinking that 2 timer ticks is definitely longer than virtually all noise spikes -- so 174us is long enough for my purposes. Even 87us is probably long enough for 99.9% of spikes really. Given the software approach, do you think there's any realistic way a legitimate knock pulse could be less than that? That would mean Bosch was able to time its ADC check down to the last possible 87us timer tick in a very dynamic environment. They were darn good, but were they that good?

It's a while since I looked at that code in any detail but from the 8048 manual, the instruction cycle for a 6Mhz clock speed is 2.5us. The KLR uses an 11Mhz crystal so that should be around ~1.4Mhz. So 87us is enough time to run over 60 instructions. That's not a lot, so you're probably right but I don't know for sure.