Just bringing this over. I know the talk of pulse damping is off topic to begin with here, but it's where the discussion is.

The 3% mentioned matches right up with what I was saying. Believe it or not, 11.24:1 to 10.77:1 is 3% each direction, so 6% total. That included some extra to deal with signal aliasing though. It also falls in line with what I was saying about being able to measure it, but it may not have a real world effect.

For now, I'd say it's still plausible that it could be a concern and would be worth investigating.

David, where are you measuring fuel pressure from?
If you want to verify it, there are couple important issues to keep in mind.

1. The fuel pressure needs to be taken at the rail. Not off a line, as the line will help dampen out the pulses.
2. This is the same for MAP. If you have a line with the sensor mounted off the plenum, you will get some additional damping. I know the AEM is typically ran this way because direct mounts tend to cause problems with how the ECU runs.
3. Sample rate, crank it up as high as possible.
4. Resolution, I don't know if you can change the resolution on the AEM, but for comparison sake, it would be like logging a 2-Byte variable on the stock ECU vs. 1-Byte. The 2-Byte provides a more accurate measurement and will catch smaller pressure variances.
5. Sensor response, some sensors are VERY slow to respond. They have a large diaphragm that is slow to react to pressure changes. This in effect knocks down the amplitude of the peaks and valleys. A MEMS based sensor will provide much quicker response and are still very durable.

 

1. I am measuring fuel pressure on the far side of the rail by the regulator.
2. The MAP sensor at the time of testing was mounted on the intake, now on an aeroquip line, not flimsy hose.
3. Sample rate that I stated earlier is the quickest it can go.
4. As far as I know the AEM's resolution is matched to the logging rate, which is as high as it goes on my car.
5. The sensor is the AEM pressure sensor, built by Kalvico I believe.

 

Like you said, next test would just be unfiltered MAP vs fuel pressure and see what it says.

Interesting topic to probably 3 people on this board...

Ok, now this is pretty bad ***.

http://www.kavlico.com/catalog/fuel_...egory=pressure

From the looks of it, the O-ring's end mounts directly on the fuel rail. The nipple goes to the intake plenum. This sensor measures the differential pressure between the two directly.

You take that sensor and use it for a fuel comp table that automatically accounts for fuel pressure changes (fuel pumps run out, FPR reference line leaks/blows off) and also provides a means to have an alarm. BAD ***

 

Yes, I will do more logging when the car is back on the dyno. Maybe next week. I have to finish Jeff's car first, top priority. Then my car will be 100% on my list only.

 

I think jeff is plenty fast, he can wait

 

Ok, I went damn geeked out to demonstrate what is being talked about here and the importance of proper signal acquisition.

I opened up Simulink in Matlab to do a quick system model. This simulation is more about frequency response than actual amplitude accuracy.

Operating Conditions:
Engine Speed: 7000 RPM
Injector Pulsewidth: 13ms

This first graph would be comparable to a transitional state. Going from say fuel cut to WOT and full boost at 7000 RPM instantly. Not realistic, but it demonstrates some very important physical characteristics of the system.



First off, the blue line. This would be representative of "injector demand". At 7000 RPM and 13ms, there is always 2 injectors open at all times. There is an overlap time when all 4 injectors are open though, and this is where the signal goes to -4.

Next up, the red line. This is the same signal but with a first order filter applied. This is just a rough idea here and it's meant to simulate the damping caused by the fuel rail. I've made it a very fast filter which would be similar to the rail having very low volume and minimal damping. This is where something like a fuel pulse damper would come in.

Now the green line is the output of the pressure transducer. Notice at the left side of the graph how it dramatically lags behind the actual signal. This is representative of a pressure sensor with a 15ms response time. This is the response time of the AEM sensor. On the right end of the graph, the system has reached more steady state. It is important to note that the because of the response characteristics that even though rail pressure is oscillating 2 full units, the actual sensor signal is only oscillating about 0.3 units. This would be similar to the fuel pressure oscillating 10 PSI and measuring 3 psi...

Now, the purple line. This is what you would see on the data logger with 200HZ sample rate. Notice that it doesn't characterize the pressure osculations all that well because the sample rate is not high enough to catch 2 samples for every osculation. In some cases, it is in phase and close to actual max/min, in others, it is completely out of phase. This is signal aliasing. If you wanted to see what was happening at 9000 RPM some what accurately, you'd need to sample at 600Hz and have a sensor that had a response time of about 1ms.

If you are interested on why the sample rate needs to be at least 2 times greater than the frequency of interest, look up Nyquist frequency.

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

Here is the same chart but zoomed in on the "steady state" part to see more closely what is happening.


Just so everybody knows, I'm not trying to pick a fight or prove anybody wrong. I'm simply explaining a pretty technical aspect of signal acquisitions and trying to relate it to the automotive world.

 

More Geek

Here is a chart of how fuel pulse damping would affect the system.
This would be the actual rail pressure.


This is what you would measure at 200Hz with a pressure sensor with 15ms response time.


As you can see, towards the right of this graph, you don't really see any improvement in the signal until the 20X more damping. Even then, it's still likely to catch peak every now and then that would say the pressure pulse is still high. With 20X the damping though, the oscillation amplitude is cut down about 5 times more than the minimally damped rail.

 

I wish I could understand what your saying better... nevertheless, let me ask some dumb questions. I understand that in your graph, the pressure sensor has a response time of 15 ms, or .015 of a second. So it is always reading what happened from a moment ago. But where I'm confused, is why the signal that the pressure sensor is reading is a square wave. Wouldn't there likely be all kinds of pressure waves in the rail, and therefore the sum of those waves would not likely look like a sin or square wave?

 

Thanks for posting that, if nothing else it is intersting reading and breaks down the possibilities more.

