knock sens
Moderators: JeffC, rdoherty, stieg, brentp
knock sens
I found something on the net when I was looking around :
This mapping program colors the bin red where there was knock, so
the tuner could see where it took place in his map.
That must be something to remember when inplenting in the software.
I have been thingking about changing between maps when knock appears,
We don't need to change the hole map only the aera nessecery,
now when I look at other programs they have a input for the amount of degrees
you want to pull back.
So when knock happens it gets pulled back the X deg.
I'm running the OPEL 20XE in my car and this engine has one knock sensor in the
center of the cast.
Is there anything I coul mesure or test for the intrest of the project?
I was thingking of building the the Knock circuit that I saw here somewhere and do
some testing.
Let me know what you need.
This mapping program colors the bin red where there was knock, so
the tuner could see where it took place in his map.
That must be something to remember when inplenting in the software.
I have been thingking about changing between maps when knock appears,
We don't need to change the hole map only the aera nessecery,
now when I look at other programs they have a input for the amount of degrees
you want to pull back.
So when knock happens it gets pulled back the X deg.
I'm running the OPEL 20XE in my car and this engine has one knock sensor in the
center of the cast.
Is there anything I coul mesure or test for the intrest of the project?
I was thingking of building the the Knock circuit that I saw here somewhere and do
some testing.
Let me know what you need.
Good idea.
A variation of this would be to log knock indicators (presence / intensity / Compensation Level / etc) along with the other datalogging information so it could be analyzed later.
For decorating the ignition map cells it could highlight them and then slowly fade them away when the knocking goes away.
Thanks,
A variation of this would be to log knock indicators (presence / intensity / Compensation Level / etc) along with the other datalogging information so it could be analyzed later.
For decorating the ignition map cells it could highlight them and then slowly fade them away when the knocking goes away.
Thanks,
Updating certain regions of the map is a worthy idea- however I think martin was suggesting that the whole map switch is a 'quick and dirty' approach that might be possible with today's firmware, providing the knock sensing device emitted a compatible output.
Now, the classic approach would be to automatically pull back timing as knock is detected. Not unlike an O2 sensor correction, it would only apply to certain regions of the map- for example, if you let off the throttle right after knocking was being experienced,a different region of the map would suddenly be in play and the knock 'compensation' value would be reset.
For this reason a 'shadow' ignition map that would hold the knock correction compenation values would be used so that when the engine goes back into that region it would see that compensation, again. Of course, the particular compensation values would decay as knock was not observed.
Just a few thoughts.
Now, the classic approach would be to automatically pull back timing as knock is detected. Not unlike an O2 sensor correction, it would only apply to certain regions of the map- for example, if you let off the throttle right after knocking was being experienced,a different region of the map would suddenly be in play and the knock 'compensation' value would be reset.
For this reason a 'shadow' ignition map that would hold the knock correction compenation values would be used so that when the engine goes back into that region it would see that compensation, again. Of course, the particular compensation values would decay as knock was not observed.
Just a few thoughts.
This kind of control could be done completely in software, no extra hardware would be needed, except for the knock sensing device, of course.
My description of the knock compenation technique was abbreviated, sorry- but very basically put, the idea is that you wouldn't need to pull timing everywhere across the map whenever knock occurs, just in the region where it happened.
My description of the knock compenation technique was abbreviated, sorry- but very basically put, the idea is that you wouldn't need to pull timing everywhere across the map whenever knock occurs, just in the region where it happened.
Yes, when you should be in the situation of letting the throtlle go when knock occurse it won't matter any more
in that section of the map.
When the bin lights op in red where is was knocking you can adjust the setting there to avoid dammage,
or do you thingk that whith the same amount of advance there is not always knock?
Because there wil be a difference between climbing and decending with the car at the same rev and tps
in that section of the map.
When the bin lights op in red where is was knocking you can adjust the setting there to avoid dammage,
or do you thingk that whith the same amount of advance there is not always knock?
Because there wil be a difference between climbing and decending with the car at the same rev and tps
Right, knocking under higher load is obviously more severe. So it would pull the timing back more aggressively.
So yes- multiple factors would affect knock. Not sure on the theory whether you would have knock or not at the same RPM / load location- if you were climbing a hill or not. Load is load on an engine- it would only affect *how long* you were staying at that particular region of the map.
So yes- multiple factors would affect knock. Not sure on the theory whether you would have knock or not at the same RPM / load location- if you were climbing a hill or not. Load is load on an engine- it would only affect *how long* you were staying at that particular region of the map.
I'm racing in hillclims so we are mostly throtlle wide open or closed.
So I was thingking of looking for the limit with knock sensing.
I would raise the advance in every bin with 5° and make a test run and see in the
datalog where knock occured.(marked red) These bins would be lowerd and the others raised again and so on...
I see that this is not only for race cars and that this doesn't mean that everybody is going to find the limit
But it would be benifitial for every engine not?
So I was thingking of looking for the limit with knock sensing.
I would raise the advance in every bin with 5° and make a test run and see in the
datalog where knock occured.(marked red) These bins would be lowerd and the others raised again and so on...
I see that this is not only for race cars and that this doesn't mean that everybody is going to find the limit
But it would be benifitial for every engine not?
-
- Posts: 68
- Joined: Mon Sep 13, 2004 8:45 am
- Location: The Chalfonts
- Contact:
I've just come across the TPIC8101 http://focus.ti.com/docs/prod/folders/p ... c8101.html which would sure make knock detection a lot easier. I don't think I'll get to try it out for a while though
-
- Posts: 68
- Joined: Mon Sep 13, 2004 8:45 am
- Location: The Chalfonts
- Contact:
hi brent, and others,
i have been reading about knock detection, and it seems clear enough that it is a complicated issue, and the hardware side of it is probably beyond the scope of mjlj. if nothing else, the problem is that what does, or does not, constitute undesirable knock is hard to define, and therefore difficult to accommodate in the mjlj.
that said, it is still an very important input into ignition control, so i was thinking that there might still be an implementation that is both useful and achievable? how about a software-only feature, which retards ignition by x degrees for y spark events, if a knock signal is present on the relevant mjlj input? x & y could be fixed, or maybe varied with the software. that way, the user could choose whatever hardware they liked to provide the signal, which i suppose would be 0v or 5v in the normal fashion. technically minded folk could build circuits using the thing oliver referred to; plainer ones, such as myself, could use the output from something such as sold here: http://www.viatrack.ca/ (i have just bought one of these - it is in the post). no doubt the device that vendor is selling DOES use the texas instruments chip anyway...
this approach introduces a knock response into mjlj in (what i presumptiously assume to be) a fairly easy software amendment, and leaves the difficult and inexact judgement about when there actually IS some knock, to the user.
regards
alexander.
i have been reading about knock detection, and it seems clear enough that it is a complicated issue, and the hardware side of it is probably beyond the scope of mjlj. if nothing else, the problem is that what does, or does not, constitute undesirable knock is hard to define, and therefore difficult to accommodate in the mjlj.
that said, it is still an very important input into ignition control, so i was thinking that there might still be an implementation that is both useful and achievable? how about a software-only feature, which retards ignition by x degrees for y spark events, if a knock signal is present on the relevant mjlj input? x & y could be fixed, or maybe varied with the software. that way, the user could choose whatever hardware they liked to provide the signal, which i suppose would be 0v or 5v in the normal fashion. technically minded folk could build circuits using the thing oliver referred to; plainer ones, such as myself, could use the output from something such as sold here: http://www.viatrack.ca/ (i have just bought one of these - it is in the post). no doubt the device that vendor is selling DOES use the texas instruments chip anyway...
this approach introduces a knock response into mjlj in (what i presumptiously assume to be) a fairly easy software amendment, and leaves the difficult and inexact judgement about when there actually IS some knock, to the user.
regards
alexander.