Re:Whittlebeast's RPMxMAP vs Duty function

[whittlebeast]

Assuming your motor is holding consistent AFRs and the VEs are well tuned, a hook at the bottom end indicates that your opening time are not correct and you have tuned around it with the VEs.

A hook down at the top right when the AFRs look good, is a motor running past it's power band.

[ol boy]

Looking at the bigger picture is there some slope math that can take your current dead time and with input from the map x rpm to maf or pw output a new dead time?

My buddy is big into eec 4 and 5 ford stuff using tuner pro. It pulls the logs and sorts out a new injector slope for low and high to reduce the ego correction/error. But with newer injector designs that non-linear area is about gone or is very small.

To insure the map x rpm to pw will work correctly for everyone we need a fool proof way to sort out dead times using the data for the hardware they are using.

Sent from my SM-G920V using Tapatalk

[robs]

Up till now I have had a hunch that the MAPxRPM vs. Duty graph was pretty much equivalent to the MAP vs. PW graph, since all we've done is multiply both axes by RPM.

Completely wrong. RPM is not a constant that we're multiplying by, but another variable. This is definitely not a simple scaling of the MAP vs PW graph.

Haven't delved into the code yet. Thought I'd try out the idea manually: start with one of my data logs, eyeball a curve to interpolate, then generate a VE table from it. The result has been interesting.

Here is the usual scatter plot with my eyeballed curve drawn on it (plotted in R, a free stats package):

fit.png

I then wrote a Perl script which takes the coordinates from that curve and a req_fuel value. It generates VE table values for a reasonable range of MAP and RPM. Here's the script:

Code: Select all

#!/usr/bin/perl -w
#
# Generate a VE table to comply with a Whittlebeast function
#
use strict;

#
# Points eyeballed from the MAPxRPM, Duty scatter plot
#
my @ipts = (
	[28070.85, 3.028723],
	[85217.24, 8.728381],
	[163528.95, 18.582027],
	[210621.81, 27.276420],
	[270413.87, 36.985159],
);
my $req_fuel = 18.2;

