hip9011 - 3v to 5v level issues

[AndreyB]

The yellow trace seems odd to me. I see it's pulling down to about .1V which make sense as it should pull to near 0V when you start the integration period. However after the integration it's still very close to 0V.

Just noticed that the yellow probe is switched to X10 mode.

Also note that I am measuring voltage after a 1/2 voltage divider.

[kb1gtt]

I kind of wonder if that was the case. Also note that the quad allows you to specify it's a 10X probe which is safer against higher voltages. If you set the quad to 10X and the probe to 10X you'll get a proper measurement on the screen.

Can you capture the analog signal? Could it not be integrating because it sees no signal?

[Spilly]

I recommend changing the values of R1 and R2 such that R1 is greater than 25k. It appears very little if any gain is required. Perhaps changing to a unity gain is worthwhile.

Also, knock input components R1, R2, and C create a highpass filter.
fc = 1 / (2Pi * R1 * C)

I recommend you change the 47n capacitor to a value at least an order of magnitude lower if not more. A cutoff frequency (fc) between 1k-3k Hz should be sufficient.

I am changing my personal board values to:
R1 = 25k
R2 = 25k
C = 3.3n

I'm assuming that the output of the TPIC/HIP is being fed into one of the buffered ADC inputs. If that is correct, the voltage divider on the TPIC/HIP output should be bypassed/removed.

[AndreyB]

I recommend changing the values of R1 and R2 such that R1 is greater than 25k. It appears very little if any gain is required. Perhaps changing to a unity gain is worthwhile.

Also, knock input components R1, R2, and C create a lowpass filter.
fc = 1 / (2Pi * R1 * C)

I recommend you change the 47n capacitor to a value at least an order of magnitude lower if not more. A cutoff frequency (fc) between 1k-3k Hz should be sufficient.

I've already removed the pull-down resistor and changed both gain resistors to 100K a while ago. I believe I still have the 47n capacitor, what value would you suggest in case of R164 and R167 both at 100K?

The analog output goes right into stm32 so the divider is needed.

Some more random videos, the probe is now in X1 mode:

[video][/video]

[video][/video]

[Spilly]

I've already removed the pull-down resistor and changed both gain resistors to 100K a while ago. I believe I still have the 47n capacitor, what value would you suggest in case of R164 and R167 both at 100K?

Yes, I forgot to mention the pull-down resistor. That should be removed.

A capacitor between 1.8n to .56n will work with 100k resistors. The smaller the capacitance the higher the cutoff frequency.

[kb1gtt]

I believe Rin to be a high pass filter, certainly it's blocking DC and I would expect a larger cap would let in more energy from the lower frequencies. Although with the op-amp input being held at 2.5V instead of being a resistor to GND or something like that, I'm not exactly sure what I should I should expect from that input. I know the datasheet suggests 3.3nF so I would suggest using 3.3nF.

It's kind of annoying how the datasheet notes Rin which is also called R1.

I see from the eval board found here http://www.intersil.com/content/dam/Intersil/documents/an97/an9770.pdf

It uses .1uF with 10k and 20k resistors. I also see on page 4 that it notes a much steeper roll off than I had expected. It appears that if you don't have this closely tuned it will filter out all of the knock signal.

I wonder if you can create a knock and record it with your PC or cell phone or what ever, then we can try to identify what frequency you are dealing with. It's possible that your programmable filter is simply chopping off the noise that's being heard.

[kb1gtt]

Can you solder in a wire on the pads connected to pin 19 then see if the quad shows any signal making it to the chips input? That would let us know if the components are almost working.

[AndreyB]

A capacitor between 1.8n to .56n will work with 100k resistors. The smaller the capacitance the higher the cutoff frequency.

I've installed 1nF but this has affected exactly nothing

I guess a wire to pin 19 is my next step.

[Spilly]

I have finally managed to replicate the output of the TPIC being constantly high. The procedure for doing so was to force the integrator time constant to the smallest value (40) and then setting a simulated RPM of 1000.

Testing indicates that the default integrator time constant that is set after power cycling the TPIC is 40 microseconds.

It seems that your TPIC/HIP may not be having its time constant updated. A possible cause for this is the SPI bus is not communicating properly with the TPIC/HIP.

