Software knock processing

[AndreyB]

2024 says:

HIP9011 that can be done in software. (I've done it)

Can you please elaborate? I would love to have working knock detection in rusEfi. At the moment it's not working

[mobyfab]

You can read my code:
https://github.com/fpoussin/MotoLink/blob/master/code/app/main.c#L460

it uses about 30-35% cpu on my STM32F3. I am sampling at 115KHz, processing 1024 samples to FFT512 (256 bins).
it should be around 15% cpu on the STM32F405.

Keep in mind you would need a dedicated ADC to sample this because of the high sampling frequency.

[AndreyB]

You can read my code:

https://github.com/fpoussin/MotoLink/blob/master/code/app/main.c#L460

Any chance for you to start a new thread and elaborate on all this? Some overview and status and limitations and hardware requirements etc? Pretty please

[mck1117]

it uses about 30-35% cpu on my STM32F3. I am sampling at 115KHz, processing 1024 samples to FFT512 (256 bins).
it should be around 15% cpu on the STM32F405.

And if we don't want to cram it in to the main ECU's processor, it is probably much safer (for longevity and flexibility) to use a second microcontroller (something small like stm32f334 or 373 in lqfp48) than an asic like the hip9011.

Also makes development easier, as that CPU can focus on just sampling and DSP, instead of that on top of running the engine too.

[puff]

lost the plot. what was the idea of avoiding hip9011? was it hard to obtain or hard to set up?

[mck1117]

Ooh, the stm32f373 also has a 16-bit sigma-delta ADC, with a programmable gain input. Gains of 0.5x to 32x, in 7 steps.

[kb1gtt]

lost the plot. what was the idea of avoiding hip9011? was it hard to obtain or hard to set up?

Currently we do not have a working chip. The key problem is getting the XTAL to start reliably. A second problem is getting the parameters programmed correctly. Every engine will want different parameters. The chip prevents us from being able to share information which is valuable when tuning the knock detection. Doing this ourselves would allow access to low level information. That low level information is handy to know for tuning purposes. As well it would allow us to make a circuit that works.

[puff]

I thought @andreika got it working. As far as I got, you'd have to set individual thresholds and windows for each engine anyway?

[mobyfab]

it uses about 30-35% cpu on my STM32F3. I am sampling at 115KHz, processing 1024 samples to FFT512 (256 bins).
it should be around 15% cpu on the STM32F405.

And if we don't want to cram it in to the main ECU's processor, it is probably much safer (for longevity and flexibility) to use a second microcontroller (something small like stm32f334 or 373 in lqfp48) than an asic like the hip9011.

Also makes development easier, as that CPU can focus on just sampling and DSP, instead of that on top of running the engine too.

This is running from the CCM, it would probably be 45-50% from flash.
We could use a QFP36 chip for that, they have a larger pitch of 0.65mm.

The sigma delta ADC is too slow for this, and 12bit is plenty.
The F3 has op amps with PGAs.
F301-303 is the best candidate IMO, you don't need any of the fancy stuff from other series.

[AndreyB]

This is running from the CCM, it would probably be 45-50% from flash.
We could use a QFP36 chip for that, they have a larger pitch of 0.65mm.

The sigma delta ADC is too slow for this, and 12bit is plenty.
The F3 has op amps with PGAs.
F301-303 is the best candidate IMO, you don't need any of the fancy stuff from other series.

Let's chat at https://rusefi.slack.com/messages/CF3K8DX26?

[AndreyB]

We have a few interesting commits into master recently https://github.com/rusefi/rusefi/pull/1730

@mck1117 any pictures/videos/suggested configurations related to this DSP knock implementation?

[mck1117]

Indeed I do have interesting findings to report!

Here's the current circuitry on Proteus used to input knock:

image.png (40.56 KiB) Viewed 91897 times

Just a simple AC coupling, shift up to vcc/2, and then lowpass to prevent aliasing once sampled by the ADC.

The resulting signal gets sampled by the ADC, currently at ~218khz. The windowing logic is currently pretty dumb - it starts listening at the moment of ignition, and listens for the next 45 degrees of crank rotation. The samples are then passed through an IIR bandpass filter to listen only to the frequency we care about. That resulting intensity (in dBv, decibels relative to 1 volt) is stored for each cylinder so that we can tell which cylinder knocked.

More to come soon!

[mck1117]

That snip up above is of Proteus v0.4. v0.3 was similar, but had a problem where the input impedance was too low, so the knock signal ended up too quiet for the ADC to hear. That necessitated this bodge job to make it work on v0.3:

image.png (5.04 MiB) Viewed 91894 times

[mck1117]

Ok, time for results (from the bench)!

Here is a characterization of the analog filter (schematic above), compared with a few configurations of digital filter implemented in software on the stm32.

image.png (52.31 KiB) Viewed 91853 times

Blue is the response of the hardware itself - and it performs exactly as designed. The passband is very flat in the middle where we expect to hear useful engine noises, the -3dB bandwidth is from around 2khz to around 28khz. The main purpose of the analog filter is to filter out noise outside of the band of interest that could "trick" the ADC in to hearing frequencies that aren't there.

Then in orange, grey, and yellow are three possible digital filters, applied in software to the signal sampled from the ADC. The filter in use is configured with a center frequency (ie, the information we care about), and a quality factor that picks how selective the filter should be. The bandwidth of the filter is roughly the center frequency divided by the quality factor: a filter with 10khz center frequency and quality factor of 5 will have a bandwidth of 2khz.

In the context of knock sensing, a higher quality factor will more strongly reject noise that's outside of the knock frequency, but will require more precise selection of the knock frequency so as to not accidentally filter it out. That said, good results are possible even with a relatively low Q: the TPIC8101 knock detection ASIC uses a similar architecture to what I've implemented on the stm32, and it uses Q = 2.3.

With Q=5, suppose there's valvetrain noise we want to suppress at 7khz, and our knock occurs at 10khz. If those two signals have similar magnitude, without a filter we would have trouble distinguishing if knock was occurring or not. With the filter, the 7khz signal will be attenuated by 11.7db, which will cut the amplitude of the valvetrain noise by a factor of 3.8. Now, the knock is 4x louder than the noise - much easier to detect!

[mck1117]

And here's some real data from a car:

image.png (34.91 KiB) Viewed 91851 times

Captured while just idling the car. Those spikes are tapping on the block with a hammer!

[bill]

question..." I am sampling at 115KHz," ... can the mic even pick up anything above 20 KHZ? And if the knock is at 10kHZ, then do you need this high of sampling rate? seems 48K is more than enough...
basically the HZ you want to use (10Khz) times 2 = sample rate needed
and 12 bit depth would be fine also...
although it says 1024 samples, which is 10 bit... which would probably be okay also, considering the S/N is probably around 50db or less
16bit = 96 db sound

[mck1117]

question..." I am sampling at 115KHz," ... can the mic even pick up anything above 20 KHZ? And if the knock is at 10kHZ, then do you need this high of sampling rate? seems 48K is more than enough...
basically the HZ you want to use (10Khz) times 2 = sample rate needed
and 12 bit depth would be fine also...
although it says 1024 samples, which is 10 bit... which would probably be okay also, considering the S/N is probably around 50db or less
16bit = 96 db sound

The rule isn't that you sample at double the frequency you care about - you have to sample at double the frequency of any significant content that exists in the analog domain. That means that your analog filter is a function of the signals of interest, then your sample rate is a function of what the filter can filter out.

The reason for the high sample rate is to prevent aliasing: https://en.wikipedia.org/wiki/Aliasing#Sampling_sinusoidal_functions

We care about signals up to 20khz, so the analog filter cuts at 25-27khz. However - it's not practical to build a "brick wall" filter that perfectly attenuates everything above 25khz, and doesn't touch anything below 25khz. See the blue trace in the plot above: it starts rolling off at around 25khz, but by 50khz, it's only down 17db. We want any aliasing to be far down "in the noise" of the system. If it wasn't, a tone at 208khz sampled at 218khz will be indistinguishable from an actual tone at 10khz! At 100khz, the filter's attenuation is sufficient to reject anything that will confuse us, so we have to sample at around double that frequency. The next convenient speed that the ADC can free-run at (ie, without a timer clocking it) is 218khz on the STM32F4 running at 168mhz.

168mhz core clock / 8 = 21mhz ADC clock
21mhz ADC / (84 cycle sample + 12 cycle convert) = 218.75khz

[mck1117]

and 12 bit depth would be fine also...
although it says 1024 samples, which is 10 bit... which would probably be okay also, considering the S/N is probably around 50db or less
16bit = 96 db sound

The ADCs on all* STM32 parts are 12-bit.

* the stm32f373 family has an additional 16-bit delta-sigma ADC, but we aren't using one of those

[bill]

what brand/model of knock detector/ mic are you using for this??

[mck1117]

what brand/model of knock detector/ mic are you using for this??

That hammer test was with the stock sensor that Volvo put there in 1991. It's the garden variety broadband Bosch knock sensor, part number 261231006.

[bill]

thanks. i will check the sensor on my mid-90's german luxo-barge and see if they are similar/same.

[mck1117]

thanks. i will check the sensor on my mid-90's german luxo-barge and see if they are similar/same.

Not particularly important exactly which sensor it is - they used a lot of different part numbers for different connectors/body shapes but most post-1990 Bosch sensors are exactly the same.

[AndreyB]

I've wired a Proteus 0.4 and recoded _something_ on my miata NB2 but it's not knock

https://rusefi.com/online/view.php?log=90

image.png (234.11 KiB) Viewed 90213 times

[md_sanci]

I think we still have some work to do there, i have a feeling that with TS samples we would not see correct data in logs, we would need to process results in fw and output only final results. For example something like on the same cylinder a change of 5db should be signalled... but then again, if we keep this information in ts output buffer, we are not sure that it will be displayed in ts, we need to keep it there longer to ensure user would grab it.

[AndreyB]

I am sorry connector was not properly soldered into breakout board Once pin 4M was soldered I got some sweet data, it's party time!

image.png (181.45 KiB) Viewed 90180 times

https://rusefi.com/online/view.php?log=94

Left side is no load revving, right side is Auto in Drive+brake + throttle, i.e. load.

[AndreyB]

One of these three images is not like the others:

[BeerMoneyMotorsports]

i need to connect H64 knock. Ill get some comp data soon.

[stefanst]

Today I ran the NB2 Miata with fairly standard timing to record a baseline for knock detection. The tune is here: https://rusefi.com/online/view.php?msq=628

Unfortunately, I am unable to upload the logs due to a REO glitch. Since the forum does not seem to allow log uploads anymore, I uploaded as a ZIP file.
The file names are degree window start followed by degree window length.

H72_Knock.zip

(519.54 KiB) Downloaded 540 times

[AndreyB]

mck1117 has quietly added knock retard logic into rusEFI https://github.com/rusefi/rusefi/pull/3396

[blundar]

I'm NOT trying to downplay the significance or impact of the work that's being done here.

With that said, ask yourself this:

Why would pretty much every engine management vendor implement knock sensing and the response to detecting knock slightly differently if there was a universal solution that would work equally well in all situations?

Knock will never be a replacement for tuning - properly implemented, it can prevent a well-tuned car from killing a sensitive engine with bad gas. "Riding" the limits of knock control is not a viable long term control strategy. Every effort should be made in the setup, configuration and DOCUMENTATION of this feature to ensure that its role is defined in such a way that new users understand its limits before they are picking up pieces of broken engine.