Page 2 of 3

Re: MAP but not SD as intermediate solution?

Posted: Fri May 30, 2014 11:17 am
by AndreyB
Nobody wrote:Image
Even numbers are tempting, but that causes the off 20x19 size. Nothing wrong with that on the other side.
I will probably interpolate this table into the 16x16

Re: MAP but not SD as intermediate solution?

Posted: Fri May 30, 2014 5:50 pm
by Nobody
Couple things need to be considered at this point. What is realistic end user of this system going to use it for?

Why did I ask that? Well I’m back to fuel injectors… Most systems today (~2000+ model year) are returnless fuel systems in which fuel pressure regulator is in gas tank and you have single line going to fuel rails.

So since we touched upon boosted applications (FI) you have to look at what that does to fuel mass flow with varying pressure differential (inlet to outlet). Most systems are 3 bar with some at 4 bar.

The only time a injector actual flows as an example 32 lb/hour is at WOT or engine not running, when you are in vacuum it flows more because deltaP (pressure differential) is higher, then say at 1 bar (14.5 psi) boost, the deltaP is smaller so less flow.

So look at this way, your pump puts outs 3 bar of fuel pressure;
* 50 kPa (MAP - absolute) that is 3.5 bar of fuel pressure into intake manifold (it is under vacuum).
* 100 kPa (MAP - absolute) that is 3 bar of fuel pressure into intake manifold (WOT near see level or engine not running).
* 200 kPa (MAP - absolute) that is 2 bar of fuel pressure into intake manifold (it is under boost/pressure).

Bernoulli’s principal says flow vs pressure is;
* New flow = Base Flow * SQRT(new pressure / base pressure)

You can do the math to see how much flow changes in above example… Oh, this is why pure MAF cars also have MAP sensor, it is fuel mass flow correction.

So why did I bring this up? Unless you want to calculated Actual IFR (injector flow rate) on the fly, you will need a table that matches your VE table max MAP.

EDIT - fixed typos.

Re: MAP but not SD as intermediate solution?

Posted: Fri May 30, 2014 6:13 pm
by AndreyB
@ I have to say I really appreciate your detailed posts.

For current iteration I guess we are targeting slightly older vehicles with regular return lines, if I understand you correctly for these we would simply use IFR. On the other hand, again, if I understand you correctly, in order to transition to returnless fuel systems we would just change this part of the equation.

How do existing systems address this? Do they have a configuration option where you need to specify if your are using returnless fuel system or not?

BTW I've started the SD implementation yesterday - see speed_density.cpp

Re: MAP but not SD as intermediate solution?

Posted: Fri May 30, 2014 7:20 pm
by Nobody
The simplest way to deal with return and returnless fuel systems is to add a table that defines injector mass flow vs MAP. For return type systems (must be intake manifold referenced) you simply use the same value all the way across (123, 123, 123… in table). Now for returnless you can use manufacturer data for flow vs MAP or perform appropriate calculations. NOTE Bernoulli equation gets you close but not perfect, it does not take into account pressure drop across injector vs fuel velocity.

This is how the OEMs, even say a Ferrari does it.

Re: MAP but not SD as intermediate solution?

Posted: Fri May 30, 2014 7:40 pm
by AndreyB
Gotcha. So, just a curve by MAP. I will implement it as a multiplier and just set it to '1' by default.

Re: MAP but not SD as intermediate solution?

Posted: Fri May 30, 2014 8:07 pm
by kb1gtt
It's very common that the fuel regulator is connected to the manifold pressure, such that the regulator tracks the manifold pressure. If you are at 5psia, your fuel pressure would be something like 50psia a difference of 45psi. Then if your manifold pressure is at 10psia, the regulator is supposed to adjust the fuel pressure to 55psia, such that the differential pressure remains 45psi. Or at least that's how the little hose off the top of your rail regulator is supposed to work. I tend to feel that's not not exactly what really happens, and I feel there are many dynamic issues with that kind of system. Any how, point being that the differential fuel pressure across the injector, for most engines is supposed to be reasonably consistent.

Re: MAP but not SD as intermediate solution?

Posted: Sat May 31, 2014 5:29 am
by UnaClocker
kb1gtt wrote:It's very common that the fuel regulator is connected to the manifold pressure, such that the regulator tracks the manifold pressure. If you are at 5psia, your fuel pressure would be something like 50psia a difference of 45psi. Then if your manifold pressure is at 10psia, the regulator is supposed to adjust the fuel pressure to 55psia, such that the differential pressure remains 45psi. Or at least that's how the little hose off the top of your rail regulator is supposed to work. I tend to feel that's not not exactly what really happens, and I feel there are many dynamic issues with that kind of system. Any how, point being that the differential fuel pressure across the injector, for most engines is supposed to be reasonably consistent.
Yes, that's how it used to work. Nowadays, as Nobody was saying, cars have gone to returnless fuel systems. The pressure regulator is in the tank, one line comes out of the tank. The fuel pressure is static. It must be beneficial for emissions in some way. Dodge started using it on the Neons in '95.. It's been around awhile, that's a nearly 20 year old car at this point.