Please try applying this patch.



Once the patch is applied, send command "hipinfo" from the console. The response "spi= IntHold@PB11 response count=3" response count will equal 3 if the SPI bus is functioning properly. If response count equals 0, the SPI bus is not functioning properly.

[Spilly]

I believe Rin to be a high pass filter, certainly it's blocking DC and I would expect a larger cap would let in more energy from the lower frequencies. Although with the op-amp input being held at 2.5V instead of being a resistor to GND or something like that, I'm not exactly sure what I should I should expect from that input. I know the datasheet suggests 3.3nF so I would suggest using 3.3nF.

I just saw my typo above (originally stated lowpass filter but meant highpass). That is definitely a highpass filter.

I did a small amount of testing with the following:
R1 = 27k
R2 = 27k
C = 3.3nf

The cutoff frequency was around 1500-1800 Hz (calculated cutoff frequency is approximately 1786 Hz).

Also, the majority of the non-resonant (flat response) sensors output around 20-30 mV/g.

It appears that if you don't have this closely tuned it will filter out all of the knock signal.

I wonder if you can create a knock and record it with your PC or cell phone or what ever, then we can try to identify what frequency you are dealing with. It's possible that your programmable filter is simply chopping off the noise that's being heard.

The formula for calculating that frequency is 900 / (0.5 * Pi * bore diameter). I'm not sure where this formula was derived, but the general consensus is that it gets you close.

If the signals from the knock sensor were being "chopped off" the output of the TPIC/HIP would be close to 0. Also, the digital filter on the TPIC/HIP does not have a very sharp rolloff.

[AndreyB]

Once the patch is applied, send command "hipinfo" from the console. The response "spi= IntHold@PB11 response count=3" response count will equal 3 if the SPI bus is functioning properly. If response count equals 0, the SPI bus is not functioning properly.

patch committed.

2015-07-07 19_29: EngineState: spi= IntHold@PB11 response count=3

also I can definitely see how set_gain X command changed the slope of the output signal on the bench - this tells me that SPI is somewhat functional. I am also playing with 'integration end' parameter and I see slope change between 'set_float 1544 100' and 'set_float 1544 400'. To me it looks like the chip does receive at least some parameters at least on the bench. I hope that the same board would work same on the bench and in the car.

[Spilly]

2015-07-07 19_29: EngineState: spi= IntHold@PB11 response count=3

also I can definitely see how set_gain X command changed the slope of the output signal on the bench - this tells me that SPI is somewhat functional. I am also playing with 'integration end' parameter and I see slope change between 'set_float 1544 100' and 'set_float 1544 400'. To me it looks like the chip does receive at least some parameters at least on the bench. I hope that the same board would work same on the bench and in the car.

That certainly eliminates the possibility of the SPI bus being the problem.

I have tested IRL a different type of knock sensor (resonant) and I have real world recordings of a knock sensor (non-resonant), similar to your knock sensor, knocking. I have been unable to replicate your results.

Would it be possible for you to record your knock sensor output with an audio recording device (laptop/computer mic input and audacity) while the engine is running? If you have a spare op-amp, it would probably be a good idea to use a op-amp configured as a buffer to protect the recording device's input. Let me know if you need help setting this up.


Also, R170, R173, and R174 are not necessary. However, I doubt removing those resistors will resolve your issue.

[AndreyB]

I am lazy so I've just recorded the audio directly, without an op-amp. One file is the only knock sensor (input wire cut from ECU), the other file is pin #19 of hip chip - that's after the filter and gain resistors.

Both files start with some idle and then I rev a little. Here's the file: http://rusefi.com/images/knock_sensor.zip

Actually on a bench I see a not-so-high output if I play this sound, and the integration start is very visible. I know phases could be off between recorded signal and my simulated 1200 rpm, but at least I see integration start on the bench. So, what's different between car and recorded sound, same ECU board?

PS: I've forgotten to record not running car. Do I need to? I can do that tomorrow.

[Spilly]

One file is the only knock sensor (input wire cut from ECU), the other file is pin #19 of hip chip - that's after the filter and gain resistors.

