Making the stock knock sensor reliable and accurate...

[cbrfrenzie]

I am currently in the process of developing an electronic knock sensor conditioning unit. This will be able to tune the center frequency, bandwidth and sensitivity of the knock signal before it goes into the stock ECU. It will also have the capability to run 2 knock sensors into this module, so that you can see knock from each cylinder pair (1,4) and
(2,3).

There would be to re-locatable LED outputs, one for each sensor that you could mount anywhere... i.e. one on the left side of the instrument cluster for cylinders (1,4) and the other on the right side of the instrument cluster for cylinders (2,3).

The technology built into this device would be very sophisticated... where there are blanking times where knock is completely ignored... except when inside a crank angle "window" where knock CAN occur, such as the compression stoke... this would greaty reduce the effects of valve train noise, being the valve would be closed and not slamming open or shut.

The reason for this post is to see if anyone would be interested in a product like this, specific for our DSM's. There would be a model for the 2.0L, 2.3L stroker, and the 2.4L 4g63 engines, given they have different engine harmonics. I know how much it sucks ass to loose 20+ WHP due to some valve train noise on some of our higher horsepower setups... especially those with stiffer valves prings.

Please clobber me with your inputs and suggestion on what would be desired as far as a user interface for knock indication.... i.e. the LED idea blows, or the LED idea sounds sweet...

Extensive R&D will be done on my personal car to ensure correct operation for ALL ranges... as I have 2 AWD dynos at my workplace and can simulate ALL engine loading conditions with the load control features...

Please and thank you!
Chad

 

[SOADweskey]

I'm interested in something like this as phantom knock is a giant pain in my ass. And I'm not brave enough to just configure DSMlink to ignore the sensor. But like all DSMers cost is a concern to me. I'm willing to pay in the hundreds but not in the thousands if you know what I mean.

 

[cbrfrenzie]

Pricing on this hasn't been determined yet, as I need to get a working prototype and make sure all the hardware is rock solid. My guess would probobly be around the $100 - $200 mark, depending on overal complexity.

The goal of this project is to provide the DSM community with a LOW COST unit that provides VERY accurate knock information to the computer utilizing the stock sensor, tuned specifically for the 4G63 2.0, 2.1, 2.3 and 2.4 engine configurations.

I've also thought about making a nice software utility for a laptop that could datalog info and/or display it in a real time graph, or gague. I'm still deciding if I want a knob of some sort to adjust sensitivity, ( i.e. a motor mount is trash and the engine is vibrating like hell ) or if I should un-load that into a software application.... more design ideas.

I'm just looking for some FEEDBACK on what people want as the human interface.

 

[SOADweskey]

Well then off the top of my head here some things I would look for.
1. Ability to function with the varying types of crank and cam sensors found on these engines.
2. I think a knob for adjusting sensitivity would be cool but adjusting via laptop software is fine with me.
3. It is critical that it interfaces with the ecu to stop phantom knock.
4. It would be a very nice touch if I was able to log both sensors in DSMlink.

 

[cbrfrenzie]

1. Ability to function with the varying types of crank and cam sensors found on these engines.

Circuits Done

2. I think a knob for adjusting sensitivity would be cool but adjusting via laptop software is fine with me.

I think it might be just a knob for the first rev, until R&D is done, then a software app might be in order.

3. It is critical that it interfaces with the ecu to stop phantom knock.

That is the purpose of this module, to completely eliminate phantom kock. At the output of this device, there would be only "real knock"... all the phantom knock and excess engine harmonics/ valve train noise would be filtered out.

4. It would be a very nice touch if I was able to log both sensors in DSMlink.

There would be only a single input to the stock ecu. Since both the knock sensors will be knocking at different times, (based on the physical design of the engnie) their outputs can be OR'ed together and sent to the stock ECU that way. DSMLink would still logg knock, it would just be the sum of both of the sensors. Thats where the software application would come into play, so you could extrapolate the knock sum out into each individual sensor. Without DSMLink firmware modifications, I don't think you could monitor both sensors in DSMLink.... I've already tried to get ahold of their firmware, but they are guarding that stuff with their lifes!

 

[Ravenous]

I would definitely get one, but I would prefer it to be software based, that way I don't have another random knob/switch to clutter my cabin. Also once it was setup I wouldn't need to adjust it so the knob would be moot.

 

[turbosax2]

Have you talked to Thomas Dorris about possibly integrating this with DSMlink? Just from reading the forums, he is usually open to suggestions and helpful in getting different things to work with DSMlink. I agree that full integration into DSMlink would be very convenient and definitely an aspect that would sway my purchase.

Unless the led's are very small and easily hidden, the led idea blows.

 

[97gstjosh]