#
# Simple interpolation
#
sub interp
{
	my ($v) = @_;
	my $i;

	#
	# Which bucket does it belong in? (last bucket extends to infinity)
	#
	for ($i = 0; ($i < $#ipts - 1) && ($ipts[$i]->[0] < $v); $i++){}

	#
	# Interpolate (or extrapolate beyond ends).
	#
	my $p = ($v - $ipts[$i]->[0])/($ipts[$i+1]->[0] - $ipts[$i]->[0]);

	return($ipts[$i]->[1] + $p*($ipts[$i+1]->[1] - $ipts[$i]->[1]));
}

my ($vebuf, $prodbuf);
for (my $map = 100; $map >= 20; $map -= 10)
{
	for (my $rpm = 500; $rpm < 6000; $rpm += 500)
	{
		my $duty = interp($rpm * $map);
		my $pw = 1200*$duty/$rpm;
		#
		# pw = req_fuel*map/100*ve/100 
		# therefore:
		my $ve = 10000*$pw/($map*$req_fuel);
		$vebuf .= sprintf "%6.1f ", $ve;
		$prodbuf .= sprintf "%6d ", $rpm*$map;
	}
	$vebuf .= "\n";
	$prodbuf .= "\n";
}
print $vebuf, "\n\n", $prodbuf;

And here is its output with RPM horizontal 500:5500 in 500 rpm steps. MAP is vertical with 100 at the top, dropping to 20 in 10kPa steps. Upper block is the calculated VE table. The lower block is RPMxMAP values, just for reference.

Code: Select all

  56.7   45.2   70.7   84.2   88.8   91.8   94.0   95.6   96.9   97.9   98.8 
  53.7   36.7   65.0   81.7   86.8   90.2   92.6   94.4   95.8   96.9   97.8 
  50.1   66.5   57.9   73.9   84.2   88.0   90.8   92.8   94.4   95.6   96.7 
  45.4   64.2   48.8   67.1   81.0   85.3   88.4   90.8   92.6   94.0   95.2 
  39.1   61.0   36.7   57.9   70.7   81.7   85.3   88.0   90.2   91.8   93.2 
  71.8   56.7   65.4   45.2   60.5   70.7   81.0   84.2   86.8   88.8   90.5 
  73.3   50.1   61.0   66.5   45.2   57.9   67.1   73.9   81.7   84.2   86.3 
  75.8   39.1   53.7   61.0   65.4   36.7   48.8   57.9   65.0   70.7   79.4 
  80.9   73.3   39.1   50.1   56.7   61.0   64.2   66.5   36.7   45.2   52.1 


 50000 100000 150000 200000 250000 300000 350000 400000 450000 500000 550000 
 45000  90000 135000 180000 225000 270000 315000 360000 405000 450000 495000 
 40000  80000 120000 160000 200000 240000 280000 320000 360000 400000 440000 
 35000  70000 105000 140000 175000 210000 245000 280000 315000 350000 385000 
 30000  60000  90000 120000 150000 180000 210000 240000 270000 300000 330000 
 25000  50000  75000 100000 125000 150000 175000 200000 225000 250000 275000 
 20000  40000  60000  80000 100000 120000 140000 160000 180000 200000 220000 
 15000  30000  45000  60000  75000  90000 105000 120000 135000 150000 165000 
 10000  20000  30000  40000  50000  60000  70000  80000  90000 100000 110000 

Perhaps there's a howler in there, but I think the code's right. Given the way it was derived, I suppose it shouldn't be a surprise that the output is similar to my existing VE table, but it has some dips that I wasn't expecting; I'm sure I've manually smoothed out such dips when VEAL looked like it had dug a hole. Maybe it was on to something. That little line of 39.1s adjacent to 73.3s looks odd, or the 36.7s, always surrounded by considerably higher values.

Here it is looking a bit more graphical:

ve.png

Assuming I haven't ballsed up, this shows that, as expected, it's possible to go direct from the curve to a VE table. Now we get to the question: does supporting this need any change to the MS2/Extra (or MS3) firmware at all?

I'm thinking that the Whittlebeast function should be looked at as a tuning technique to quickly get a solid base tune into the VE table, and that all fuelling decisions should still channel through that table. In the cases where the thin-line rule doesn't apply, this lets other tuning techniques take over seamlessly.

This is lumping the effort into TunerStudio instead. Andy described his proposed interface earlier: you would need a way to set MAPxRPM "load" and corresponding target AFR values, a way to see the current load, AFR and target AFR, and a way to vary the duty cycle for the current load setting. So a typical wizard graph, and either manual controls or a VEAL-style interface which automatically chases the targets.

Under the covers, TS would need to be working out which VE table cells were impacted at the current load setting and send its usual updates to those cells as the required duty changes.

I hope this doesn't all seem like a cop-out, and there may be tweaks that can be added to the firmware to help TS do the work, but by and large, particular tuning methods are probably better hosted in the tuning software (especially given how full MS2 is).

Meanwhile, I'll be happy to make something properly useful out of that Perl script for MLV type use -- i.e. once you've decided your control points, it would generate a ready-to-import VE table.

For you Ryan, this means you might tune half a dozen points along the diagonal of the VE table on the dyno, then use those optimised points as input to the Perl script which would generate the rest of your VE. Not too awful (though high performance and 2-stroke worries remain).

Also your injector dead time question is worth asking. Dead time is one of the things I've left out of this for now (being generally lazy -- it may well explain the rich looking bottom-left of the table). I think there's too much going on in this area to isolate out a dead time component. Best is surely on the bench. On the engine there's the two vs. four squirt comparo and I'll throw in a with/without alternator to vary the voltage.

Enough of a ramble for now. Time for everyone to point out my glaring mistakes.

Have fun,

Rob.

[whittlebeast]

At one point, I did something similar but I used a vacuum pump and a stim to generate the base VE table. Unfortunately, it was an ITB motor that would not behave very well on the model but it did get get me from a driveway tune to a reasonable starting base map that I could use on the dyno as a starting point.

[robs]

Thought a bit more about this overnight. It was a cop-out. The point of the new wizard would be to support simplified tuning where the user holds a steady RPMxMAP (easy) while varying Duty until a target AFR is reached. When you consider that (a) a single RPMxMAP value equates to an oblique line ruled all the way across the VE table and (b) TunerStudio can only command values for the VE table grid intersection points, I don't think it'd even be possible for the VE table to be made to comply with the wizard's controls.

I'll start looking at the manuals to see if the MAF input gets anything like what is needed. Then I'll see about delving into the code.

Speaking about the VE table and grid interpolation, I've reposted something I posted to the B&G forums years ago.

[ol boy]

Whats the resolution that can be achieved in duty cycle? 65.553%? or 655.53% What method yields the finest PW step? With MS2 users the complaint has been VE values to a whole values. Whats your thoughts on using Load x RPM instead of MAP x RPM. MAP would remove %Baro. I'll pull a few datalogs from the 2 stroke engines and do a TPS x RPM to Duty to see what I get.

Thanks Ryan

[ol boy]

Here is a scatter plot of TPS X RPM vs Duty. Flown with a MAF, this has the tightest line/curve and tightest AFR of most logs.

I have a bout a hundred logs over the past year flying this engine and others like it.

TPS X RPM to Duty DA120.png

[robs]

Whats the resolution that can be achieved in duty cycle? 65.553%? or 655.53% What method yields the finest PW step? With MS2 users the complaint has been VE values to a whole values. Whats your thoughts on using Load x RPM instead of MAP x RPM. MAP would remove %Baro. I'll pull a few datalogs from the 2 stroke engines and do a TPS x RPM to Duty to see what I get.

Duty cycle is derived from PW and RPM: Duty% = PW x RPM / 1200 (can vary depending on how many squirts per cycle). Ultimately we want to generate a PW so the operations involved are going to be PW = lookup(MAP*RPM)/RPM*(constant perhaps). Will need to think about the ranges involved here. MAPxRPM is already too big for a 16-bit, and there aren't any 32-bit interpolation functions (or there weren't last time I looked). And, as you say, we need to hold enough precision for a decent PW even after dividing by RPM.

I also want to do a bit of sensitivity checking. It's all very well seeing that the ideal curve is so thin, but it does us no good if moving one of the control points a tiny amount leads to a dramatically different VE table. I don't think this will happen, but it seems worth checking before getting in too deep.

The TPSxRPM plot does look nice and thin, but not much of the running time was in the low area which is where I'd be expecting it to misbehave (at low RPMs, extra TPS won't necessarily deliver extra air, but it will increase TPSxRPM). Still, worth planning for an option to use TPS in place of MAP.

