Page 10 of 12

Re: Knock sensing ideas and circuit designs

Posted: Thu Sep 03, 2009 1:29 pm
by jharvey
Wow 2 mega ohm you say that's up there. Makes sense why they bias microphones I guess.

I'm also certainly not saying we need RF level design. I'm not concerned about SWR, reflected energy or anything like that. What I was trying to stress, is that with a 20K sound card connected to a 2M microphone, an 800 mV signal will be very different than if the to a 2M sound card. It's very likely the maximum energy you can couple from the microphone to the sound card is when the impedances match. Kind of like an 4ohm speaker with an 4ohm amp.

Good to hear the 20K, that's not far off from the 25K min for the TPIC. This means your data should be very close to what we would expect with the TPIC with min resistor installed. I suspect the empirical data will show us that we want the R1 to be around 1M to 2M, with R2 around 100K.

Re: Knock sensing ideas and circuit designs

Posted: Thu Sep 03, 2009 6:31 pm
by Fred
Actually, the output impedance of almost all audio amplifiers is approaching zero and for good reason.

Re: Knock sensing ideas and circuit designs

Posted: Thu Sep 03, 2009 7:12 pm
by jharvey
Hmmm, P=RI^2, so when R=0 P=0. Doesn't sound right to me. Here's a quote from this link.

http://en.wikipedia.org/wiki/Impedance_matching

"Impedance matching is the electronics design practice of setting the input impedance (ZS) of an electrical load equal to the fixed output impedance (ZL) of the signal source to which it is ultimately connected, usually in order to maximize the power transfer and minimize reflections from the load."

Re: Knock sensing ideas and circuit designs

Posted: Fri Sep 04, 2009 3:13 am
by jharvey
Here's how I see the signal flow from the knock sensor to a usable number in the CPU.

knock sensor source -- narrow frequency energy detector -- trigger-able peak detector and integrator -- CPU logic

Theory being, PPC (ePTU?) typically tells integrator and peak detector to sit idle perhaps by a reset line or some such signal. When a knock window opens, the cpu sets the reset signal inactive, the integrator starts at 0 and adds ADC readings during the window. At the end of the window the PPC reads the value and sets the reset active again. This integrator value would represent the total energy of the knock. Total energy of the knock should give a vague idea of the cylinder temperature, and therefore if the boundary layer is getting thin. Tied to the same reset signal is the peak detector. This simply starts at 0 and takes each ADC reading, then compares it against the last reading, saving the higher of the two, and at the end of the window it contains the max amplitude of the knock.

Both number could be causally saved in a table that correlates to the cyl, and used at a later time for fuel and spark calcs. What to do with those number will be interesting. I like the two methods, instead of just one.

For example, if you have a large spike, with no energy, that might indicate a RF leakage problem or some such other issue. If you have a very low peak, with a fair bit of energy, it might indicate a bearing going wrong or some other reason for a rising noise floor. When both values appear to be valid knock ranges, I think a larger number in the amplitude would increase priority of making rapid adjustments now. While with a lower amplitude, and higher energy, it would indicate you don't need to be so aggressive in correcting it. Back it off so you don't cause long term damage.

For example, a plasma cutter breaks through the boundary layer, by having a large spike of heat that cuts through like a knife. It simply blasts through the boundary layer, and keeps on going. Cutting torches, don't have that pop. They have to heat up the metal until it's temperature is hot enough for the boundary layer to go away, then the flame can touch the metal and do it's thing. It's kind of a blunt approach vs sharp approach. Both can remove material.

I also think the integrator and peak detector would be best left in software. They shouldn't be to hard to accomplish, and would be much more flexible and more robust in software.

If the above sounds right, I'm willing to consider this schematic good, and up the priority of the thermo coupler.

Re: Knock sensing ideas and circuit designs

Posted: Fri Sep 04, 2009 12:30 pm
by davebmw
Fred wrote:Actually, the output impedance of almost all audio amplifiers is approaching zero and for good reason.
Very good point Fred :) The output has to be as low impedance as possible to damp the mechanical motion of the speaker cone otherwise the speaker will oscillate back and fore like a right lemon causing some seriously nasty distortion.

JHarvey, I think your spot on with the 1M as I have dug out my spare BMW ECU and both Knock sensor channels measure 1Meg to knock sensor ground, after that I'm not able to follow it as the tracks disappear into the internal layers of the board, as Bosch use all their own marking on the chips it makes it difficult to track down, well anything really, so I haven't a clue about the front end gain setting.

What we have is essentially an Audio frequency source, we are using a microphone (in this case a tuned narrow bandwidth piezoelectric microphone) to passively listen to what is going on in the engine block. There is little signal but plenty to drive into a 20K load, this loading which is considerably lower in Z than the source effectively terminates the signal and suppresses any minor noise that may occur en-route this may help filter out unnecessary crap, but is not the best solution.

The way I envisaged the circuit is a simple front end amp, a bandpass filter, a peak detector, digital output to the MCU which retards the timing by a pre-settable number of degrees (determined in software by the user) this provides a closed loop feedback that could do the job.
The TPIC provides all this on one chip and the fact that they specify a minimum of 25K for the front end Z confirms some of the above waffle. The plethora of settings in the TPIC allows tweaking for specific sensors, block materials, combustion chamber sizes and level of tune etc.

