[info] HIP9011 module

[AndreyB]

SVN repository
Full archive
Schematic.pdf
Oshpark

ECS-40-20-5PX-TR CRYSTAL 4MHZ: XC1238CT-ND
IC REG LDO -5V 0.1A SOT89-3: 497-1219-1-ND
CAP ALUM 100UF 16V 20% SMD: EEE-FP1C101AP
CAP ALUM 10UF 16V 20% SMD: EEE-1CA100NR

[AndreyB]

BTW HIP9011 is not in stock @ digikey, are they retiring this chip? I am using the TPIC8101 version which is the same thing

[blundar]

http://www.findchips.com/avail?part=HIP9011

Rochester electronics looks to have quite a few of them but the "major" electronics retailers seem to have retired the part.

http://www.findchips.com/avail?part=TPIC8101

Marginally better stock on the TPIC8101. It's still a chip approaching end of life AFAIK...

All the OEMs that once would have been interested in chips like these are using MCUs fast enough (SH4/SH5, Tricore, fast MPCs, etc.) to do knock FFT processing on MCU.

[AndreyB]

Thanks god we are not in large scale car manufacturing so we do not have to make an important decision here. Let's begin with a 9011/8101 for now and see how life goes

[kb1gtt]

Also many OEM's are switching to Ion Sensing, so knock circuits are becoming old school any how. I like the use of a generic differential PGA as a input. Doing the rest in software isn't really that hard. I'm not a fan of the TPIC8101, it shares the GND as one side of the sensor pickup, which causes it to have a poor Common Mode Rejection (CMR).

[blundar]

OE Ion sensing systems I know of:
-Saab Trionic turbo4
-Some Isuzu / Honda V6

Delphi seem to be getting on board with Ion:
http://delphi.com/pdf/techpapers/2013-01-0354.pdf

I'm still not convinced that it will ever be truly useful, especially for high revving race engines. Ion is useless during the actual spark discharge. The long spark duration of an inductive coil discharging takes upwards of a millisecond in many cases. For a high-revving engine (say 9600 RPM) an entire cycle happens in 6.25ms. If you have active spark discharge for 1ms / 6.25, that's pretty much the entire window that you care about.

[AndreyB]

The board has arrived

[AndreyB]

It has been two months since the board has arrived but I am failing to find time to play with it

[puff]

chip is 234 rur in rus. retail. one needs two chips for V-type motors?
you don't have time to solder it? interface it to the board (firmware-level)? or improve ignition timing logic?

[AndreyB]

Most of the above. Soldering should take 20 minutes, but I do not have the time to write the firmware integration - and, most importantly, I do not have time to figure out how to test it (real signal or fake signal or recorded signal). The whole effort is on the scale of days and I do not have that time. Bottom line - I have the boards, I probably have the components but not the time to make all this work together. There is some skeleton of the integration at https://sourceforge.net/p/rusefi/code/HEAD/tree/trunk/firmware/hw_layer/HIP9011.c

[puff]

probably, severity level for any knock event is different for any given engine, due to different sensitivity of the knock sensor, its position, etc. this makes things complicated.
therefore we need to develop a technique, allowing to set up the sensor (i.e. coefficients in the firmware?) in any environment.
what do we know about the duration of each such event?
Personally, i'd start with a simple bench (µc, SPI-bus, ten leds, some simple software and a small hammer )

[AndreyB]

... and a small hammer

Please let me know what size of hammer I should mail you to make this happen
http://oshpark.com/shared_projects/bYitHt3p

[puff]

I already have a hammer
$10 per a set of three, plus $7 for the chip, plus not sure if this one would fit
http://www.autoopt.ru/catalog/080364-datchik_detonacii_vaz_2112_zmz_406_avtopribor_k/
somewhat $20?
The thing is I just spent all my money on my paypal account, and I don't know what to do with three of them, so you'd better mail me one of those boards

[AndreyB]

If something does not fit, use the hammer. Problem solved.

Please PM me your address I will mail you a board.

[puff]

first give me couple of days to evaluate the problem, explore the data sheet and check if i am capable of doing anything at all.
guess i need to start with physics - what is detonation, when it happens, how it comes out (rhythm, frequency of signals?), basically, how this HIP9011 works.

Am I right that SPI is used just to set up the chip, and there is intout pin (Buffered output of the integrator. Output signal is held by an internal Sample and Hold circuit when INT/HOLD is low), which goes high when detonation is registered? So we need to set up the chip just one time once the power is on, and then just use it?

[puff]

for those interested in its operation:
http://www.intersil.com/content/dam/Intersil/documents/an97/an9770.pdf

[kb1gtt]

A quick crash course, yup, SPI is for config, and it might come with nearly acceptable defaults. The ping sound is frequency dependent based on your engine moldings and such. The frequency is typically around 5kHz. This chip has a fairly wide front end filter, so it generally triggers from any noise from well below 5kHz to well above 5kHz, so the fine tuning of the frequency isn't really very helpful. Perhaps if you really tune it, and you attenuate the signal enough, perhaps you can get a fairly narrow peak. However I understand that's not all that handy. So I would suggest not bothering so much with attenuation or fine tuning the frequency.