Where was the ground of the recording device connected?

Actually on a bench I see a not-so-high output if I play this sound, and the integration start is very visible. I know phases could be off between recorded signal and my simulated 1200 rpm, but at least I see integration start on the bench. So, what's different between car and recorded sound, same ECU board?

Even when increasing the gain to silly levels, I too see the output line change when integrating.

Off the top of my head, a few differences between bench and on car testing are driving inductive loads and the power supply.

Can you remove R175, connect the ECU to the car, and measure across R176 while the car is running? I want to verify that the constant output is indeed the TPIC.

Are you using a TPIC or a HIP?

PS: I've forgotten to record not running car. Do I need to? I can do that tomorrow.

I don't think recording while not running will provide much insight into the issue.

[AndreyB]

Where was the ground of the recording device connected?

Audio cable going into the laptop has two wires. One wire is connected to one side of the knock sensor, the other wire - GND I believe - is connected to the other knock sensor wire, which is also connected to my ECU gnd which is also connected to the car GND. So ECU, car, sensor and audio cable all share same GND. Laptop runs on battery

Are you using a TPIC or a HIP?

I have TPIC, I am not sure if you can even buy HIP anywhere.

[Spilly]

It sounds like we need to focus on the differences between the car and the bench. Can you disable your fuel pump, drain your fuel rail, put the ECU into self-stimulation mode, and check the output of the TPIC while connected to the car? If the output is still constantly high, try disconnecting the inductive loads (injectors, ignition, etc.).

[Spilly]

Here's something a little bit easier to test. Apply this patch so we can verify that the TPIC is still responding while the car is running.

[AndreyB]

I believe I've reproduced the issue on a bench! It's about how I power the board and it's something about SPI.

Test #1: power the board with 5v via USB
1) turn board on - high TPIC output on start
2) enable self-self_stimulation - TPIC output goes LOW
hipinfo: response count=3 incorrect response=0

Test #2: power the board with 12v coming from an old PC power supply
1) turn board on - high TPIC output on start
2) enable self_stimulation - TPIC output stays HIGH
hipinfo: response count=0 incorrect response=3

[kb1gtt]

5v USB after blocking diodes, connector drops, wire drops, and such is probably close to 4V on the 5V rails. However the 12V is going to be 5V on the rails. I would expect the Vref/Vmid pin would change from 2.5V to 2V. This reference signal is put on the input op-amp, which would change it's reference level. I don't see how that changes anything, but it is likely a change. Perhaps out is also higher. Perhaps it's 4V on USB and 5V when powered by 12V. The ADC is 3.3V so perhaps the increased voltage is causing problems. I know we have the divider, so we should be good. However it also should be working.

Can you measure your 5V when on USB and when on 12V?

[AndreyB]

USB power: 4.4v gets to hip/tpic, works
external 5v power supply power: 4.8v gets to to hip/tpic, works
external 12 power supply: 5.0v gets to the hip/tpic, no SPI responses

let me remove some of these pull-ups just to try something

[kb1gtt]

Why do we have any of those pull up resistors? I see the TPIC and HIP have internal 30k pull ups. The 1k pull up is probably to much current for the TPIC to work with. I would suggest removing R170 to R174.

[kb1gtt]

Oh wait, int/hold has a 20k pull down, not pull up. The need for R170 will be determined by the STM. If the STM drives high, it has to provide some small current which I'm sure it can provide. However if that pin can't drive high for some reason, then you would need R170 to pull high and the STM would then have to pull low. However I believe the STM can drive high, so I would suggest remove R170 and drive it both high and low with the STM.

[Spilly]

Oh wait, int/hold has a 20k pull down, not pull up. The need for R170 will be determined by the STM. If the STM drives high, it has to provide some small current which I'm sure it can provide. However if that pin can't drive high for some reason, then you would need R170 to pull high and the STM would then have to pull low. However I believe the STM can drive high, so I would suggest remove R170 and drive it both high and low with the STM.

According to table 12 of the stm32F407xx http://www.st.com/web/en/resource/technical/document/datasheet/DM00037051.pdf the pins can sink and source 25mA. Also, tables 6 and 7 indicate that the I/O the TPIC is connected to are 5V tolerant. Thus, R170, R171, R172, R173, and R174 are not needed.