Re: MAP but not SD as intermediate solution?

Posted: Sat May 31, 2014 8:04 am
by Nobody
Gotcha. So, just a curve by MAP. I will implement it as a multiplier and just set it to '1' by default.
I’d suggest you use proposed table to calculate actual IFR (injector flow rate) used in S/D or MAF equations. The longer you stay in actual engineering units the better, because a multiplier followed by more multipliers makes it difficult to see where things are not solving as expected or what is causing tune/calibration to be off.

Oh, I would think by now it’s becoming apparent why S/D (speed density) is generally preferred, because without MAP vs IFR correction you can still get it to run - VE table would look odd, but on MAF side it would not run worth a cr@p (returnless fuel system).

Re: MAP but not SD as intermediate solution?

Posted: Sun Jun 01, 2014 8:58 am
by kb1gtt
It's my understanding that MAF is often preferred by OEM's and "normal" performance engines. The MAF directly correlates to 02 in the cyl, which makes the math very easy, as you don't need to tune for a new engine. For example, an OEM designs one ECU and uses that for several vehicles and uses that for several design cycles. You can change cam's, intake plumbing, ect and as long as the MAF is still working correctly, you can change just about anything with the engine. However to make the MAF work correctly you generally need a very large intake as it helps keep turbulent flow to a minimal. As well heavy valve overlap needs to be dampened such that a reverse pulse of air away from the engine doesn't falsely register an increased air flow. Hence those little cavities that you see on OEM engines. These cavities and large intake plumbing are often a negative to a performance application. If you have a 200HP engine with a 4 inch intake, and you double it's power, you need about 6 inch intake to be a near equivalent in terms of probability of turbulent flow vs laminar flow. If you are boosting to say 12PSI, that clamp is going to need to support 340 lbs of axial force. The problems can start to be come a problem as you are approaching welding you plumbing instead of clamping, ect.

With MAP, it's a bit more labor intensive from the development and tuning side, as any change to your intake plumbing, changing cams, ect requires a re-tune of the VE tables. Basically your engine is an air pump and your VE will be dependent on a great many factors. However VE is less dependent on turbulent vs laminar flow issues, so you don't need to be as concerned with resonant cavities, over-sized plumbing, or other air flow issues. You simply slap it all together and tune it. So if you have an existing 4 inch intake, you can simply cram more air through it and still get reasonably accurate predictions of how much O2 is in the cyl. MAP for low flow situations is a bit less accurate, so your fuel consumption at idle is often a bit off. OEM's don't like at as they are emissions controlled.

Some OEM's use both MAP and MAF switching between both systems. Basically at full load, they use the MAP, then at idle they use MAF. However once you start adding MAP, you start to increase the labor required for the development cycle, as well you add cost to the build. So often OEM's do not like this approach and go MAF only.

Re: MAP but not SD as intermediate solution?

Posted: Mon Jun 02, 2014 12:36 am
by Nobody
Image

Most MAFs have a curve that strongly resembles above, far from linear. So unless you know curve ahead of time, solving for it on engine is not fun. I've had to get S/D tune nailed down before working on MAF characterization.

My fun car is blended S/D and MAF up to about 1500 RPM, after that MAF, then after 3000 it's S/D (open loop) - that's the way I setup tune/calibration.

One thing I have not seen mentioned here is, how it's intended to deal with higher loads? You can't have 14.7 or 14.6 (E10) AFR, more like 12.5ish at wide open throttle (engine dependent). FI is 11.5ish...

Also some food for thought... About 9 years ago things like this started to appear:
* Virtual VE = K1*MAP² + K2*MAP + K3*MAP*RPM + K4*RPM + K5*RPM² + K6
* K1 - K6 are curve fitting coefficients :)
* Seems OEMs wanted better than a standard VE table. So now we have model based engine control, with VE still in use but considerably more precise.

Oh, I'm pushing 10+ psi of boost through a 3.5 inch tube with silicone couplers and constant tension hose clamps, as long is it has a bead to keep it from slipping off, no need to weld anything. 30+ psi is not an issue for hose clamps.

EDIT -

I am not against MAF, far from it, but know what it takes to get it running correctly. Even though it doesn't look like it, S/D is the most forgiving because you can bandaid allot in the table. If you have no means by which to enrich AFR for higher loads or WOT (wide open throttle) you just put in a artificially high VE number (sometimes above 100%).

