Knock windowing code discussion

Official FreeEMS vanilla firmware development, the heart and soul of the system!
Post Reply
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Knock windowing code discussion

Post by Fred »

I've just been chattering about knock with a few people off line and whilst thinking about windowing came up with a neat algorithm to do it cleanly.

Given the assumption that you are after knock and not pre-ignition which is a fair one IMO you can unmask an interrupt pin on each ignition event such that a signal can be received, and then if you get that interrupt, check you are within the prescribed window, and if you don't, it doesn't matter. in either case, you turn the interrupt off again until the next ignition event if you are hit. if you aren't hit it doesn't matter, if you are, you get at max one interrupt per spark which is acceptable and possible. in the case where you are inside the window, you set variables such that the next ignition calc pulls timing, and even remove some timing from the existing calcs such that if the calcs are a bit behind timing is pulled sooner.

These are just random thoughts that I just had this instant, so there could be flaws, point them out and discuss!

Admin.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
thebigmacd
LQFP112 - Up with the play
Posts: 205
Joined: Thu Apr 10, 2008 5:51 pm

Re: Knock windowing code discussion

Post by thebigmacd »

Unfortunately the best way to react to knock is proportionally depending on the severity. If you look at the way a lot of ECUs do it is they sample the output of a tuned filter with an ADC and pull timing based on the amplitude of the knock signal from 0-1V.

Why not just sample the knock amplitude during the final advance calculation before a given cylinder is to fire and modify the advance at that time?

Let's dub this one the "just in time" method.
Keith MacDonald
Control Engineering (Systems) Technologist
GartnerProspect
LQFP112 - Up with the play
Posts: 160
Joined: Tue Apr 08, 2008 9:14 pm

Re: Knock windowing code discussion

Post by GartnerProspect »

I'm not sure per-cycle windowing is necessary is it?

Just to clairify, you're trying to create higher accuracy by limiting the opportunity for knock interupting to a small frame of time in which knock is most likely to occur?

Now the numbers I've seen floating around hover around 20-30* around the ignition event. In the case of a v8 you're talking worst case, 1/3rd of the time spent in the knock window. That's not much of a window in my opinion and I'm not sure it really makes sense.

If you run multiple knock sensors, and were to individually window them based on their location then I suppose it would improve things more dramatically...

I think most importantly is to take the time to tune a knock detection system to the particular frequency that your engine produces upon knock. Of course the only way to do that is to let it knock... That's where all the R&D dollars that the OEMs have come in handy. But even if you force it to knock on light throttle, I don't know enough about it to know if the frequency is going to be the same as the knock under load.

And I like the idea of amplitude based correction too... but don't know enough about the implementation. Wouldn't you spend a lot of time polling the ADC waiting for knock to happen? I guess I'm not sure if the ADC runs in the background or what... I need to break myself of the PICAXE way of thought because an ADC poll stops all instruction processing until it's done IIRC. So you try not to do it too frequently if you can help it. IIRC, the 10bit ADC took about 10 times as long too...

But I'm here to learn!
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Knock windowing code discussion

Post by Fred »

thebigmacd wrote:Unfortunately the best way to react to knock is proportionally depending on the severity. If you look at the way a lot of ECUs do it is they sample the output of a tuned filter with an ADC and pull timing based on the amplitude of the knock signal from 0-1V.

Why not just sample the knock amplitude during the final advance calculation before a given cylinder is to fire and modify the advance at that time?

Let's dub this one the "just in time" method.
That entirely depends on how your outside world knock hardware works. If you get a pulse for a knock event from your box, then windowing like that is the way to go as it is not possible for knock to occur outside of that range (as opposed to not likely). If your knock box is outputting a continuous voltage that is representative of knock severity as you say, then "JIT" is a good/the only option. If it is going to work that way, code is already in place to do JIT (or as close to it as our hardware will allow) anyway.

If we are going to use pulses and interrupts, then my way looks pretty good as far as I can tell.

Additionally, knock, as important as it is, is NOT a key/core component of a basic good EFI/EMS system. This is definitely an add on for once the basics are working right. Once you say "this is an add on" then, how do you go about choosing which method to use in software? I HATE (with a vengence) the massive configuration that MS has. It should in my opinion be a case of : Do you want knock control? yes/no How many degrees per event/per Volt? X degrees How many degrees max? Y degrees How long before ramping back up the timing one degree? Z seconds. Mask knock signal for how long after last knock modification? W seconds. etc. Generic stuff that applies to all.

Which effectively means that we need to decide on the best method to do this.

The way I see it (from my boosted point of view) is that ALL knock is to be avoided. If you see any knock, you pull timing. If you see more, you pull more timing. When you see none, you leave it alone or raise it back up to the tune level.