Edit: TEST has an internal pullup.

[Spilly]

Does spilly confirm the issue with 5V vs 4.8V on the 5V supply.

For russian, can you capture a valid packet when powered via USB then turn on the external 12V to get 5.0V on the SPI lines then capture the same packet with the same wiring.

I'll call russian this evening and see if we can look at this in analog land. I know these logic analyzers will trip at around 1.8V, perhaps the failure is because the LA claimed packets aren't a high enough voltage for the TPIC to register as a high or something like that. It's common that rounding of the square wave can also cause problems not seen on the LA. We man have a problem that would be more obvious in analog land instead of the digital land.

High-level input voltage INT/HOLD, VIH CS, TEST, SDI, SCLK 70% of VDD

70% of 4.8V is approx. 3.36V
70% of 5V is approx. 3.5V

Just killed a TPIC trying to test various voltage levels. Fortunately, I do have one TPIC left.

[AndreyB]

@:

I finally have it figured out. The logic level thresholds are dependent on the voltage input to the TPIC. At 4.8-4.9V the TPIC works as expected. At 5V or above it does not.

As a dirty temporary fix, I am powering TPIC with 4.6v and things are looking good! I will now go try this on the real car.

[kb1gtt]

@russian, with the quad, can you get any capture of the SPI signals? Look to see if we are driving to 3.3 or 5V. I suspect we are driving to 3.3V not 5V. If the STM is driving 3.3V and the TPIC threshold is 3.36, it will probably work. Then if the TPIC's threshold is 3.5V (like when using the 5.0V supply) it will probably not be good enough. Take note that the LA will trigger at around 1.8V while the TPIC is triggering at around 3.3 to 3.5V. So what you see on the LA is not what the TPIC is seeing.

I suspect we need something like this https://www.sparkfun.com/products/12009, but perhaps we can get by by making R171, R173 and R174 a 10k to 40k pull up resistor.

[AndreyB]

pb13_sck.BMP

pb14_miso.BMP

pb15_mosi.BMP

pd0_cs.BMP

[kb1gtt]

I'm confused, I see some show above 5V which I know is not correct, then I see others are close to 3.3 which I do expect. I suspect there is a 10X probe issue. Can you get a capture of the DC 5V, then a picture with the same setting for the SPI data? This will let me see where 5V then we'll know how the SPI compares to 5V.

Any how, it appears the issue is that the STM is driving to 3.3V not 5V, which is at the very edge of the TPIC's threshold. We need to drive the TPIC with 5V some how.

[Spilly]

EDIT: Issue has been fixed in software. No modifications to hardware are required

The issue has finally revealed it self.

High-level input voltage INT/HOLD, VIH CS, TEST, SDI, SCLK 70% of VDD

When the board is powered via USB, VDD is 4.8V (USB can be higher but mine was 4.8V) minus the forward voltage drop (most likely between 0.3-0.6V) of D1 BAT60JFILM on the Discovery board. This means the TPIC requires a minimum input of 2.94-3.15V for a logic high. Under this condition the TPIC responds correctly to input from the STM32.

When the board is powered via 12V, VDD is 5V. This means the TPIC requires a minimum input of 3.5V. Under this condition the TPIC does not respond to input from the STM32.

Obviously increasing VDD a few hundred millivolts is preventing the TPIC from reading input from the STM32.

After looking over the PCB and schematic, I believe the best workaround for current boards is to jumper D3 (BAT60JFILM) on the Discovery board and install a diode (ex: 1N4001) between the 5V rail and TPIC VDD. This will bring the bring the 3V rail up to 3.3V and lower VDD to 4.5-4.7V (depends on forward voltage drop across diode). In order to do this I recommend following the modifications in the picture. Removing C165 is not necessary, but it may make the modification a bit easier.

I am working on a more permanent fix for future boards.

[Spilly]

I'm confused, I see some show above 5V which I know is not correct, then I see others are close to 3.3 which I do expect.

I'm sure it's a calibration issue. The DSO quad isn't the most accurate device for precise voltage measurements. However, in my experience relative measurements are sufficient.