Another thing to consider is you can have xx mass flow at 3000 RPM and same mass flow at 7000 RPM, the required AFR will be different... :) Again, the MAF seems really simple, but it's not a straight calculation as I suspect is being expected. Lots of work is needed here, that I don't think it's even on the radar.

Re: MAP but not SD as intermediate solution?

Posted: Sat Jun 14, 2014 2:53 am
by AndreyB
Nobody wrote: Speed Density in its simplest terms…
IPW = (Vol * VE * MAP) / (AFR * IFR * R * Temp)
* IPW is injector pulse width
* Vol is engine volume
* VE is volumetric efficiency i.e. 0.8 (for 80%)
* MAP is manifold absolute pressure
* AFR is air fuel ratio
* IFR is injector flow rate
* R is gas constant 287.05 J/(KG*K)
* Temp is absolute temperature (ideally a blend between IAT and ECT).
Vol - liters. MAP - kPa. Temp - Kelvins
IFR? Cubic centimeter per minute?

Re: MAP but not SD as intermediate solution?

Posted: Sat Jun 14, 2014 9:48 am
by kb1gtt
I just added those acronyms to the wiki list. That list allows for link able explanations. For example,

The IPW is calculated based off the SD equation.

Here's the code that generated the above.

Code: Select all

The [url=http://rusefi.com/wiki/index.php?title=Engine:acronym-phrases#IPW]IPW[/url] is calculated based off the [url=http://rusefi.com/wiki/index.php?title=Engine:acronym-phrases#SD]SD[/url] equation.
Any how I just wanted to note that the linking thing is an option. I wonder if a script or something can run daily to modify and flag these kinds of acronyms. I know it's wrong to modify someone else's post, but acronym script modification might be a liked options by most. Or perhaps when you hit submit, perhaps it could make a suggested modified post before the post is completed. Any how, it's a thought and an option. Perhaps a bit OT, but eh, might as well post it somewhere.

Re: MAP but not SD as intermediate solution?

Posted: Sat Jun 14, 2014 9:29 pm
by Nobody
Sorry been busy… But answer is on page 3 where I said “Everything above is in metric (KG/sec, M^3…). Also R (gas constant) is for dry air and you’ll notice that newer cars now have humidity sensor built in!”

Gas constant has “standard day” humidity built into it, but still dry by comparison to Florida.

If you want to use liters and kPa, then need to convert to grams…

Re: MAP but not SD as intermediate solution?

Posted: Sat Jun 14, 2014 10:01 pm
by blundar
If you want a walkthrough/comparison of some common engine management systems and their (subjective) pluses and minuses, hit me up. I have (literally) hundreds if not thousands of datalogs and tunes from various real vehicles. Sometimes it's really handy to see some of the data analysis / mechanics / etc. involved in a tune setup. There are some really good ideas out there and not re-inventing the wheel is a good thing. Hit me up if you're interested.

Re: MAP but not SD as intermediate solution?

Posted: Sun Jun 15, 2014 4:45 am
by Nobody
Removed example...

Re: MAP but not SD as intermediate solution?

Posted: Mon Jun 16, 2014 1:43 am
by AndreyB
Nobody wrote:The result is 0.01414 sec or 14.14 ms.
Appreciate the example! Let me refactor the code so that I can write a unit test now.

Re: MAP but not SD as intermediate solution?

Posted: Thu Jun 26, 2014 3:05 pm
by AndreyB
Nobody wrote:A verified example is as follows.
Engine 7L (LS7 - 427)
IFR = 5.303 g/sec (42 lb/hr) each
R = 0.28705 J/g*K (we are now in grams)
Temp = 293.16 K (20C) - this needs to be blended…
MAP = 98 kPa
VE = 0.92 (92%)
AFR = 12.5 (engine is under heavy load)
The result is 0.01414 sec or 14.14 ms.
I've made a tiny bit of progress, the numbers did match up - see test_speed_density.cpp

Do I understand it right that I would also need VE(RPM, MAP) and AFR(RPM,MAP) tables to actually get the ve and atf values for current conditions? Would 8x8 be enough for any of these or do we need 16x16?

Re: MAP but not SD as intermediate solution?

Posted: Fri Jun 27, 2014 2:32 am
by UnaClocker
8x8 is "enough". Do 16x16.

Re: MAP but not SD as intermediate solution?

Posted: Thu Jul 03, 2014 2:30 am
by Nobody
russian wrote: I've made a tiny bit of progress, the numbers did match up - see test_speed_density.cpp

Do I understand it right that I would also need VE(RPM, MAP) and AFR(RPM,MAP) tables to actually get the ve and atf values for current conditions? Would 8x8 be enough for any of these or do we need 16x16?
It really depends on how you want to do closed loop - narrow or wideband O2.

Re: MAP but not SD as intermediate solution?

Posted: Thu Jul 03, 2014 10:07 am
by AndreyB
Nobody wrote:narrow or wideband O2.
I would guess we would eventually need both?

Re: MAP but not SD as intermediate solution?

Posted: Sun Jul 06, 2014 4:36 am
by Nobody
Keep in mind that how you deal with power enrichment, will to some extent be dictated by your tuning software. Software needs/should know what commanded AFR is in order to derive error.

Re: MAP but not SD as intermediate solution?

Posted: Mon Jul 14, 2014 2:24 am
by AndreyB
I think SD implementation is ready.

Re: MAP but not SD as intermediate solution?

Posted: Mon Jul 14, 2014 11:57 pm
by UnaClocker
WooHoo! I should conjur up something to wire my board to the engine in my PT Cruiser (Neon style trigger wheel on that motor). :)