Let me ask you something though. Even with slower logging/data gathering, if there were larger spikes/valleys in pressure shouldn't it show up somewhere across the log? I mean even a a fluke that it all caught it on time it would seem you'd be likely to see atleast one random high or low area at some point during multiple datalogs, right?

 

Exactly what I was thinking. Why can't a sensor pick up some of those spikes or dips now and again?

Maybe it has something to do with how the pressure sensor works... I dunno.

 

Nope. Response time isn't a time delay. It is the amount of time it takes the sensor to go from one output level to another when simulated with a step response. The way the pressure sensor response time is measured is something like so:
Apply a step in the pressure from 0 to full scale "instantly"
Record the sensor output voltage
The response time is the amount of time it took to go from 0 to 63% of the applied pressure. The pressure sensor will not actually measure the full scale pressure until 5 times the response time.

So for the 125psi sensor with a 15ms response time, if you went from 0-psi to 125 psi, it would take 75ms before the output was within 99% of 125psi.

Anyway, the important thing here is that the sensor doesn't have a time delay. It's not 15ms behind the signal. It is changing in phase with the signal, it just isn't changing as fast as the signal.


The actual square wave would be analogous to the injector signal. Injectors are on-off devices and so you control them with a square wave and vary the frequency (RPM) and duty cycle.

The sensor isn't actually measuring the square wave though. It is measuring off of the "Actual Pressure" which has it's own response time. This would be analogous to how the injector responds. Think "Dead time" here.

If you look at injector phasing, you'll see that the summation of all 4 injector signals produces a square wave like I have shown. At 7000 RPM and 13ms pulse width, there is over lap where 2 injectors are always open at the same time. Not the same two, but two are always open. On a 4cylinder, the injectors fire 180 degrees apart. The signal gets repeated every 360 degrees...

I should say something here though for those that understand system response so you don't come rip me a new one. I'm making this a VERY simple model intentionally. I'm not trying to accurately predict anything, so I am only using 1st order response characteristics. I feel this is reasonable though because I'm mostly interested in the dominate system characteristics and am trying to show how signal aliasing and sensor response can be VERY important in signal acquisition.


The best you can do is catch a peak of the sensor response. Which actually, if you look at the first graph I posted, it managed to catch a peak and valley. 4th peak from the right, green signal and purple signal. It should be noted that the green signal output is 1/8th of the actual signal amplitude. Yes, you will catch a peak and valley at some point and it will show you the maximum response of the sensor. But with a slow sensor, if you do have large pressure fluctuations, you'll NEVER catch them because the sensor never reads it.

Yes, it has everything to do with how the sensor works. Think of a drum head. That's basically all a pressure sensor is. It might have a strain gauge or a capacitance sensor on it, but it's a drum head. It has mass, it has elasticity, it has resistance. It's a 2nd order system.

If you "hit" that drum head with a pressure wave, it doesn't instantly jump to the deflection associated with that pressure because it has to accelerate the mass of the drum head. If it did it instantly, you'd be breaking very important laws of physics. It is not a delay though. You hit a drum head with a drum stick, it moves as soon as you hit it, but it resists the motion of the drum stick. That's the response time working.

Now, to go even more geeky.

A first order system will never over shoot or oscillate after you apply the stimulus. It just reacts and eventually goes to the final value. A 2nd order system on the other hand can overshoot, oscillate, etc. For the same reason it resist moving in the first place (inertia) it wants to keep going even after it's passed by the stimulus value. Back to the drum. You hit it and it keeps making noise long after the intial hit. Same thing happens with a pressure sensor. I'm neglecting this though as that's not the dominate characteristic in this case because it can't even react quick enough in the first place to reach the final value, much less over shoot it.

The one thing about second order systems though, they can become "unstable" and hit resonance or have a HUGE phase shift to the actual signal. It's very possible for the sensor to get 180 degrees out of phase with the actual response. This would mean the pressure would be going up, but the sensor was "delayed" and was reading the last valley, saying the pressure is actually going down.

 

That makes sense...

So... let us say there are pressure waves in the fuel rail which we want to observe accurately, or at least very close to accurate. And the frequency of those pressure waves is, for example, 10 waves per second.

And if we take your fact, that a typical pressure sensor might have a response time of 15ms, and that it takes the sensor that time to read 63% of the applied signal.

And if the waves are 10 per second, that means the duration of a peak or valley is half that, so .05 seconds. And 15ms is .015 of a second.

So in this case, of 10 hz, or 10 pressure waves per second, the 15ms response is more than enough to very accurately log what is happening, because the duration of a peak or valley is over 3 times the response time. This means what you are logging will be very close to the real value.

But the problem is, at 7000 rpm, you get 116 revs per second, or .009 of a second per rev. And if we assume the biggest pressure wave is created from the overlap when all 4 injectors fire, that happens once per rev, so we need a sensor with a response time much better than .009 of a second? So probably a sensor with a response time of like 3 or 4 ms would be needed?

 

If I were doing this measruement and wanted accurate results for development purposes, I'd use a sensor that had considerably better response (<0.5ms) and I'd data log it at considerably higher speeds (>1000Hz).

But, this looks like a sensor that could directly replace what David is using and has <2ms response time. Same wiring and scaling.

http://www.kavlico.com/_assets/pdf/P500DS.pdf

 

Thanks for your explanations. While a lot of it was over my head, you definitely helped me understand this notion of a sensors response time.

 

Yes, 03white, thanks for the input, I appreciate the time and such.

The reason I was logging the fuel pressure in the car, for reference, was just to be sure there were no oddities going on. I wanted to make sure there were no big spikes in the pressure when the second pump came on and that the pumps were holding fuel pressure at high RPM. I confirmed both were in good shape from the logs.