I see the windowing is quite an important thing as spurious noises from the various mechanical parts could encroach on the knock signal domain creating false triggering of the peak detector.

Now consider if you will, a knock detect system without windowing: As piston 1 rises on the compression stroke, piston slap on another cylinder, the valves closing, or the cam follower tapping may trigger the peak detector early giving false knock retard without ever getting near firing the plug, making the timing retard excessive could lead to gutless performance, possibly burnt valve seats, dead cat and excessive fuel consumption per HP, etc etc.

A Chip Select signal from the MCU when it needs to be listening could be pre-settable in software by the user to allow more tweak-ability than you can shake a stick at. I know this puts more work onto the laps of the software guys, but I have met Fred in person and I know he is a very dedicated individual that only requires about 1 hour sleep in 24 so I know he's the kind of guy that requires these kind of challenges, :lol2:. Plus the guys a bloody genius, I'm sure he could come up with something us hardware guys can interface to. (Sorry Fred, feel free to flame me if you like :) lol)

Re: Knock sensing ideas and circuit designs

Posted: Sat Sep 05, 2009 7:32 pm
by Fred
davebmw wrote:but I have met Fred in person and I know he is a very dedicated individual that only requires about 1 hour sleep in 24 so I know he's the kind of guy that requires these kind of challenges, :lol2:. Plus the guys a bloody genius, I'm sure he could come up with something us hardware guys can interface to. (Sorry Fred, feel free to flame me if you like :) lol)
Nah, I'll just do this: :oops:

Re: Knock sensing ideas and circuit designs

Posted: Sun Sep 06, 2009 8:10 am
by davebmw
:lol2:

Re: Knock sensing ideas and circuit designs

Posted: Tue Sep 08, 2009 1:58 pm
by mk e
Movex wrote:To make knock detection available on a DIY device the trace data should be accessible by serial port or something similar. Not everyone has got a scope to do this and for saving a trace signal you need a expensive scope.
As proposed by Dan the waveform should be sampled by the MCU itself for this reason.

Attached a example from a PowerPC based ECU where the raw signal and the filtered signal are processed internally and sent to the software running on a notebook.
I don't know how I missedThe “running on a PowerPC” part :)

Pop on over to the hardware and software planning threads and let’s see what we can share and get both projects jump started.

How important do you think seeing the wave form is to getting it working on a general application after the initial work is done on how it will work?

By this I mean if the system is set up to take a window and threshold does the general user need to see the wave form that they probably won’t actually understand to get it working? If so knock is a feature that won’t get much use outside of the development team types I don’t think because most car guys I know don’t know how to read a signal trace whether is comes from a scope or shows up on their PC screen.

I was hoping we could get knock boiled down to a window and a threshold setting and I think that is what the general assumption has been reading the other posts…do you think we are smoking crack and the signal trace is a must have?

Re: Knock sensing ideas and circuit designs

Posted: Tue Sep 08, 2009 3:04 pm
by Movex
The problem on a simple threshold plus a window is that the integrator which is attached after the HW/SW filter set also integrates noise or other stuff. It is essential to have an idea how my raw signal looks like. Human can see if something is going wrong but computer can't. If the Phytec PCM028 board will be the computing source we can store some knock datasets in external RAM and be read out be a PC tool. Also an aspect, support, people simply post their trace data in the forum and someone can help without it's like looking into the magic bowl.

The filterset should not only be intended to use accoustic sensor, ion sensing or pressure measurement are options, too. In terms of algorithm and simplification you can sample a second window where certainly no knock occurs. This data set is compared with the window where I might expect knock. From my point of view this can completely done inside a modern MCU. External knock chips aren't so flexible.

Re: Knock sensing ideas and circuit designs

Posted: Tue Sep 08, 2009 3:46 pm
by mk e
Movex wrote:The problem on a simple threshold plus a window is that the integrator which is attached after the HW/SW filter set also integrates noise or other stuff. It is essential to have an idea how my raw signal looks like. Human can see if something is going wrong but computer can't. If the Phytec PCM028 board will be the computing source we can store some knock datasets in external RAM and be read out be a PC tool. Also an aspect, support, people simply post their trace data in the forum and someone can help without it's like looking into the magic bowl.

The filterset should not only be intended to use accoustic sensor, ion sensing or pressure measurement are options, too. In terms of algorithm and simplification you can sample a second window where certainly no knock occurs. This data set is compared with the window where I might expect knock. From my point of view this can completely done inside a modern MCU. External knock chips aren't so flexible.

I guess I had in my head that we could sample the noise outside the knock window to both set the baseline and confirm the sensor is working. Then once the baseline is known we could integrate anything above the noise threshold.

I do like the idea for being able to look at the signal and we are planning to use the phytec board for the foreseeable future so ram is there so we certainly can have this feature. But, even if we look at the signal it still seems like we need to boil the function down to a hand full set points. From there it seems like we should be able to come up with an algorithm that can look at the signal and drop in the right set points…this could come later though once there are a good number of data files collected and available to look at. Keep it simple at first I guess.