This would be awesome. I will def. be in on this when you guys are ready to release it.
It would help me out alot. Seriously talk to Thomas I think he would really consider it. If not I would still want one. I agree with the LED size. If they are smaller than a penny I think that would work. Keep us updated. I wouldnt mind if it was a knob I would prefer it actually

 

[turbosax2]

This would be awesome. I will def. be in on this when you guys are ready to release it.
It would help me out alot. Seriously talk to Thomas I think he would really consider it. If not I would still want one. I agree with the LED size. If they are smaller than a penny I think that would work. Keep us updated. I wouldnt mind if it was a knob I would prefer it actually

Smaller than a penny WTF Man thats huge! I was talking like no bigger than the eraser of a pencil

 

[97gstjosh]

Smaller than a penny WTF Man thats huge! I was talking like no bigger than the eraser of a pencil

Yeah thats a better description
Thats what I wanted to say I just couldnt think of anything smaller.
Thanks for saying that

 

[Calan]

Interesting... Not to doubt your abilities, but I'm curious to see if you can actually isolate true knock from the sensor noise floor and "random" output.

I would of course be interested in ANYTHING that produces a cleaner and more acurate knock signal.

 

[kenamond]

I would not find this useful as a "knock sensor upgrade" strictly speaking, but if you could display a knock count high water mark updated a few times a second (or maybe adjustable frequency) to a gauge for us 2g guys who don't have DSMlink, that might sway me.

A concern I have is pre-ignition being missed if the window doesn't completely cover the intake stroke - or perhaps the end of it before the intake valves close - as well. Maybe I'm misinformed, but pre-ignition often happens around BDC at the start of the compression stroke, and will ruin your engine orders of magnitude faster than detonation. I'm not sure how car-specific that is, and you seem to know your stuff, so if I'm full of it, that's fine.

And what do you have to do to the block to add a 2nd knock sensor? Or would it just use the CAS/CPS and the existing knock sensor (or maybe a different/better sensor in the same location)?

Finally, I would find it very interesting if you posted a tech article describing the in's and out's of the DSM knock sensor and as much as you could about ultimately ending up as a knock count in the ECU.

Wish I had an AWD dyno at work. Can it motor the engine?

 

[cbrfrenzie]

A concern I have is pre-ignition being missed if the window doesn't completely cover the intake stroke - or perhaps the end of it before the intake valves close - as well. Maybe I'm misinformed, but pre-ignition often happens around BDC at the start of the compression stroke, and will ruin your engine orders of magnitude faster than detonation. I'm not sure how car-specific that is, and you seem to know your stuff, so if I'm full of it, that's fine.

You are right on track here. The window period would have to be a programmable value, until a maximum is reached based on R&D on all the different DSM engine's behaviors. The window would have to cover x-degrees BTDC to x-degrees ATDC on the compression stroke, that will be determined based on my dyno testing. Also, anyone who would be willing to send me their datalogs WITH knock present so that I have a better understanding of a "worse case scenario" to utilize in this windowing scheme.

And what do you have to do to the block to add a 2nd knock sensor? Or would it just use the CAS/CPS and the existing knock sensor (or maybe a different/better sensor in the same location)?

This would be up to the user. I plan on developing this system based on the existing stock knock sensor, to minimize cost to the end user. A second sensor could be mounted to the block, preferably in a location similar to the stock location, just moved toward the transmission side of the engine for a more accurate knock signal form those cylinders, just as the stock location is right between two cylinders. Of coarse a hole must be in the block to utilize... maybe the balance shaft bolt hole that is used for timing the engine could be utilized.

Finally, I would find it very interesting if you posted a tech article describing the in's and out's of the DSM knock sensor and as much as you could about ultimately ending up as a knock count in the ECU.