Which brings us to the main point, this is not an oem EMS, its a DIY EMS which we are installing on our precious performance cars that we religiously fill with the best fuels and tune to perfection, knock control is a safety net in the first place which given consistent fuel and a good tune will not be seen.

When OEM systems do the "more timing till it knocks then back off some" routine, they are aiming for best economy etc on any fuel you are dumb enough to tip in. They limit boost to 10psi in most cases and intercool it well enough. The knock in these OEM systems is not severe and you can "get away with" doing the adv till knock then retard a little thing all the time. For someone with 30psi and much higher cylinder pressures, you CAN NOT afford to do this, you tune it RIGHT once and then if your logs show knock, you retune to avoid it.

So, the key thing then :

Interrupts, or ADC?

I'm against using up a precious ADC for this As it is an event based thing the way I see it. To me it makes sense to pull timing for knock ASAP regardless of how big it is. if you pull say 3 degrees and its not enough, the next time through will be significantly less anyway, and the next 3 degrees will definitely remove it.

One thing that concerns me is maybe zoning of the knock retard, but this is getting overly complex for something that is an extra and superfluous in the first place. By this I mean that you pull 3 degrees from full load timing, rather than 3 degrees everywhere. Chances are that you aren't knocking anywhere except full load.

Enough rambling, that ought to give you something to argue with :-)

Admin.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
GartnerProspect
LQFP112 - Up with the play
Posts: 160
Joined: Tue Apr 08, 2008 9:14 pm

Re: Knock windowing code discussion

Post by GartnerProspect »

Admin wrote:One thing that concerns me is maybe zoning of the knock retard, but this is getting overly complex for something that is an extra and superfluous in the first place. By this I mean that you pull 3 degrees from full load timing, rather than 3 degrees everywhere. Chances are that you aren't knocking anywhere except full load.
I like this. I like this a lot.

But what I like even more is the idea that we will have the nuts in hardware to make this happen. If you knock at Xrpm, Yload, Ztemp, Qwhatver, I want that zone to be cut back. And if it happens there a second time, I want it to cut back more and I want it to cut back permanently.

And then I want to KNOW about it too. So I want my CEL to flash annoyingly at me. And then I want the RTC to add a timestamp to it, flash it to involatile, and set a flag. Then I want to bluetooth the cell phone or laptop or in car PC and pull up the software, which checks the modification flag, notes it and lets me know it's set. Then I ask for a comparison of the original map and the modified map so that I can choose to make it a permanent part of the map or I can reset it to the original because I'm pretty sure it was caused by bad fuel or I'm feeling dangerous or I did something else to aleviate the problem somehow.

Speaking of rants, that's what I want.

How the knock system interfaces for me is much more trivial than what actually HAPPENS once it gets the knock signal.
thebigmacd
LQFP112 - Up with the play
Posts: 205
Joined: Thu Apr 10, 2008 5:51 pm

Re: Knock windowing code discussion

Post by thebigmacd »

GartnerProspect wrote:
Admin wrote:One thing that concerns me is maybe zoning of the knock retard, but this is getting overly complex for something that is an extra and superfluous in the first place. By this I mean that you pull 3 degrees from full load timing, rather than 3 degrees everywhere. Chances are that you aren't knocking anywhere except full load.
I like this. I like this a lot.

But what I like even more is the idea that we will have the nuts in hardware to make this happen. If you knock at Xrpm, Yload, Ztemp, Qwhatver, I want that zone to be cut back. And if it happens there a second time, I want it to cut back more and I want it to cut back permanently.

And then I want to KNOW about it too. So I want my CEL to flash annoyingly at me. And then I want the RTC to add a timestamp to it, flash it to involatile, and set a flag. Then I want to bluetooth the cell phone or laptop or in car PC and pull up the software, which checks the modification flag, notes it and lets me know it's set. Then I ask for a comparison of the original map and the modified map so that I can choose to make it a permanent part of the map or I can reset it to the original because I'm pretty sure it was caused by bad fuel or I'm feeling dangerous or I did something else to aleviate the problem somehow.

Speaking of rants, that's what I want.

How the knock system interfaces for me is much more trivial than what actually HAPPENS once it gets the knock signal.
That sounds fairly trivial to do. Whether traditional maps or "floating point" style maps are used we could still do the same thing: have a table of load vs rpm events and associated knock-induced retardation (sounds painful ;)). The modification table starts out all zeros and as knock events are logged it starts making the corresponding value in the map more and more negative. Simply add this offset to the base spark map and boom you have fully mapped knock retard.
Keith MacDonald
Control Engineering (Systems) Technologist
GartnerProspect
LQFP112 - Up with the play
Posts: 160
Joined: Tue Apr 08, 2008 9:14 pm

