Knock sensor - Speeduino (2024)

ralfs.volis wrote:Hello, Im newbie here, just built my own Speeduino and it runs great so far.
I think knock sensor would be awesome option - tuning your engine and knowing if it`s gonna detonate/knock, Speeduino could retard the spark and that would eliminate knock. Just for safety. Keep it up with the good work, very appreciated.

Welcome!

Knock sensing is a big bag of worms. <- my opinion

If you are encountering knock, that is a problem, I agree. But that also suggests there is something wrong with the tune, too... like you have too much ignition advance tuned in, or not enough fuel. Could also be a result of an engine in need of repair.

How Speeduino would sense and adapt to engine knock is a whole other ball of wax, so to speak. So please provide your ideas about how to do that.

ralfs.volis wrote:Thanks, cx500tc!
Agreed.
I have friend of mine who roadtunes cars(MS equipped) with the headphones(connected to knock thru diy amp) and of course WB o2, and he have pretty great results(2.0 vw homebuilt turbo engine ~300whp, stock internals with cr-8.5:1 on a pump gas).
So basically knock sensor is a microphone. Hardwarely it would need amp to amplify signal going in to the arduino.
Softwarely - some kind of filter in software, where you can filter out normal running engine from when it detonates.
And if we could monitor the knock, we could run more aggressive tune, and like I said before, if it knocks - timing is retarded to not blow up the engine.

I think CX500t is getting more to the point on how to determine burst knock retard. Not all knock is created equal, so speeduino would need to be programmed to handle multiple cases. The amount of signal process that the arduino would need to do on the knock sensor signal would be greatly taxing on the processor. Ideally, with knock sensor signal processing you want the ecu to be able to determine light knock from hard knock (and rate everything in between), and how to respond to each. Then the ECU ideally should have knock learn factors, checking whether it is safe to add timing back into the mixture while the engine is not at a high load. If the ecu is not capable of this, then all it is doing is reacting momentarily to the knock, and will allow the engine to knock a few cycles before it retards the timing to protect itself. It will continue this cycle until inevitably you have a larger issue. Then a fuel quenching factor ideally would need to be added to help alleviate the "hard" knocks.

So long story short, not nearly as easy as just placing a knock sensor onto the engine (location is super critical for this btw) and being like, "yup thats knock."

Thanks, @klotzy_550

My comment stands: if you are getting knock, there is a problem with your tune... although we cannot rule out bad fuel.

Now, your solution suggests a filter algorithm running in Speeduino? I don't see that happening. That is just too much for this to do and not enough free resources on the 2560 to do that and control everything else.

An external module may be an option. There are several such things out there that could send a signal to the ECU that knock is occurring.

Then, though, we would have to decide how to handle such a signal.
Would the ECU fall back to a baseline advance angle, or just retard a bit? Would it add more fuel? Would it "learn" that response and integrate that back into the tuning or just free run all the time and compensate when knock is detected? Would it compensate, if 'learning', for each cylinder individually, or apply compensation in bulk, across all cylinders?

Fun, fun, fun.

klotzy_550 wrote:I think CX500t is getting more to the point on how to determine burst knock retard. Not all knock is created equal, so speeduino would need to be programmed to handle multiple cases. The amount of signal process that the arduino would need to do on the knock sensor signal would be greatly taxing on the processor. Ideally, with knock sensor signal processing you want the ecu to be able to determine light knock from hard knock (and rate everything in between), and how to respond to each. Then the ECU ideally should have knock learn factors, checking whether it is safe to add timing back into the mixture while the engine is not at a high load. If the ecu is not capable of this, then all it is doing is reacting momentarily to the knock, and will allow the engine to knock a few cycles before it retards the timing to protect itself. It will continue this cycle until inevitably you have a larger issue. Then a fuel quenching factor ideally would need to be added to help alleviate the "hard" knocks.

So long story short, not nearly as easy as just placing a knock sensor onto the engine (location is super critical for this btw) and being like, "yup thats knock."

Yeah, light knock, which may be desirable in some instances, versus hard knock / detonation.
There is a difference between ping under light load, and riding that edge helps with economy, generally speaking. Light knock occurring at part throttle is where the most ignition advance and most lean fuel mixture is possible, so best economy. Hard knock is the opposite, so to speak, where you want as much power as possible, so there is too much advance or not enough fuel and when you knock there, you will be blowing pistons up.

For what it is worth, Speeduino just recently gained the ability to do sequential fuel injection and such things.

Adding in filtering for knock sense is going to be a long way down the road.

cx500tc wrote:For what it is worth, Speeduino just recently gained the ability to do sequential fuel injection and such things.

Adding in filtering for knock sense is going to be a long way down the road.

Ok, mby something like this?

cx500tc wrote:

klotzy_550 wrote:I think CX500t is getting more to the point on how to determine burst knock retard. Not all knock is created equal, so speeduino would need to be programmed to handle multiple cases. The amount of signal process that the arduino would need to do on the knock sensor signal would be greatly taxing on the processor. Ideally, with knock sensor signal processing you want the ecu to be able to determine light knock from hard knock (and rate everything in between), and how to respond to each. Then the ECU ideally should have knock learn factors, checking whether it is safe to add timing back into the mixture while the engine is not at a high load. If the ecu is not capable of this, then all it is doing is reacting momentarily to the knock, and will allow the engine to knock a few cycles before it retards the timing to protect itself. It will continue this cycle until inevitably you have a larger issue. Then a fuel quenching factor ideally would need to be added to help alleviate the "hard" knocks.

So long story short, not nearly as easy as just placing a knock sensor onto the engine (location is super critical for this btw) and being like, "yup thats knock."

Yeah, light knock, which may be desirable in some instances, versus hard knock / detonation.
There is a difference between ping under light load, and riding that edge helps with economy, generally speaking. Light knock occurring at part throttle is where the most ignition advance and most lean fuel mixture is possible, so best economy. Hard knock is the opposite, so to speak, where you want as much power as possible, so there is too much advance or not enough fuel and when you knock there, you will be blowing pistons up.

Not so advanced - graph reading knock

if it senses soft - do nothing, if it senses mid - retard timing by 1 degree, if senses hard - retard by for ex 4 degrees and red alert goes off .
and mby in user defined steps and degrees per engine cycle
smthg like that.

So, my take on this is that knock is easy to do badly and surprisingly difficult to do well

It's not simply a matter of watching for a knock signal to go over a preset threshold, the signal itself varies in amplitude and frequency across the rev range and getting a definitive knock reading is a relatively complex bit of signal processing. I've seen other projects that claim to do knock detection but are really just watching for set thresholds etc, which will give you false positives. Have a look at this, which is a reading taken directly off a sensor:

Trying to separate the knock from other events (Such as the gear shift) is not necessarily simple.

My preference is to use an external knock module that can output a simple signal to indicate the presence and severity of knock. The GM one in particular looks like an option, but I haven't put a lot of research into it.