rusefi.com

Well, I mean I agree with you overall, but, knock detection is basically universal with most manufacturers... Retard the timing, dump a bit of fuel, and set a DTC if long/savage enough.

Is the idea to determine the gain needed on a per-engine basis, and bake that into the board? Or any thoughts on adding programmable gain to the circuit?

If you use a DAC instead of VREF2 (5v/2), then put a PGA like PGA112 or MCP6S91 at the end (maybe instead of U471?). Or if you want more choices in gain, you can use another DAC in concert with an op-amp.

I've read that knock sensor sensitivity can vary substantially depending on whether you're using a wideband or narrowband sensor, though I have little experience with this.

We just don't need the dynamic range. It has well over 40db of usable dynamic range as-is. Since we're direct sampling (then calculating as 32b float...), we don't need the kind of gain control that things like the HIP9011 have.

To be clear, I'm not suggesting dynamic range while the engine is running, but instead dynamic range to handle differences from one engine/knock sensor to another. The 32-bit float isn't buying you anything if you max out (or can't even get a signal) from the ADC.

Or is the answer "you have to buy this knock sensor for it to work, or maybe change some resistors?" How many different engines/sensors has this been tested on? I'm guessing not many given some of the comments in this thread (datalog in August, code commit in October).

Another circuit question... any reason the first op-amp doesn't include any low pass filtering? If C474 were moved in parallel with R470 (and the value changed appropriately), then R472 could be removed. Not that it's a huge deal. Or get a relatively cheap 4th order filter and reduce the sampling rate required on the ADC.

Or are you relying on parasitic capacitance of the pins to provide mild filtering given the large resistances in use? (I have no idea how to model that...)

What schematic do those references match? Can you add a snip of it here?

https://github.com/andreika-git/hellen-one/blob/master/modules/knock/0.1/knock-schematic.pdf

I assume that's the latest version? It is already remarkably compact on a PCB.

So far I do not fully understand your knock detection algorithm yet.
- How is knock discriminated from noise level after filtering and windowing?
- What is done, after knock occurrence has been detected?
- How is your knock-control strategy and algorithm?

kr, sepp2gl

A quick note on how we have been taking baselines in the current software.

Use something like this calculator to quickly find the frequency of expected knock at your bore size:
https://phormula.com/knock-frequency-calculator/

We have been testing at both the first harmonic and second to see which is giving a cleaner result, to try the second harmonic obviously just double the frequency result from the calculator.

Currently in the software the only settings that matter are the "knock filter frequency" the "Knock detection window start angle" the "knock sampling duration" and the channel assignment.
"knock filter frequency" - Obviously this is the frequency that the ECU will use to provide the sound level output, you must reset the ecu before a change here takes effect.

"Knock detection window start angle" - Leave this at zero, it is an adder to move the window out of phase purely for some diagnostic and testing work.

"knock sampling duration" - This is how many degrees after the spark is fired we will listen for, when set to 60 for example and sparking at 20BTDC we will listen for knock until 40ATDC. Anything between 45 and 60 is reasonable for this window length.

If you have more than one sensor then pick the channel closest to each cylinder, this will only really work properly in sequential setups with a cam sensor to tell the ECU which cylinder it needs to listen to at a given part of the cycle.
If you have a single sensor then set them all to Channel 1.

To take a base line there seems to be a couple of ways we can do this, raising the driven wheels off the floor and spinning them in gear through the engine RPM - This is dangerous and I am not going to tell anyone how to do this here or even recommend anyone tries. If you know what your doing you will know what I mean anyway.

The better option is to have the car on a dyno and run it under light load (say 50kpa inlet manifold max) up through the rpm range while logging. It can help to retard ignition a bit while you do this to be totally sure that there is no knock happening but if there is actual combustion knock happening at such light load then there is something much more wrong with your setup.

If possible when running baselines have your fueling somewhat correct, try to let the engine coast down as you would on the road with DCFO on so we can get some idea of the noise levels on the way up and down do check if we get a good base line.

@simon:
what makes you think, that there is ONE baseline?
The noise-level, depends on a variety of parameters (e.g. engine speed&load, cylinder-no., sensor placement, engine aging, valve timing and valve lash, etc.).
Measuring a baseline during deceleration does not make any sense, as there will never be any knock under such circumstances.
Measuring a baseline during high acceleration does not make any sense either, as engine operating point is changing from combustion to combustion.
So knock detection is effective for steady-state operation or slight transient engine operation.
In addition knock control is not meant to completely avoid knock but to keep knocking events under a certain intensity and a certain knocking rate.
So If you only look for the occurrence of "knock frequency" within a certain angular window, you might fail.
Knock is a kind of auto-ignition phenomenon, that might occur statistically, when compression pressure & temperature in the combustion chamber (sometimes supported by "hot-spots") exceeds an auto-ignition threshold.
Consequently a "baseline" needs to be monitored permanently in the "active knock" engine operation to be compared with the latest noise-sample, to decide, if it was a knocking combustion or not.
This can be best done on an engine dyno, but also vehicle testing on the road can be successful after some time.
Another challenge: how to decide, if a "detected knock event" really was a real knock event?
On a dyno OEMs use in-cylinder pressure sensors a reference. In a car even a microphone in the engine compartment can help.

more to come...
t2us, sepp2gl

Your reading far too much into a post simply to help someone gather some data for us to look at establishing back ground noise level baselines.
Just the mechanical noise and standard combustion echo in the block.

Right now nothing works beyond the recording of the sound level at the selected frequency.

@Simon:
you may be right; I know quite a bit about knock-detection and control, but so far I haven't found the information about
the rusEFI knock-detection concept documented anywhere in this forum.
So I may have misinterpreted the expression "baseline".

Nevertheless: where can I find my below questions answered, so that I can help?

sepp2gl wrote: ↑

Mon Jan 03, 2022 9:31 am

- How is knock discriminated from noise level after filtering and windowing?
- What is done, after knock occurrence has been detected?
- How is your knock-control strategy and algorithm?

Right now there is not a lot to say. Which would be why you cannot find a lot.

We take the signal from the sensor and pass it through and FFT to determine the noise at the chosen frequency, we spit that out as a raw noise level value.

We have the ability programmed in to select a sensor based on the part of the engine 720 cycle, so we can pick the sensor closest to the cylinder, doing so does require a cam sensor.

That is about it, Matt or the firmware can probably offer more info on the exact details of that FFT than I can.

Thanks for clarification.
Looks like you (the "resEFI knock-team") are still at the very beginning of knock-detection,
and you want to find your own way.
Anyway: if you need advice for a proven solution, contact me...

Yeah, there really isn't much to say at the moment, we are mostly just gathering what data we can to understand the nuances of the hardware.
We are just lucky we have some capable people on hand to assist with things.

In case there was doubt about whether the relatively naïve implementation works, here's some data from a race:
Can you spot the knock?

Simon@FutureProof wrote: ↑

Sun Mar 27, 2022 8:05 pm

We take the signal from the sensor and pass it through and FFT to determine the noise at the chosen frequency

Haha, it's not even an FFT. It's a bandpass filter (adjustable Q, F_c), then something approximating an envelope detector or integrator. We just measure the total amount of power that makes it through the bandpass filter inside the window. So not only do we only listen at the correct time for knock to be audible (ie, near and just after TDC), we only listen to the right frequency band where we expect knock to occur. The signal to noise ends up being pretty good, as you can see from the several dB louder knock events in that scatter plot.

To follow up a little on this, we are certainly getting VERY solid data out of the knock sensors, retarded timing and low loads on the dyno are able to set a base line for that specific engine with enough quality we should be able to determine knock from normal background noise.

A brief plan for the knock response has been created and can be viewed attached to this post or here:
https://tinyurl.com/2d7cfkmn

What is the relation between the document above and https://github.com/rusefi/rusefi/wiki/Vault_Smart_ECU#knock-intervention content?

Matt has made some progress back in November https://github.com/rusefi/rusefi/pull/3396 - three new configuration parameters and some logic between those were added, just not exposed to UI yet. I've just exposed those three to UI.

That code from November even has some test coverage. I wonder what if anything remains for a first real vehicle test with some first real value on "Knock Retard" gauge?!

@Simon:
please find some comments in the attached modified presentation.
There are mainly three things, that I disagree with:
1. Transient knock can be very strong and thus need to be avoided.
Transient knock cannot be handled by sensor-based knock detection, because it simply is too slow, as the retard comes 2 revs of the crankshaft later, when the engine load-condition will be completely different.
Additionally knock will reoccur with same strength with next acceleration again.
Better have a feed-forward spark-retard, that is dependent from the speed/load-transient but independent from the knock-sensor.

2. I made some experience with knock-retard depending on the "strength" of the knock-event. It simply didn't pay-off.
The intensity of a knock-event is highly stochastic. If not controlled by spark-retard, it will definitely increase as the combustion temperature increase simultaneously. Once a spark-retard has been applied (TME 6 deg/knock is a good estimate) the next combustion is either knock-free or the knock-intensity ahould be greatly reduced. If you retard much more you will suffer from power-loss. It is better to have a slow re-advance-rate to allow the combustion temperature to get down again. As the combustion-temperature has slow dynamics, so should be the re-advancement.

3. It doesn't make sense to do knock-control at low loads, as there is simply no knock at low loads under steady-state conditions.
If you detected knock at low loads, the detection was false.
Exception: transients from load-load to high-load (see my comment above)

so, do I get it right that the hip9011 solution has now become officially obsolete in rusefi?
in this thread there are two almost similar schemes - with mcp6004 and with two LMV321IDBVR - which one is better?
where do I get the Vmid (VREF2) signal and what to which pin of stm32f407 should i connect the out_knock? Should the opamp be powered from 3.3V or 5V? Do I need a voltage divider there?

and yet another question regarding the wiring: the knock sensor probably has two wires + a shield. can I just use an analog earth for any one of the wires? what about the shield (if it exists)?

puff wrote: ↑

Sun May 01, 2022 6:25 am

so, do I get it right that the hip9011 solution has now become officially obsolete in rusefi?

In theory still works, but I can't recommend it after the success we've had without it.

puff wrote: ↑

Sun May 01, 2022 6:25 am

in this thread there are two almost similar schemes - with mcp6004 and with two LMV321IDBVR - which one is better?
where do I get the Vmid (VREF2) signal and what to which pin of stm32f407 should i connect the out_knock? Should the opamp be powered from 3.3V or 5V? Do I need a voltage divider there?

For the purposes of knock detection, the MCP600x and LVD32x behave the same. They're different, but not really in ways that matter here. If you're intending to breadboard a solution for use with Frankenso or some other board, I'd start by copying the circuit found on Proteus, see page 17 here: https://github.com/mck1117/proteus/blob/master/export/v0.7/proteus_0_7_schematic.pdf You should be able to use pretty much any general purpose opamp in place of those MCP6004, but we've only actually validated with the MCP600x and LMV32x. Those resistor/cap values seem crazy, but the values do matter, so try to match as close as you can get.

puff wrote: ↑

Sun May 01, 2022 6:25 am

and yet another question regarding the wiring: the knock sensor probably has two wires + a shield. can I just use an analog earth for any one of the wires? what about the shield (if it exists)?

Ground both the shield and one of the signal wires to analog ground at the ECU. AFAIK the wires on the sensor are the same - since it's an AC device (and the input is AC coupled at the ECU), the polarity doesn't matter.

Thanks a lot! The only question is there are no PF4/PF5 pins in stm32f407vgt6 - there is no PF port at all. Is software knock processing at all supported in 407 chip?

puff wrote: ↑

Sun May 01, 2022 8:18 am

Thanks a lot! The only question is there are no PF4/PF5 pins in stm32f407vgt6 - there is no PF port at all. Is software knock processing at all supported in 407 chip?

any adc3 pin would do

AndreyB wrote: ↑

Fri Apr 29, 2022 2:51 pm

What is the relation between the document above and https://github.com/rusefi/rusefi/wiki/Vault_Smart_ECU#knock-intervention content?

Matt has made some progress back in November https://github.com/rusefi/rusefi/pull/3396 - three new configuration parameters and some logic between those were added, just not exposed to UI yet. I've just exposed those three to UI.

That code from November even has some test coverage. I wonder what if anything remains for a first real vehicle test with some first real value on "Knock Retard" gauge?!

Relationship - Should probably override the vault info, Vault info is older and more a set of initial thoughts and ideas on the subject. PDF is more of an actual plan.

If I can get up to date on what is coded and testable then we can do some ASAP on the drift car.
We have a very good baseline for it, knock sensors and 2 years worth of data to work from.

Hi friends I need help whith Knock in proteus
https://rusefi.com/online/view.php?log=1214
https://rusefi.com/online/view.php?log=1213
https://rusefi.com/online/view.php?msq=1446

maybe threshold need positive?
In log i see "knock degrees retarded" but in "Timing" not see
And I not see any changes on 2-4-6 cilinder

Hmelik wrote: ↑

Sun Apr 09, 2023 5:33 pm

not see any changes on 2-4-6 cilinder

AndreyB wrote: ↑

Tue Apr 11, 2023 2:15 pm

Hmelik wrote: ↑

Sun Apr 09, 2023 5:33 pm

not see any changes on 2-4-6 cilinder

image.png

Weird. So log makes it look like we have channel 1 cylinder 1 and 3 and channel 2 cylinder 5 working but crazy steady numbers of cylinders 2,4,6?

Please flip Proteus wires and grab a new log?

AndreyB wrote: ↑

Tue Apr 11, 2023 2:24 pm

Weird. So log makes it look like we have channel 1 cylinder 1 and 3 and channel 2 cylinder 5 working but crazy steady numbers of cylinders 2,4,6?

wasted spark

this log after new firmware changes