Knock presence handling code discussion

[SleepyKeys]

A prime example:

A local engine builder had a bunch of engines come back with blown head gaskets. It turns out(after fuel testing) about 1/2 the local fuel stations sell sub grade fuel. 87 was on average 84 and 91 was 88. And due to local corruption he was unable to do anything about it except tell customers where to buy fuel.

-sean

[AbeFM]

God, that's terrible.

Well, if it's being logged, I guess it's ok. Being sensitive to severity, and therefor being able to log it, might let you tune better or at least faster. And to a degree, being more sensitive means you can run closer to the edge.

Plus, it would be nice to be able to drive the day your 91 octane turns out to be 90.5, without pulling 24* of timing out. If it's bad-wrong, sure, let me know. But if it's in the noise, can't we all just get along? Like a "pull 1/2 degree until I press the fuel door button"

[SleepyKeys]

God, that's terrible.

Terrible indeed. Funny, there are a few gas stations named "Terrible Herbst Inc".

Just another reason I'm glad I don't live there anymore.

[AbeFM]

Heh, my father always was a terrible herbst fan. I know they sponsor a lot of off-road racing.

Do you know if they were the good stations or the bad?

[SleepyKeys]

This could be a long off-code topic.
http://www.diyefi.org/forum/viewtopic.php?f=15&t=236

Yes the Terrible's Truck is bad ass!!

[AbeFM]

Bring a topic back from the dead? Well, I just wanted to introduce someone here whom I met on another forum (not to be named) who'd got his own ucontroller based knock detection system he's working on. He wrote me:

Subject: Knock Detection with variable sensitivity over RPM

It would seem if you could monitor RPM via the trigger signals, you could do windowing pretty easily, a little circular buffer, and you'd only need one number to describe when you're masking events.

Can you explain this a bit more. have crank angle and cam angle as input to my monitor...

My Response:

Sure, let's say you want to window from 1 ms before the ignition event until 20 degrees after it. At 7200 rpm, it's 8.3 ms per revolution.

The 1 ms before is easy, but I'll get to the circular buffer, which is challenging. ("Fore_Window")

The 20 degrees after ignition is even easier. 20 / 360 = 0.055. roughly a part in 20.
(60 seconds / CURRENT_RPM) * 20 (window) / 360 (degrees per second) = reduces to = WINDOW_SIZE / RPM / 60 = time in seconds after ignition event ("Aft_Window")

Now, you watch for knock. The after part is easy:

If (Current_Time > (ign_timestamp + Aft_Window))
Knock_routine(Post_Ignition); //(Post Ignition Knock)
Else: Ignore Knock Event //Mask it out

The before part is a little more tricky, part of the virtual circular buffer:

On Knock_Signal: Knock_TimeStamp = Current_Time;


On Ignition Event: If (Knock_TimeStamp + Fore_Window > Current_Time)
Knock_routine(Pre_ignition); // Log Preignition Event;


Does that make any sense? You could totally clean it up. The idea is that if you're knocking withing X (setable?) degrees/ms before or Y degrees after the ignition event, you report it as knock and act appropriately.

Knock from preignition means you're WAY hot and need to pull a lot of spark. Knock right around when you fire the sparkplug means you're firing too early, and need to pull a little spark. At least I think.

Feel free to email me (please copy this) at AbeFM@mad.scientist.com. There's a good place we could talk about this at length and get some good input!

The Reply

Very clever. You are referencing time_stamp , is this simply the ticks from a counter or a utilty in the c language that provides the time?

I see the benefit is pre-ignition or detonation detection as well as the ability to change the window.

I have cam angle and crank angle inputs to my device. For toyota the cam signal is 10btdc,20atdc,50atdc,80atdc,110atdc.

Why can't I use the cam pulses to listen between 10btdc and 110atdc without having to use calculations?

Is it that your technique makes it independent of vehicle? All that is required is rpm and ignition.

[AbeFM]

Heh, well, that was the worst sort of psuedo code - and I don't know if there IS a time_stamp, but... I figured you could alway find a clock or some such thing to get the system time, even if it's in milliseconds you'll be ok.

You could have a running degree clock, but I'm still confused as to the utility of this - it seems like... anyway, it doesn't matter, off topic.

You could probably use your teeth, but then you're not being very selective - Your windows will be quite large. Additionally, you can't have your windows follow the advance of the motor! 10btdc/20atcd might be ideal when you're firing at TDC, but if you have 13 degrees of advance, then it would be useless. And switching to 110/10 would be way too large a window, etc.

My own suggestion would be to use the angle method, which will make it more flexible (for engines of other makes, or even different cylinder counts), as well as allowing dynamic windowing with RPM (perhaps at high speed/boost you might "listen harder" for knock). Yes, it would mean all you need to know is RPM and ignition events, which you could get as low-level logic from the computer instead of using optical couplers.

Where to pick the limits of your windows is another discussion, and when it comes to software implimentation, the folks here know a lot more than do I!!
-Abe.