Have fun,

Rob.

[whittlebeast]

I have looked into TPSXRPM on my motors and that looks way less useful. The basic A-N table is far more understandable.

Andy

[whittlebeast]

Rob, I actually use MAP * RPM/100. I realize you loose accuracy but would that help get these big numbers to fit inn the code. Is this also an issue on MS3?

Andy

[whittlebeast]

I just tried the formula

MAPxRPM rounded and defined it as

[MAP]*round([RPM]/100)

And it did not cause any real accuracy hit.

[Rick Finsta]

Assuming your motor is holding consistent AFRs and the VEs are well tuned, a hook at the bottom end indicates that your opening time are not correct and you have tuned around it with the VEs.

A hook down at the top right when the AFRs look good, is a motor running past it's power band.

Not trying to hijack but thought I'd add a few other things I've seen using (MAPxRPM)xDC:

A hook up on the top right is running out of fuel... I found that my fuel pressure gauge wasn't showing it but increasing pump duty cycle brought everything back in line on mine. It was super easy to see it wasn't the VE table using this method since the ECU was holding the injector open longer than it *should* have had to for a given amount of airflow.

Also, I've found little bumps off the line where the VE table is commanding PW in the non-linear range (in my case <2mS) of the injectors. They look like the idle dead-time bumps, but happen up the line further. I like looking for such anomalies and then clicking some data points in that area to see what was going on - in my case it was throttle closing at high RPM going into the low load areas.

[whittlebeast]

Just for fun, here is what a Honda V-Tec Motor looks like.

http://www.nbs-stl.com/HarleyTuning/Hon ... 0Logic.png

Notice how the motor has two distinct lines. One for the low cam and one for the high cam.

[jsmcortina]