I believe a general algo you may want is something like this. You need a window where you look for an increase in noise that would indicate you might have a knock. This window will move based on RPM, ignition timing, and the ping's fixed signal delay. So if you have a fixed timing and if you are to ping at say TDC, and it takes 1mS for the ping to pass to the MCU, then at say 1kRPM, your window will need to be X +/- 5 degrees. However if you are at 5kRPM, your window will need to be Y +/- 5 degrees. X and Y will be different crank angles.

You are looking to sample the knock window and compare that value with the average value. You look to see if the value you get from this revolution has more noise than the average engine noise. To get the average, you'll need to take a sample say every 1 degree of rotation and collect an engine noise vs degree table. Then engine noise will likely vary based on RPM, so you'll probably want to map this based on RPM. Similar to the fuel vs load tables. Such that you have a table of noise values and can determine a noise value based on RPM and engine position. This table gets programmed during the install and configuration stages of a build. Generally it should not change over time, so it would be fine on an SD card if memory is an issue.

Then you need to get a live reading for every degree of rotation. This reading needs to be compared against the above mentioned look up table. If the noise is higher than expected, then you have a potential issue and should raise an alarm of some sort. To determine what kind of alarm and what kind of actions should be taken, you should compare against a knock window. If this higher than average noise is with-in the knock window, you want to retard the timing proportional to the amount over the threshold you have measured.

Ultimately, if you have a good brick wall filter, you could potentially simply look for say 5kHz to 5.5kHz and if you see any noise in that range, back down the timing. However these filters are so wide, they can't determine the difference between a ping, and alt bearing noise, or water pump noise, or even lifter noise. So you have to use other algo's.

Hmmm, if that doesn't make enough sense, perhaps a phone call is in order.

[puff]

thanks! basically you described the whole logics that should be implemented in firmware

[AndreyB]

@ has assembled & tested the module, it is now officially functional.

[kb1gtt]

Very cool, very cool. Looks like that was triggering in about 9 cycles. That's good info to know.

[Spilly]

I was contacted via email about this project. I very recently wrote a driver for another uC (Parallax Propeller) and it should not be that big of a deal to get it working with the STM32F4.

The code a few posts back appears to use an SPI library/function. However, I have written a bit-bang SPI function that ensures the timing is correct. Are there any objections to using my bit-bang SPI function?

My current driver does the following:

Code: Select all

user configurable integration window in degrees (between what engine positions do you want to listen for knock)

at start-up send SPI configuration (prescaler, channel select, bandpass, enable advanced mode)

calculate Tc based on rpm

update Tc via SPI

calculate what gain value to use based on rpm and time constant (should make for more consistent integrator output, but I am still testing this)

update gain

Set INT/HOLD pin active based on engine position (integration window)

once integration window ends, get 10-bit integrator output

calculate Tc based on rpm

update Tc

calculate what gain value to use based on rpm and time constant (should make for more consistent integrator output, but I am still testing this)

update gain

Set INT/HOLD pin active based on engine position (integration window)

once integration window ends, get 10-bit integrator output

etc.

Let me know if you have any ideas or if you want to do anything differently than what I have described.

To save me some time, can you point me to your function that calculates engine position?

[AndreyB]

Hello @, I am Andrey.

I am open to http://en.wikipedia.org/wiki/Bit_banging for a prototype but for a final implementation I would probably prefer a driver/HAL call just to separate the HIP logic from HW layer, but I am pretty flexible on anything

As for synching with TDC, see the code/comments around tdcMarkCallback in rpm_calculator.cpp

[acab]

Hello Spilly, it was me. Its great that you interested of rusEFI.

[AndreyB]

I very recently wrote a driver for another uC (Parallax Propeller)

That must be https://github.com/spillymon/TPIC/blob/master/TPIC8101_V1_5A ?

Looks like I am might poke you in a couple of days

[puff]

what's the purpose of R5 (10Ohm) resistor between the lm7805 and the chip? does it work as a fuse? and what's the value of X1?

[kb1gtt]

R5 is part of a low pass filter.

X1 is 8MHz on Frankenso, so you probably want 8MHz as well. However the frequency needs to match the software that uses this chip.

[puff]

the low-pass filter on the supply chain?
That'll be same rusefi, same software, so I don't know why you make such a note.
I am going to get rid of 7805 and power it up from the same 12v-to-5v power supply as the discovery and frankenstein.
Still couple of questions: how do I hook it up to the discovery/frankenstein?
Is P4 used to connect to frankenstein" (need to look up the pinout)
int/hld and test are used for testing purposes only?
Where do I connect the output? What voltage levels do we expect there? There seems to be a voltage divider (R15/R16) - do i need anything else? Do i connect it directly to adc on disco or through the opamp thing.

[AndreyB]

This is a bit unfinished (untested) and a bit untested (no proof that real knock is detected), at this point I would not bother using it.

[puff]

I thought you posted a video demonstrating the hip logic works?
Looking through the datasheets of hip and tpic I noticed these two chips have a bit different connection scheme (with regard to xin-xout pins). the input schematics is also a bit different.
Are these pull-ups on spi line necessary? neither schemes I examined have them.

[AndreyB]

Are these pull-ups on spi line necessary? neither schemes I examined have them.

I recall a lot of that was due to 3v<>5v magic