Re: MAP but not SD as intermediate solution?

Posted: Mon Sep 01, 2014 5:18 am
by E4ODnut
Russian,
I have used SD with both a Haltech E6K and my current Megasquirt controllers. Both handle it in a similar fashion and both work very well for relatively stock multi cylinder engines. The difficulty arises when you have manifold pressure that is abnormally high at low speed low load on engines that have a lot of valve overlap and or multiple throttle bodies. Then there is the situation where the MAP signal is jumpy, in single, two, or possibly even three cylinder engines.

Now the problem becomes, how to get a reasonably accurate representation of actual manifold pressure under these conditions. The later versions of MS have an averaging feature for MAP as well as some other inputs that should help, but would possibly slow down the response time under changing conditions. Another possible way would be to sample MAP as many times as possible in one intake runner during the intake stroke on that cylinder and use the highest reading for the next cylinder in the firing order. I don't know how you take the MAP samples now but perhaps this could be discussed.

Re: MAP but not SD as intermediate solution?

Posted: Mon Sep 01, 2014 1:32 pm
by AndreyB
Right now I am taking MAP readings as fast as I can. I am ignoring them outside of the specified cam angle window, within the specified range of angles I am simply averaging it. I guess taking the maximum value could be a configurable option.

Re: MAP but not SD as intermediate solution?

Posted: Mon Sep 01, 2014 2:40 pm
by E4ODnut
How fast can you take them?
What MAP sensor are you using?
How fast can that sensor respond to changes?

Re: MAP but not SD as intermediate solution?

Posted: Mon Sep 01, 2014 4:01 pm
by kb1gtt
I seem to recall russian is using a an OEM MAP with unknown parameters. However the typical response time for similar sensors is 1mS.

Re: MAP but not SD as intermediate solution?

Posted: Mon Sep 01, 2014 6:01 pm
by E4ODnut
I had a look at the data sheets for the MPX4250 that I have been using and it states a response time of 1.0ms as well so it looks to me like there is not much point in sampling any faster than that.

I did some more digging and the consensus seems to be that if MAP is sampled at a specific crank angle, or within a range of angles, then the lowest MAP value should be used, not the highest as I had suggested. I'm not sure why this is preferred to an average value. The key seems to be that sampling should be taken at a specific crank angle, or range of angles that will vary depending on RPM.

Re: MAP but not SD as intermediate solution?

Posted: Mon Sep 01, 2014 8:21 pm
by AndreyB
E4ODnut wrote:range of angles that will vary depending on RPM.
yep, that's the way we do it - window start and window angle width are both curves by RPM. I guess I will make an option to use either avg, max or min just for fun :)

Re: MAP but not SD as intermediate solution?

Posted: Mon Sep 01, 2014 8:51 pm
by kb1gtt
The micromachined piezoresistive internals of the MPX41XX series and almost every major low cost MAP sensor will be right around that 1mS. You can get faster reaction times but it requires different more expensive technologies. Also don't mistake bandwidth for response time. Just because the physical mass takes 1mS to go to 90% accuracy doesn't mean there isn't good or valid data above that sample rate. Also don't forget about things like aliasing and such. I would suggest attempting to sample once ever .25mS then average of 4 samples. You'll need at least .5mS to obtain nyquist requirements. By planning for .25mS it allows some room for growth to extract some more data.

The min is usually used as it's more consistent for idle, which allows you to make a better prediction during idle and allows a better fuel delivery at idle. However when at WOT, you don't need to be very accurate. You generally tune to dump some extra fuel and call it good. However to much fuel with very little air like at idle means missed fires.