When I discussed implementing this with Andy, it was going to be a VE curve vs MAPxRPM. Although, maybe it would be better to use the MAF curve feature.

James

[ol boy]

When I discussed implementing this with Andy, it was going to be a VE curve vs MAPxRPM. Although, maybe it would be better to use the MAF curve feature.

James

How many points are in the MAF curve? Something like 32 or was it 64?

Do you think the resolution can be as low as 100.00% or finer with the allotted memory?

[whittlebeast]

James, my best guess at this point is to do a MAF like function. My bet is you could get by with about 8 points developing the curve. Nowhere near 32 or 64 points.

Andy

[robs]

Andy,

I'm worried that even 20rpm might sometimes be significant when making fuelling calculations. A small change in duty can make a big change at idle. It might be that some sort of variable precision is needed (something like floating point) to support both precision at idle and range for flat out running.

I gave that Perl script a few runs to check sensitivity. Haven't unearthed anything too worrying, but it is interesting how it behaves. Here are the lines of the original VE and the modified cells below each when I added 0.1% duty to the second control point (i.e. 8.72% -> 8.82%):

Code: Select all

  50.1   66.5   57.9   73.9   84.2   88.0   90.8   92.8   94.4   95.6   96.7
  52.7   67.4   
  45.4   64.2   48.8   67.1   81.0   85.3   88.4   90.8   92.6   94.0   95.2
  48.5   65.3   
  39.1   61.0   36.7   57.9   70.7   81.7   85.3   88.0   90.2   91.8   93.2
  42.9   62.5   
  71.8   56.7   65.4   45.2   60.5   70.7   81.0   84.2   86.8   88.8   90.5
  71.7   58.6   66.4   
  73.3   50.1   61.0   66.5   45.2   57.9   67.1   73.9   81.7   84.2   86.3
  72.8   52.7   62.5   67.4   
  75.8   39.1   53.7   61.0   65.4   36.7   48.8   57.9   65.0   70.7   79.4
  74.8   42.9   56.0   62.5   66.4   
  80.9   73.3   39.1   50.1   56.7   61.0   64.2   66.5   36.7   45.2   52.1
  78.8   72.8   42.9   52.7   58.6   62.5   65.3   67.4   

Not the easiest to read, but that smallish change in one control point led to quite some ructions in the table. More control points would make each one less influential and, because of the way the data gets more rarefied towards the right, it'd probably be reasonable to pack most of the control points towards the left. I suspect 8 or maybe 12 points would be fine; if an engine needs more than that it's probably one of the exceptions to the line rule.

On this, and also on the "floating point" question, it just struck me that a log-log version of the scatter plot I posted earlier would be worth looking at:

l-l.png

That evens the spread up quite a bit, and gives more detail either of my engine's bad tuning, or the fact that low load areas might be problematic.

For implementation, despite what my avatar says, I'm no master, so don't be shy about giving more details (or pointing me at doco). The sort of idea that occurs to me is to jam an adjusted RPMxMAP value into a 10-bit number (0-1023) and use that in place of a physical MAF's ADC input. The desired user interface makes sense for MAF tuning. Doesn't seem like crazy talk to me, but it might to someone who knows what he's talking about.

As a final point, if a 10-bit number is enough for reading a MAF sensor, it should be enough for some flavour of the Whittlebeast function's MAPxRPM value, so the 32-bit interpolator probably won't be needed. Mind you, it'd probably be easier to implement than a log() function (given the space we have in MS2).

Have fun,

Rob.

[ol boy]

How about a smallish 6x6 ve table for the idle area. When closed loop idle is active use the values in the table instead.

Or just a fixed duty value. I had some weirdness with MAF in the idle area but finally worked out the right g/s slope to counter any rpm wiggle and thus pw change.

Sent from my SM-G920V using Tapatalk

[whittlebeast]

I always pictured this as 85% of the tuning would be done on the
"curve" and all fine tuning could be done with a Speed Density correction table. As long as the "curve" gives a gentle fueling without jumps in DC or PW, I see no issues.

Andy

[ol boy]

Could we use the VE trim tables instead? +-12.8 from the curve.. do you see any reason that the curve wouldn't get most if not all engine within 12%?

Sent from my SM-G920V using Tapatalk