Re:Whittlebeast's RPMxMAP vs Duty function

[racingmini_mtl]

I can't even think what a "single 4-stroke in sequential mode" means. Sequence of one doesn't sound very hard! Anyhow, I'm not certain about sequential injection. I think it'll do something if this option is selected, but the decision process in the code leading up to it is fairly convoluted and it doesn't take much to confuse me.

For a single cylinder engine, I guess a better term would be timed injection since what happens is that you can control the injection timing of the single injection pulse. This can have a significant impact on some engines under some conditions.

And the sequential injection code is indeed convoluted but it does not have any impact on the pulse width computations. It just uses the pulse width to determine when the injection should start. Part of the complexity of the code comes from the need to deal with many corner cases such as collisions between successive pulses when the injection start goes back and forth across a tooth trigger. And it is also convoluted due to how it evolved from the initial way I implemented it and the desire and need to use common aspects with the rest of the code and the ignition timing code.

Jean

[robs]

Ah, right, that makes sense. Thanks.

I wasn't criticising the code; for all the things it's capable of doing, it seems no more complicated than it need be.

Have fun,

Rob.

[ol boy]

Put another 50 plus miles on it tonight. Still working good. Not sure why anyone would ever want to use a VE table again. The response seems quicker than a MAF set up and even easier to tune.

Tip in throttle is much better as the right PW is used, I can now see where my acceleration enrichment was covering up areas of the table that are hard to tune ie.. 1300rpm at 80% load. You tend to transition through that spot too quickly to get a good read on what's going on.

Just works. Need to go up and down some hills next to see how baro correction works.

Later Ryan

Sent from my SM-G920V using Tapatalk

[whittlebeast]

Glad to see you guys are having success.

Andy

[Dennis_Zx7r]

Condensed for dummies, is this kind of a simplified, easier to tune speed density for highly linear engines or am I missing the point?

[whittlebeast]

Unless you guy have confused me here, it appears you are going from MAPxRPM directly to VE. I have never been able to make that work. MAPxRPM is a far better predictor of DC. It is only fair at predicting VE. Here is data off my Motec but in the MS world, it is all the same thing, as far as I can tell.

http://www.nbs-stl.com/motec/MAPxRPM%20 ... d%20VE.png

Andy

[whittlebeast]

Dennis, correct. Good for stock intake motors that are non VVT. It does not work very well on ITB motors.

Andy

[ol boy]

From a what I've found.. MAF = map x rpm x (VE/100). PW = dead time +(req fuel × ve/100). Duty cycle = (PW x rpm)/1200. Moving the math around and using VE will get you to duty cycle.

