Software knock processing

It's all about the code!
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Software knock processing

Post by AndreyB »

mobyfab wrote:
Sat Dec 29, 2018 1:21 am
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 :(
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
User avatar
mobyfab
Posts: 139
Joined: Tue Oct 29, 2013 10:09 am
Location: Versailles, France

Re: Software knock processing

Post by 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.
Last edited by mobyfab on Sat Dec 29, 2018 6:14 pm, edited 1 time in total.
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: Software knock processing

Post by AndreyB »

mobyfab wrote:
Sat Dec 29, 2018 6:01 pm
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 :)
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
mck1117
running engine in first post
running engine in first post
Posts: 1493
Joined: Mon Jan 30, 2017 2:05 am
Location: Seattle-ish

Re: Software knock processing

Post by mck1117 »

mobyfab wrote:
Sat Dec 29, 2018 6:01 pm
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
contributor
contributor
Posts: 2961
Joined: Mon Nov 11, 2013 11:28 am
Location: Moskau

Re: Software knock processing

Post by puff »

lost the plot. what was the idea of avoiding hip9011? was it hard to obtain or hard to set up?
mck1117
running engine in first post
running engine in first post
Posts: 1493
Joined: Mon Jan 30, 2017 2:05 am
Location: Seattle-ish

Re: Software knock processing

Post by 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.
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: Software knock processing

Post by kb1gtt »

puff wrote:
Sat Dec 29, 2018 11:29 pm
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.
Welcome to the friendlier side of internet crazy :)
puff
contributor
contributor
Posts: 2961
Joined: Mon Nov 11, 2013 11:28 am
Location: Moskau

Re: Software knock processing

Post by 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?
User avatar
mobyfab
Posts: 139
Joined: Tue Oct 29, 2013 10:09 am
Location: Versailles, France

Re: Software knock processing

Post by mobyfab »

mck1117 wrote:
Sat Dec 29, 2018 11:25 pm
mobyfab wrote:
Sat Dec 29, 2018 6:01 pm
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.
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: Software knock processing

Post by AndreyB »

mobyfab wrote:
Sun Dec 30, 2018 12:16 am
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?
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: Software knock processing

Post by 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?
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
mck1117
running engine in first post
running engine in first post
Posts: 1493
Joined: Mon Jan 30, 2017 2:05 am
Location: Seattle-ish

Re: Software knock processing

Post by mck1117 »

Indeed I do have interesting findings to report!

Here's the current circuitry on Proteus used to input knock:
image.png
image.png (40.56 KiB) Viewed 33738 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
running engine in first post
running engine in first post
Posts: 1493
Joined: Mon Jan 30, 2017 2:05 am
Location: Seattle-ish

Re: Software knock processing

Post by 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
image.png (5.04 MiB) Viewed 33735 times
mck1117
running engine in first post
running engine in first post
Posts: 1493
Joined: Mon Jan 30, 2017 2:05 am
Location: Seattle-ish

Re: Software knock processing

Post by 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
image.png (52.31 KiB) Viewed 33694 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
running engine in first post
running engine in first post
Posts: 1493
Joined: Mon Jan 30, 2017 2:05 am
Location: Seattle-ish

Re: Software knock processing

Post by mck1117 »

And here's some real data from a car:
image.png
image.png (34.91 KiB) Viewed 33692 times
Captured while just idling the car. Those spikes are tapping on the block with a hammer!
bill
Posts: 219
Joined: Sun Mar 29, 2020 1:44 pm
Location: DC usa

Re: Software knock processing

Post by 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
running engine in first post
running engine in first post
Posts: 1493
Joined: Mon Jan 30, 2017 2:05 am
Location: Seattle-ish

Re: Software knock processing

Post by mck1117 »

bill wrote:
Fri Sep 04, 2020 1:13 am
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
running engine in first post
running engine in first post
Posts: 1493
Joined: Mon Jan 30, 2017 2:05 am
Location: Seattle-ish

Re: Software knock processing

Post by mck1117 »

bill wrote:
Fri Sep 04, 2020 1:13 am
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
Posts: 219
Joined: Sun Mar 29, 2020 1:44 pm
Location: DC usa

Re: Software knock processing

Post by bill »

what brand/model of knock detector/ mic are you using for this??
mck1117
running engine in first post
running engine in first post
Posts: 1493
Joined: Mon Jan 30, 2017 2:05 am
Location: Seattle-ish

Re: Software knock processing

Post by mck1117 »

bill wrote:
Fri Sep 04, 2020 9:26 pm
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
Posts: 219
Joined: Sun Mar 29, 2020 1:44 pm
Location: DC usa

Re: Software knock processing

Post by bill »

thanks. i will check the sensor on my mid-90's german luxo-barge and see if they are similar/same.
mck1117
running engine in first post
running engine in first post
Posts: 1493
Joined: Mon Jan 30, 2017 2:05 am
Location: Seattle-ish

Re: Software knock processing

Post by mck1117 »

bill wrote:
Sun Sep 06, 2020 10:34 am
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.
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: Software knock processing

Post by 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
image.png (234.11 KiB) Viewed 32054 times
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
User avatar
md_sanci
Posts: 69
Joined: Thu May 30, 2019 6:13 am
Location: Romania
Github Username: shadowm60
Slack: Alex M
Contact:

Re: Software knock processing

Post by 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.
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: Software knock processing

Post by 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
image.png (181.45 KiB) Viewed 32021 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.
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: Software knock processing

Post by AndreyB »

One of these three images is not like the others:
Attachments
image_720.png
image_720.png (79.15 KiB) Viewed 30545 times
image.png
image.png (27.12 KiB) Viewed 30545 times
51MG7bDxx0L._SY445_.jpg
51MG7bDxx0L._SY445_.jpg (37.67 KiB) Viewed 30545 times
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
BeerMoneyMotorsports
Posts: 151
Joined: Thu Jan 14, 2021 10:16 pm

Re: Software knock processing

Post by BeerMoneyMotorsports »

i need to connect H64 knock. Ill get some comp data soon.
stefanst
contributor
contributor
Posts: 703
Joined: Wed Feb 17, 2016 12:24 am
Location: USA 08530

RAW data for knock detection H72

Post by 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 266 times
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: Software knock processing

Post by AndreyB »

mck1117 has quietly added knock retard logic into rusEFI https://github.com/rusefi/rusefi/pull/3396
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
blundar
contributor
contributor
Posts: 141
Joined: Tue Jan 07, 2014 4:38 am
Location: Cincinnati, Ohio
Github Username: blundar
Slack: Dave B.
Contact:

Re: Software knock processing

Post by 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.
Post Reply