Re: Knock windowing code discussion

Post by GartnerProspect »

thebigmacd wrote: That sounds fairly trivial to do. Whether traditional maps or "floating point" style maps are used we could still do the same thing: have a table of load vs rpm events and associated knock-induced retardation (sounds painful ;)). The modification table starts out all zeros and as knock events are logged it starts making the corresponding value in the map more and more negative. Simply add this offset to the base spark map and boom you have fully mapped knock retard.
I think THAT happened to me just a couple weeks ago! :?

I don't know much about the guts behind it, so thanks for assuring me I'm not expecting magic from mayhem.

Admin has real good points about never wanting to encounter knock based on the TYPICAL demographic here, the all out performance enthusiast. Where I see probably the most excitement from an intuitive, highly powerful system is potential efficiency. While I love my high powered, super turbo charged, high displacement or high compression or some combination ragged edge engines, I personally find the persuit of 70 real world MPG to be far more interesting and challenging. Maybe I'm getting old? Or I've spent my whole life reading hot rod magazine. Helped bring to life a few wicked cool performance cars. 500hp doesn't excite me like it used to. And I guess I don't see myself trying to build a car to get there anymore because it's frankly not that hard to do anymore. Enough people have done it on all sorts of different platforms all I have to do write the check and I'd be running 10 second quarter miles all day long.

With the global state of things, and all the folks in the states crying over $3.50 a gallon, I foresee a grass roots effort at fuel efficiency that might come unexpected in the DIY ECU field.
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Knock windowing code discussion

Post by Fred »

GartnerProspect wrote:And then I want to KNOW about it too. So I want my CEL to flash annoyingly at me. And then I want the RTC to add a timestamp to it, flash it to involatile, and set a flag. Then I want to bluetooth the cell phone or laptop or in car PC and pull up the software, which checks the modification flag, notes it and lets me know it's set. Then I ask for a comparison of the original map and the modified map so that I can choose to make it a permanent part of the map or I can reset it to the original because I'm pretty sure it was caused by bad fuel or I'm feeling dangerous or I did something else to aleviate the problem somehow.
Then you have a lot of work ahead of you :-)
thebigmacd wrote:That sounds fairly trivial to do. Whether traditional maps or "floating point" style maps are used we could still do the same thing: have a table of load vs rpm events and associated knock-induced retardation (sounds painful ;)). The modification table starts out all zeros and as knock events are logged it starts making the corresponding value in the map more and more negative. Simply add this offset to the base spark map and boom you have fully mapped knock retard.
The trouble with this is memory. Maybe. We have a lot more, but not all of it is directly accessible. What that means to us, I'm not yet sure, but it could mean that we face memory limits on tables etc, and If I had to make a choice to remove a massive table, it would be this one.
GartnerProspect wrote:Maybe I'm getting old? 500hp doesn't excite me like it used to.
If that is really the case then you aren't driving them like you should! Or perhaps there are no roads near you worth thrashing around? Or something else. I don't wan 500hp to do 10s quarters to prove my weener is small, I want it to get a thrill ripping down some windy road scaring the crap out of my passengers and occasionally myself :-)
And I guess I don't see myself trying to build a car to get there anymore because it's frankly not that hard to do anymore. Enough people have done it on all sorts of different platforms all I have to do write the check and I'd be running 10 second quarter miles all day long.
Doing it without writing out the cheque is where the fun is :-) Hence this site. Did you look through my "other project" ? DIY to the core ;-)
With the global state of things, and all the folks in the states crying over $3.50 a gallon, I foresee a grass roots effort at fuel efficiency that might come unexpected in the DIY ECU field.
When I was younger and poorer, I had to face choices like "eat baked beans and drive fast" OR "eat proper food and walk or drive slow" : I ate beans! I use fuel like it's going out of fashion. Fuel economy mostly comes down to the driver. I tried to let a mate of mine with a prius let me try to make it do worse than 10l/100km, but he was afraid I would break it lol. I typically get 20l/100km he typically got 5l/100km, most people get 10l/100km driving sanely. I should mention that I got those fuel figures with 150hp and 1.3 tonnes. Now that I have nearly 3 times that, I think my fuel figures will be even worse :-) I did roughly 60l/100km from my first half a tank of boost LOL, I bet I can do much worse too! And yes, I would rather starve than not do it.

Are you really a car enthusiast? :-p Or is it just something you happen to have done? :-)

Back on topic :

If you want your fuel efficiency, you tune high in the spark table and let the knock algorithm take care of it, if you want safety, you tune correctly for safety and power and the knock thing is a safety net.

But, which type, ADC or ISR?

Give me your reasons!

Admin.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
Post Reply