That is a good idea. To sum it up, it all depends on the hardware and firmware in the stock ecu and/or DSMLinks version of the code. If I were to design an ECU (which I'm actually doing as well ) I would have some voltage threshold and frequency window that dynamically changed with RPM to get an "ON" or "OFF" state from.

An example at 5000 RPM:
Anything > 750 mvolt and between 83 Hz and (83Hz + dynamic frequency window) would count as 1 knock count.

Anything > (750 mvolt + dynamic step size) and between 83 Hz and (83Hz + dynamic frequency window) would count as 2 knock counts.... and so on.

As I said above, without an ECU schematic and Firmware in hand, I couldn't tell you, however when I start testing I can reverse engineer it out based on the data I obtain... So I'll update this once I figure that out.

Wish I had an AWD dyno at work. Can it motor the engine?

Our Dyno hardware can monitor many things. We have an analog module that can monitor any analog signal from -10volts to +20 volts ( which I designed ), and its displayed on the dynographs overlaying anything else you log.... ie RPM, EGT, whatever you wish. Also with an OBD2 compatible vehicle we can overlay anything the ECU keeps in RAM with any of our dynocharts.... great tuning AND diagnostic tool. Finally with the use of a digital oscilliscope you can capture anything your little heart desires.

Sorry for the novel, but information is information.

 

[cbrfrenzie]

Interesting... Not to doubt your abilities, but I'm curious to see if you can actually isolate true knock from the sensor noise floor and "random" output.

That is the beauty of a micro-controller controlled dynamic level and frequency filter with exhaust stroke blanking.

R&D will be the true teller of it all...

 

[spawn7037]

I would perfer to see a knob in to control the sensitivity seeing as I don't have DSMlink and probably won't beable to get it anytime soon. But this sounds pretty cool.

 

[Calan]

That is the beauty of a micro-controller controlled dynamic level and frequency filter with exhaust stroke blanking.

R&D will be the true teller of it all...

Got a feeling there be some pretty sophisticated filtering algorythms, considering all the noise these things can make

Good luck with it ... will be looking forward to watching your progress.

 

[kenamond]

An example at 5000 RPM:
Anything > 750 mvolt and between 83 Hz and (83Hz + dynamic frequency window) would count as 1 knock count.

Anything > (750 mvolt + dynamic step size) and between 83 Hz and (83Hz + dynamic frequency window) would count as 2 knock counts.... and so on.

Is that how our ECUs (in general) determine knock count? Just a "louder" knock (I'm assuming louder knock in the frequency band means higher signal voltage)? Does that just indicate a higher pressure spike?

I love information!

 

[90laserRSfwd]

what ???? WTF ..... jk I would be interested in this too. I like the idea of talking with Tom also about integrating this into the v3 dsmlink

 

[cbrfrenzie]

Is that how our ECUs (in general) determine knock count? Just a "louder" knock (I'm assuming louder knock in the frequency band means higher signal voltage)? Does that just indicate a higher pressure spike?

I love information!

The frequency window is related to engine RPM as follows:

frequency window = RPM / 60 = RPSecond = Hz, thats where my 83 Hz figure came from. Anything lower frequency is just noise, and anything higher than that frequency + the window is a "potential" knock. The more intense the knock is, the higher the amplitude AND the higher the frequency of the knock signal, meaning how fast the signal rises and falls. Here this week I'll try to get some scope screen shots of a knock sensor output with different magnitudes of forces applied.

Keep em comin guys... I'm colaberating a nice note sheet here.

As far as DSMLink, it would still act as it would without this module, however it would count knock for the SUM of BOTH sensors, instead of the single one. To enable DSMLink to log both sensors, a seperate Digital input pin needs to be re-purposed on the ECU... then the internal circuitry needs to be the same as the original knock sensor input pin.... IF only I had an ECU schematic...... anyone know where to find one

 

[turbosax2]

You should take to steve. He knows ecu's.

 

[kenamond]

The frequency window is related to engine RPM as follows:

frequency window = RPM / 60 = RPSecond = Hz, thats where my 83 Hz figure came from. Anything lower frequency is just noise, and anything higher than that frequency + the window is a "potential" knock. The more intense the knock is, the higher the amplitude AND the higher the frequency of the knock signal, meaning how fast the signal rises and falls. Here this week I'll try to get some scope screen shots of a knock sensor output with different magnitudes of forces applied.

Hmmm. I was reading about knock sensors somewhere, and they mentioned that knock is detected by listening for the characteristic frequency of the block (like what frequency spectrum you'd get if you whacked it with a hammer like a bell). Is that not done for our knock sensor setup? Or is that a separate part that's independent of what you're talking about.

Also, wouldn't you have to look at 41.5 and 83Hz @ 5000rpm so that you catch one cylinder knocking (41.5Hz) as well as the other, out-of-phase cylinder knocking as well (83Hz)? If you're listening to 1+4 with one sensor and 2+3 with another sensor, I guess you don't have to check 166Hz?

EDIT: And why not report knock on each cylinder? If you're not pre-igniting, the knock wouldn't overap between two different cylinders' windows (most likely)...if one cylinder knocks more than others, that'd be handy to know.

Thanks for all the info so far!

 

[GVR4592]

So you want to build a J&S safeguard, but without the safeguard. I guess I just don't see the point, without being able to integrate it into a datalogger or actively control timing. I believe the next version of Dsmlink is going to give access to knock control, so you wouldn't be able to go that route.

I don't think you need two knock sensors to accomplish your goal though. You should be able to retrieve data from the ecu or intercept it from the CAS, and determine which cylinder is knocking. Have you ever tuned an ems with programmable knock control?

 

[cbrfrenzie]

Hmmm. I was reading about knock sensors somewhere, and they mentioned that knock is detected by listening for the characteristic frequency of the block (like what frequency spectrum you'd get if you whacked it with a hammer like a bell). Is that not done for our knock sensor setup? Or is that a separate part that's independent of what you're talking about.

That is independant. For example, in GM vehicles, there is a knock sensor conditioning unit, which is not in our vehicles. It "might" be located inside the stock ECU's circuit board, but I can't know for sure until I get a schematic. The module I'm designing will take into account the 4G63 engine harmonics, exactly as you mentioned above.

Also, wouldn't you have to look at 41.5 and 83Hz @ 5000rpm so that you catch one cylinder knocking (41.5Hz) as well as the other, out-of-phase cylinder knocking as well (83Hz)? If you're listening to 1+4 with one sensor and 2+3 with another sensor, I guess you don't have to check 166Hz?

These frequencies are the actual frequencies of the signal, not the frequency domain analysis of the hardware filter I am going to implement, (if that is what you were implying). Those frequencies are there to be used in the software filter that the microcontroller will be using to extrapolate valve train noise out of the signal. IF you think about it, the rise and fall of your knock sensor signal is going to be greater than a single engine revolution, but less than some threshold vavlue, that is dynamically changed via an algorithm with respect to RPM.

In my 5000 RPM example, if you get a knock frequency of 41.5Hz then that means that the duration of the detonation lasted for two engine revolutions, which is not possible. That is the purpose of the varying frequency window. I hope that makes sense.

EDIT: And why not report knock on each cylinder? If you're not pre-igniting, the knock wouldn't overap between two different cylinders' windows (most likely)...if one cylinder knocks more than others, that'd be handy to know.

Individual cylinder knock sensing was my original plan, my first post might have been a little bit un-clear on that. The purpose of two knock sensors was to increase the resolution for the cylinders furthest from the stock sensor. Technically only a single sensor is needed, but the further you go from the sensor it self the weaker the detonation signal becomes. My efforts was to standardize the signal strength for each cylinder so that my signal gains could be constant as well as the software and hardware filtering could be minimized.

 

[cbrfrenzie]

So you want to build a J&S safeguard, but without the safeguard. I guess I just don't see the point, without being able to integrate it into a datalogger or actively control timing.

I think people are missing the whole idea here..... If you can datalog the knock sensor on your stock ECU, then you can datalog it still with this system in series between your knock sensor and ECU. I was also going to implement a software utility that would BOTH datalog knock as a function of RPM as well as display current knock in real time. If the stock ECU can actively control timing, then it still will be able to with this module in there, I guess I don't understand why you think it wouldn't.

I believe the next version of Dsmlink is going to give access to knock control, so you wouldn't be able to go that route.

If the new DSMLink uses knock control with the stock knock sensor, then this system will work as if it wasn't even there..... the signal will just be CLEAN, and there will be NO phantom knock, so I would be able to go that route.

I don't think you need two knock sensors to accomplish your goal though. You should be able to retrieve data from the ecu or intercept it from the CAS, and determine which cylinder is knocking. Have you ever tuned an ems with programmable knock control?

Yes I have tuned may vehicles with a knock control, including AMA race bikes (yamaha R1's, tons of Gixers......), Mustangs, Audis, DSM's with AEM EMS and many more. The custom ECU I am developing right now has programmable knock control..

The purpose of two sensors is to increase my knock sensitivity resolution such that my hardware/software filtering has more of a signal to work with, instead of amplifying it up and bringing noise in with it.

Bottom line is that whatever tools are avalible such as DSMlink or any other tool for a stock DSM ECU will NOT be affected in any way, except for the fact that there will no longer be phantom knock.... When the ECU see's knock, its Guaranteed to be knock and nothing else. ON TOP OF THAT, the software utility will display real time individual cylinder knock, as well as datalog it....
So in my mind, I see this as a knock sensor conditioner, a knock sensor detector for individual cylinder knocking, and a knock data logger.

 

[turboglenn]

If i were still on a stock ECU or had any provision for a knock sensor i'd be interested in it. It sounds a lot like what J&S offers up on their knock sensors for hi-po applications, you can tune out a lot of things and it has cylinder independant control, but it's a stand alone unit that hooks up between your ECU and ignition transistor to modify the signal coming out from a stand alone or ECU without provisions for a factory knock sensor ( this is what i have to run, i just have to make room on the "want list" for it )

I hope you come through with this, i'm sure if you do the control system will be worked out nicely wether it be knobs, or digital momentary touch keys and an LCD display.

If you ever do this, make sure to make the post stay active long enough for me to find it or PM me, i'd be interested in trying one on a friends car just to see if it's something i would like to work with in the future

Also, PM me some info on your ECU, i install and tune countless stand alone ECU's every spring/summer when the porsche club guys come out trying to buy their way into first place with goodies. If it's nice and reasonably priced and easy to work with, i am definately interested.. i prefer simple DOS software, but being that RS-232 ports are phasing out, i guess i'm going to have to go more to windows based stuff with the use of USB connections unless it can be done in DOS... haha I can tune a car, btu i don't know ish about PC programming