Rob wanted to reuse the speed density math that all ready exist. He was able to keep the squirt and alter-sim functions without big changez to the known working code. Solving straight to duty cycle would kill the resolution. Duty cycle would be too course when using 16bit math.(That's what I gathered).

Others have noted you should have bands of like VE values that arc across your VE table that correlate to rpm x map. Low rpm and high load or high rpm and low load will net the same airflow and same VE value. Of course if your inj dead times are way off the table will have an odd shape with extremely large values near the bottom(dead time too low). Once dead times are sorted the table becomes very flat and you begin to see the VE values and how they arc across the table.

Sent from my SM-G920V using Tapatalk

[racingmini_mtl]

I wasn't criticising the code; for all the things it's capable of doing, it seems no more complicated than it need be.

No problem, I wasn't seeing that as criticism but simply as a valid observation. Even I need to spend some time re-reading it to understand what I did if I need to go back to it and check something.

Jean

[robs]

Andy, yeah, direct to VE. I was trying to go via Duty but gave it up.

As it turned out, dead time was the killer in trying to turn Duty into a PW. Dead time is packed away inside the duty; it's excluded from VE. Empirically, you have found that the MAPxRPM relationship to duty is cleaner. I can't argue with that, but it is hard to think why adding dead time to the mix should tighten the relationship.

[pause for thought]

Now that I give it a bit more thought, dead time will increase duty for high RPM, but not for high MAP. This means that, say, a 2000rpmx100kPa and a 4000rpmx50kPa cell get the same MAPxRPM value, therefore the same duty value. When you account for dead time though, the 4000rpm cell gets much more dead time -- less actual fuel. That accords with what I've always thought -- higher load gets richer mixture than higher revs.

Hmmm. Looks like Andy's right again. And here was I thinking it was all done and dusted.

Now, here's the question. It still seems to me that the actual dead time value is not important (in a physics sense) to this. What it does is to add an RPM specific adjustment to the mix which tightens up the relationship. It wouldn't be hard to add a user adjustment to the mix either, to tighten the relationship in a similar way.

Code: Select all

ve = lookup(MAPxRPM, whittle_table);
ve = new_adjustment(ve, RPM, MAP??);

Anybody have any thoughts on what a sensible new_adjustment function would look like? Not sure MAP belongs in its parameter list, but I have a feeling it might.

I'll continue to think about this, but I'm the least experienced in tuning around here and would like to hear other people's ideas. Another possibility is if I could have a few VE tables that generate clean Whittle curves, I might be able to nut out a relationship with a bit of stats voodoo.

Have fun,

Rob.

[whittlebeast]

Here is a plot off one of the more animal motors I tune. This motor just broke a 15 year old track record today at Gateway International in a VW Rabbit. This motor is running a MS3/MS3x setup.

http://www.nbs-stl.com/motec/MAPxRPM%20 ... %20HP3.png

This compared to the 300 HP blown jetski I own that I posted earlier in this thread.

http://www.nbs-stl.com/motec/MAPxRPM%20 ... d%20VE.png

You can see that DC is very much a function of MAPxRPM. VE is not even close on the NA motor. I can post the raw data if people would like to see it. I have the entire 30 min race recorded at 100 hz resulting to a 20 meg file.

Andy.

[ol boy]

So.. dead time becomes a larger percentage of duty cycle at higher rpm..? Smaller PW at a higher frequency but with the same dead time. Should be a simple slope line going from 100% to 110% covering 1000 rpm to 6000!? Would that delta of lost duty also have a load factor in it? The plot thickens!



Edit.. why not turn the VE table into a duty adder for rpm. Or is this solved with a simple math formula?

Sent from my SM-G920V using Tapatalk

[ol boy]

More thinking.... dead time is always going to be a percentage of the period between crank turns. At lower speeds that percentage is less and more at higher speeds. At 6k rpm a dead time of 1ms will account for 10% or 5% of the period (depends on sqrt # alt-sim pattern). While at 1k rpm it's 1.6% or 0.8%.

Sent from my SM-G920V using Tapatalk

[robs]

Andy, I agree, Duty is better, VE is worse.

I'm trying to understand why. That's what all the other stuff in that last post was about.

Here's a plot of MAPxRPM vs VE from my car, which plots a nice thin Duty curve:

veband.png

So the code I posted here isn't much good. It's going to be a thin line somewhere on this plot where a decent tune is actually pretty fat.

But .... what is that very orderly banding of colour? Z axis is RPM. This makes it pretty clear that you can thin up the VE relationship by including some sort of RPM factor in the equation.

Ryan: You've got it. I think it's going to turn out to be a pretty simple relationship. It's hardly progress if, to avoid populating a 2d table we end up populating a curve AND a 2d table!

Have fun,

Rob.

[ol boy]

I've seen in some Toyota or Honda ecu or maybe it was GEMS uses a 16x16 table for dead time doing bat volts on the y and rpm on the x.

I'm sure you'll sort the relationship to bat volts to % of the period.

Sent from my SM-G920V using Tapatalk

[whittlebeast]

I have always found that things always get complicated before they get simple. My gut feeling is we need develop a formula that derives, on the fly, the VE that would generate a base DC. It will come down to basic algebra. We just aren't there yet.

Just thinking out loud here..... Can the code build a lookup table on a burn? Essentially rebuild a SD table based on the sliders? I realize we have never done that but the Extra code was born when James and Phil did something Al never thought of. Using flash for something people had previously thought could only be done in RAM, as I recall.

Andy

[robs]

Believe me Andy, I've done the algebra. But since the fundamental difference between Duty and VE is dead time, what I want to hear is a good rationale for how *dead time* can possibly be important to performance. I think dead time happens to give Duty a linear component related to RPM, and I can see how that could have a bearing, but I don't believe dead time is the right factor. What would happen the graph if you disconnected the alternator? How about the tune?

Since you asked, I'll go into the algebra.

Simplified, it works out pretty much to incorporate the equation that James posted earlier plus a dead time component. Duty, d* is:

d* = [req_fuel.(VE.MAP.RPM)/10000 + deadtime.RPM] * 1/1200.

Experimenting with this, if I use my actual req_fuel value, 19.1, and an "average" deadtime of 1ms, that gives the same tight MAPxRPM->Duty curve my car has given all along. However, plugging in 11 for that req_fuel value you get a tighter curve.

Here are a few graphs in an effort to illustrate that. They are MAPxRPM vs the above with several req_fuel values.

duty.png

Not all that clear, but higher req_fuel values tend to make the upper-right expand; lower values grow the lower-left. In these graphs, the req_fuel = 10 or 15 seem to be the best. Actual req_fuel is 19.1.

In other words, I don't think it's req_fuel and dead time at all. Ultimately, the linear relationship boils down to:

d** = C.(VE.MAP.RPM) + RPM

Try experimenting with values of C in MLV and see if you don't get at least as good a linear relationship as Duty gives you. In my car's case 0.001 gives a thinner curve than actual Duty does.

In the code, I think the solution is going to turn out along the following lines:

Code: Select all

ve = f1*(lookup(MAP * RPM) - f2 * RPM)/(MAP * RPM)

but what is the meaningful explanation for f1 and f2? What are good first estimates? And how are they tuned?

Have fun,

Rob.

[whittlebeast]

If I understand what you are saying correctly, and I get confused easily...

If we had two default axises that both by default went from 0 to 100, one on the bottom was labeled air flow and the vertical is fuel flow. Who cares what the units are. We acknowledge that they are fuzzy logic. But if 100 is not large enough for air flow, increase the size to 200 and the curve now go the twice the are flow. Same with the fuel flow axis. These number then generate a VE table in the background.

Just thinking

Andy

[robs]

I agree that this is going to be some sort of magic number business, but that wasn't really what I was driving at.

The whole notion of VE is magic numbers anyway. What the engineers have done is to take a nice clean concept from physics, the ideal gas law, then acknowledge that they are dealing, not with the idealised world of physics, but with a world where particles aren't zero sized, nor perfectly elastic, and where turbulence exists. To deal with all these difficult to deal with problems, they've added a fudge factor which is to be measured rather than calculated, but it would be embarrassing to call it a fudge factor so they call it volumetric efficiency.

Your curve idea is basically trying to tease out some rules behind the VE numbers.

I had what I think is a decent idea overnight. In many ways dead time is the right concept, but it's air dead time. In the injector's case, dead time is the time between the solenoid being energised and the squirt starting - similar delay at end. In the inlet tract, "dead time" is the time between the valve opening and the column of air really getting into gear (a bit like traffic lights). Let's say this takes 1ms in a particular engine at some particular air density. At low speed, the intake stroke might be 25ms, so 1ms inertia-time doesn't impede volumetric efficiency very much. At high speed, by the time 1ms has passed, the piston is already well down its stroke and, even though the column of air is now up to speed, it may not get the cylinder up to pressure before the valve closes. So you have been using injector dead time which makes a not-too-bad approximation of air inertia. It also gives some insight why it might be less applicable to ITB inlets.

Well, that's my hypothesis at any rate. I'm just thinking about this from first principles (picturing little marbles rattling around) and I bet it's all well understood and documented in engineering articles. I also bet the reason it's not included in the MS equations is that inlet gas inertia is going to be engine specific and, since you still need a VE number to allow for other factors, just leave it lumped in with all the others.

But I don't think that means we've been wasting our time here. I bet there are some ballpark numbers that will apply to many engines, particularly stock engines. Not inconceivable that one new question, e.g. "how many inlet valves per cylinder", would give a good enough hint for a reasonable inertia factor to be plugged in, with the rest of the Whittle curve user interface staying as-is.

For now, I'm going to try a few more graphs from my engine and see if I can come up with some rules. If I come up with something promising, we can try it out against some of your logs, and Ryan's, and others.

Have fun,

Rob.

[ol boy]

I'm thinking back to the bigger picture idea from 2 weeks ago about some widget to analyze datalogs and produce a new dead time. To make the rpm x map to ve work more precisely over the entire rpm range well have to add in that % of cycle lost or added back to get the proper duty value.

I can produce logs with dead time too low and with it at the current value. I can add 400us and do another tune to compare ve values and resulting duty.

Can someone post a good looking VE table with a properly measure dead time? My tables never end up looking like the default table stored in flash.

On one of my MAF tunes I was having a hard time nailing down the transfer curve. At one rpm and map it would produce a good AFR but at another but with same g/s airflow would result in an undesired AFR. I can only assume the dead time was offsetting the PW too big or too small one direction or the other.

Dead time is so important with the standard SD or %baro tune why would it suddenly be less critical with a more complicated fueling algorithm?


Sent from my SM-G920V using Tapatalk