Re:Whittlebeast's RPMxMAP vs Duty function

This is a forum for discussing the development and testing of alpha MS2/Extra code. Documentation
(Runs on MS2 and Microsquirt)

Moderators: jsmcortina, muythaibxr

robs
Master MS/Extra'er
Posts: 564
Joined: Sun Jan 17, 2010 4:26 pm
Location: Sydney, Australia

Re: Re:Whittlebeast's RPMxMAP vs Duty function

Post by robs »

Ryan, I wasn't meaning dead time was irrelevant when tuning MS2. In this thread though, the thing about dead time is that to go from VE to Duty, or from Duty to VE, dead time has to be accounted for. But, by definition, dead time is time that the injector is not squirting, so actual dead time cannot have any bearing on tune yet it seems to improve the fit. That's why I've been waffling on about gas inertia -- a different sort of dead time.

Your injector dead time problems might be unstable voltage, or sensing voltage at a different point from that feeding the injectors, or maybe a messed up voltage correction. I'm not telling you anything you don't know though, but I don't think anything in the Whittle curve area is going to help sort out injector dead time.

Have fun,

Rob.
robs
Master MS/Extra'er
Posts: 564
Joined: Sun Jan 17, 2010 4:26 pm
Location: Sydney, Australia

Re: Re:Whittlebeast's RPMxMAP vs Duty function

Post by robs »

It has been gently pointed out to me that I might be fooling myself here, (or making a fool of myself). Well, yes I have (you can choose which).

As I posted earlier, duty can be expressed in terms of VE.
Duty = (PW * RPM)/1200
PW = (VE/100)*(MAP/100)*req_fuel + dt
(dt, dead time)
Therefore:

Duty = [(VE/100)*(MAP/100)*req_fuel + dt]*(RPM/1200)
dividing MAP out of the left and into the right:
or.. = [VE*req_fuel/10000 + dt/MAP]*RPM*MAP/1200

Previously I didn't go out of my way to get MAP and RPM together, but I should have. It turns out that MAPxRPM dominates the values on the RHS so we're pretty much plotting MAPxRPM vs MAPxRPM + (signal). After all this wrangling, I'm afraid that's all there is to it.

Two more plots:
dutywith.png
dutywithout.png
The second plot is the same duty values as the first, minus a constant multiple of MAPxRPM. Bang goes the useful linear relationship.

And there I was making up a really plausible story. Had me fooled. Sorry if people are disappointed. I've enjoyed the tinkering and it seemed worth the effort to explore. I suppose it's a bit much to expect that tuning could be so greatly simplified. Dynos will still be useful.

At this point, I think we can return the devel forum to its more accustomed ghost-town state. OTOH, having updated one of my cars to the latest firmware and found MAP to be surprisingly noisy, I just might have a dabble in there.

Have fun,

Rob.
whittlebeast
Super MS/Extra'er
Posts: 2221
Joined: Tue May 04, 2004 8:20 pm
Location: St Louis
Contact:

Re: Re:Whittlebeast's RPMxMAP vs Duty function

Post by whittlebeast »

Rob, It looks to me that you can use the formula

VE Calced

([Req Fuel]/2)*(([Duty Cycle Whittle]*1200/[RPM])-[InjectorDeadTime])/([MAP]/100)

Where [Duty Cycle Whittle] comes from our lookup curve and feed that number back into the normal fuel equation to get the answer we are looking for.

I am not real sure where the "/2" part is coming from. Possibly 2 squirts....

Please don't give up now.

see http://www.nbs-stl.com/motec/VE%20Calce ... o%20VE.png

This data is coming off the racecar running MS3x that we just set a track record with that had stood for 15 years. :mrgreen:

Andy
ol boy
Super MS/Extra'er
Posts: 1532
Joined: Mon Sep 10, 2007 3:06 am
Location: Tucson, Az

Re: Re:Whittlebeast's RPMxMAP vs Duty function

Post by ol boy »

I'll continue to smash along with my car and the code Robs came up with. It's working well as is. If a few other testers want to try it out and report back there experience would be helpful.

Ryan

Sent from my SM-G920V using Tapatalk
306 SBFord, Torquer II EFI intake, 60 lbs injectors, 8 LS2 coils, VS Racing 7668 turbo, 4R70W, MS3x fw1.4 w/built in trans controller.
robs
Master MS/Extra'er
Posts: 564
Joined: Sun Jan 17, 2010 4:26 pm
Location: Sydney, Australia

Re: Re:Whittlebeast's RPMxMAP vs Duty function

Post by robs »

Andy,

Perhaps I was a bit strong in that last post. I was kicking myself for becoming obsessed with equations when the simplest statistical analysis would have shown me that the vast majority of the linear relationship was contributed by the y axis being heavily dependent on the x axis. There might still be something to be salvaged.

Nevertheless, I have moved to a strongly sceptical position. I know that's a sudden change from my position of near conviction two days ago. The nice thing is that my attitude doesn't have to matter. There's not all that much difference between proving there is a relationship and proving there isn't. Failing on the one pretty much achieves the other.

I'm happy to code something up, but I don't want to see dead time mentioned in the formulation. There can be no physical reason it should be there. PW = VE stuff + dead time is the rule and it makes sense. What's more, dead time is mostly a function of voltage. Surely you agree that it's nonsensical for VE to depend on dead time.

That doesn't close out the inlet "dead time" hypothesis, but that hypothesis needs meat put on its bones.

Trying your proposed equation with a line fitted against my car's figures, and plotting them against the car's well tuned VE:
veve.png
Perfect would be a thin y=x line. With scaling and translation, I can get the blob to lie over y=x. But look at the range of VE (i.e. the height of the stripes). Even after scaling down, the fitted value is the real value +/- 10. Seems to me that tuning two points and using the TunerStudio interpolate tool would get you a lot closer.

Now there is definitely a relationship there, but that is no surprise. The Whittle curve was derived from the Duty plot, and Duty heavily depends on VE. The relationship is expected, but you'd hope for it to be tighter.

Looking down at this problem from the user-interface level, when the user raises one of the control points, all the VE values associated with that RPMxMAP setting must be lifted. This would be equivalent to tracing a hyperbola across the VE table and increasing all their values. The hyperbola is locked down -- RPMxMAP = C. All we need to decide is how much or how little to raise those values. The code Ryan is using lifts them all equally. The inlet inertia theory suggests that you lift the high RPM values less and the high MAP values more. Still a big question over what the rule should be, but that's all that needs to be decided.

Have fun,

Rob.
ol boy
Super MS/Extra'er
Posts: 1532
Joined: Mon Sep 10, 2007 3:06 am
Location: Tucson, Az

Re: Re:Whittlebeast's RPMxMAP vs Duty function

Post by ol boy »

Robs: you got me thinking... not to disprove/prove or to sway you either direction but more of a fact finding expedition. I found dead time is in the 212 bytes of data that MS spits out but didn't see it in any of my logs. Looking at the bottom of the ini file it's not to be found in the [datalog] section, so I added it. Also made a variable called pw_cal. pw_cal = pw1-deadtime. I suppose we could also make another variable with deadtime/pw1*100 to find the ratio of wasted time lost to the mechanics of the injector and its affect on duty cycle.

In an ideal situation deadtime could be seen as an unchanging constant and mechanically correct, therefore less of a concern on the total function.(as your latest conclusion seems to convey) But in reality 95% of all MS users probably aren't within 10% of the actual measured deadtime. As a result the VE table values makes up for a few 100us here or there but produces results with the same duty cycle and same AFR no matter how far off from ideal.

Just on my drive home today I noticed a big lean hole around 50kpa +-10kpa. Richer below and Richer above. I added an extra 50us to the deadtime around the half way point of the trip. Looking at the histogram shows when that adjustment took place. Showing 15.2ish AFR average for those same cells after the adjustment but near 16.0 before. I'll add another 25us in the morning and retest. My theory is once deadtime is nailed down the rpm x map to VE will yield the desired results everytime. Deadtime becomes more of a constant and is the proper offset for pw to duty across the entire rpm and load range. In short, I have a stack up of stack ups with the standard offset of deadtime. Once the stack ups are removed all that's left is deadtime which gets back to rpm x map >> duty [VE+deadtime]*rpm/1200.

I'm sleepy... Ryan

Sent from my SM-G920V using Tapatalk
306 SBFord, Torquer II EFI intake, 60 lbs injectors, 8 LS2 coils, VS Racing 7668 turbo, 4R70W, MS3x fw1.4 w/built in trans controller.
robs
Master MS/Extra'er
Posts: 564
Joined: Sun Jan 17, 2010 4:26 pm
Location: Sydney, Australia

Re: Re:Whittlebeast's RPMxMAP vs Duty function

Post by robs »

Ryan, I take it you're not using EGO correction? You're probably right that most people don't have their dead time right. Likewise MAT (I suspect). But as long as they've got a reasonably consistent VE table, and reasonbly steady voltage, EGO feedback will pretty quickly home in on a suitable correction for the rest of the drive won't it?

Anyhow, I think it's particularly good idea you had to log PW-deadtime -- that'll be (the best guess at) the actual amount of fuel being delivered. But then I guess plotting that against MAPxRPM won't be all that much different from plotting VE against it, and Andy isn't so keen on that.

I've tried some common statistical methods on my usual data log, seeing what relationships can be found. I tried comparing two simple models:
  • best fit plane: ve = p1*RPM + p2*MAP + p3
  • best fit Whittle contour: ve = p1*MAPxRPM + p2*RPM + p3
p2 in the Whittle model gives us the equivalent of what dead time does, giving an RPM dependent ramp in VE for points along a Whittle contour (RPMxMAP=C). The reason I'm comparing it with a simple plane is that many people seem to describe these "well behaved" engines as "linear". Whether that truly means the VE map is something like a plane, I'm not sure. I should also point out that the Whittle code change is more powerful than the model above, because the model assumes a straight line, where the code does a curve lookup. Anyhow, comparing anova (analysis of variance) statistics of these two models looks promising:

Code: Select all

> anova(mt)   (Plane model)
Analysis of Variance Table

Response: y$Gve
             Df Sum Sq Mean Sq F value    Pr(>F)    
y$RPM         1 117421  117421   14384 < 2.2e-16 ***
y$MAP         1 720004  720004   88203 < 2.2e-16 ***
Residuals 12942 105646       8                      
> anova(mw)  (Whittle model)
Analysis of Variance Table

Response: y$Gve
             Df Sum Sq Mean Sq F value    Pr(>F)    
y$xprod       1 746135  746135   99175 < 2.2e-16 ***
y$RPM         1  99569   99569   13235 < 2.2e-16 ***
Residuals 12942  97368       8                      
In brief, the slightly smaller residuals value tells us that for my particular engine, the cross product (RPMxMAP) with RPM models the VE table better than the best fit plane of RPM and MAP. Doing the actual regression gives the best fit equation: VE = 0.001984.MAPxRPM - 0.0055947.RPM + 47.94. The important thing here is the -0.0055947.RPM. If we added a simple RPM multiplier to the user interface, the curve lookup attends to the other values. Here is the effect it has on the RPMxMAP to VE fit:
sbs.png
The way the code is at present, we are effectively using a thin curve drawn over the graph on the left to represent each value. If I add the constant RPM multiplier (and the user enters a good value for it!!) the curve represents the much smaller range of values on the right. I would be happy to add this small change to the code, but how does the user decide on an RPM multiplication factor? (and no, my injector dead time is not 5.5ms!).

Opinions? Happy to do similar work on other log files to see if there's a pattern.

Have fun,

Rob.
Dennis_Zx7r
Experienced MS/Extra'er
Posts: 374
Joined: Thu May 26, 2016 1:25 pm
Location: Germany

Re: Re:Whittlebeast's RPMxMAP vs Duty function

Post by Dennis_Zx7r »

As I understand it, you may have neglected the effect that MapMultiply has on the VE table. Maybe this could improve things?
My project: Link
whittlebeast
Super MS/Extra'er
Posts: 2221
Joined: Tue May 04, 2004 8:20 pm
Location: St Louis
Contact:

Re: Re:Whittlebeast's RPMxMAP vs Duty function

Post by whittlebeast »

Dennis, that is my guess also.
ol boy
Super MS/Extra'er
Posts: 1532
Joined: Mon Sep 10, 2007 3:06 am
Location: Tucson, Az

Re: Re:Whittlebeast's RPMxMAP vs Duty function

Post by ol boy »

Dennis_Zx7r wrote:As I understand it, you may have neglected the effect that MapMultiply has on the VE table. Maybe this could improve things?
Won't it just spread out the VE values and extend the range. 20 to 200ish... I'm in boost so that added fuel from MAP alone won't be there.

Sent from my SM-G920V using Tapatalk
306 SBFord, Torquer II EFI intake, 60 lbs injectors, 8 LS2 coils, VS Racing 7668 turbo, 4R70W, MS3x fw1.4 w/built in trans controller.
whittlebeast
Super MS/Extra'er
Posts: 2221
Joined: Tue May 04, 2004 8:20 pm
Location: St Louis
Contact:

Re: Re:Whittlebeast's RPMxMAP vs Duty function

Post by whittlebeast »

Ol Boy Try this formula in MLV HD

VE calced

((YOUR REQ FUEL)/2)*(([Duty Cycle1]*1200/[RPM])-(YOUR INJECTOR DEAD TIME)/([MAP]/100)

See if the VE1 is really close to the VE Calced

Or post one of your logs and I can do it.

Andy
ol boy
Super MS/Extra'er
Posts: 1532
Joined: Mon Sep 10, 2007 3:06 am
Location: Tucson, Az

Re: Re:Whittlebeast's RPMxMAP vs Duty function

Post by ol boy »

I'm leaving for work shortly and will log it and post.

Sent from my SM-G920V using Tapatalk
306 SBFord, Torquer II EFI intake, 60 lbs injectors, 8 LS2 coils, VS Racing 7668 turbo, 4R70W, MS3x fw1.4 w/built in trans controller.
Dennis_Zx7r
Experienced MS/Extra'er
Posts: 374
Joined: Thu May 26, 2016 1:25 pm
Location: Germany

Re: Re:Whittlebeast's RPMxMAP vs Duty function

Post by Dennis_Zx7r »

ol boy wrote:
Dennis_Zx7r wrote:As I understand it, you may have neglected the effect that MapMultiply has on the VE table. Maybe this could improve things?
Won't it just spread out the VE values and extend the range. 20 to 200ish... I'm in boost so that added fuel from MAP alone won't be there.
The following is a simplified 3x3 example for a naturally aspirated engine. In this example, the engine is what I call perfectly "linear" at 3000Rpm. Both result are identical in the resulting PW, assuming the left doesn't multiply map, and the right one does. My understanding is that the "effective" VE without MM is the raw VE value in the table, and with MM enabled it's VE_effective = VE*MAP/100.
Image
This of course means a different VE table has to be generated for different settings of MM.

---------------------

If you don't have DT in your (older) logs, the following could be used to calculate it in MLV.
(DT_at_13.2V)-([Batt V]-13.2)*(BattVoltageCorrection)

For example, I use a base DT of .72ms and BattVoltCorr of .12ms/V, and the formula for my custom field would be 0.720-([Batt V]-13.2)*0.12
My project: Link
ol boy
Super MS/Extra'er
Posts: 1532
Joined: Mon Sep 10, 2007 3:06 am
Location: Tucson, Az

Re: Re:Whittlebeast's RPMxMAP vs Duty function

Post by ol boy »

So the log this morning was too big even after I zipped it. I tried to make it smaller and broke it somehow. I'll give it ago this evening on the way home. Removed a bunch of stuff from [datalog], see what happens.

I up loaded a 970K file the other day but now the limit is 716k?
306 SBFord, Torquer II EFI intake, 60 lbs injectors, 8 LS2 coils, VS Racing 7668 turbo, 4R70W, MS3x fw1.4 w/built in trans controller.
Dennis_Zx7r
Experienced MS/Extra'er
Posts: 374
Joined: Thu May 26, 2016 1:25 pm
Location: Germany

Re: Re:Whittlebeast's RPMxMAP vs Duty function

Post by Dennis_Zx7r »

This is his logfile.
zipped: https://dl.dropboxusercontent.com/u/106 ... .03.25.zip
unzipped: https://dl.dropboxusercontent.com/u/106 ... .03.25.msl

edit: You can't open it with MLV-HD, but you can do so with MLV-MS!
edit2: I fixed the file (see http://www.msextra.com/forums/viewtopic ... 76#p487176), it should open now with MLV-HD, too.
Last edited by Dennis_Zx7r on Wed Oct 26, 2016 1:29 pm, edited 1 time in total.
My project: Link
ol boy
Super MS/Extra'er
Posts: 1532
Joined: Mon Sep 10, 2007 3:06 am
Location: Tucson, Az

Re: Re:Whittlebeast's RPMxMAP vs Duty function

Post by ol boy »

I opened the log in MLV(non-HD) and it shows percentage of deatime to duty. Idling shows 30% at 650 rpm, 26% at 1900 rpm cruising at low load, and as low as 16% at 2300 rpm under medium load. I'm running 60lb injectors in a 306 Ford. I suppose with smaller injectors in a 300Hp engine deadtime would be less of a percentage of the total duty and have less sway on the duty% and less sway if not correctly set. Something else to think about.. This is with 2 sqrt alternating. If I switched back to 4 squrt alternating then the % of deadtime will nearly double which places more heavily to need to have a proper deadtime set.

The assumption is when everything is dialed in the MAP x RPM to duty should intersect 0,0 on the graph. The size and shape of the fuzziness near the bottom of the line will give indications if you're off or just close with inj deadtime. For the sake of science.. I could retune the VE values for each trip and move the deadtime up or down 200us for each drive to see the shape difference. Hopefully over time we will see the math correlation and have a better fuel algorithm figured out.

I'll strip some stuff from the datalog INI section and reduce the sample rate so once zipped it will be under 700k.

Ryan
306 SBFord, Torquer II EFI intake, 60 lbs injectors, 8 LS2 coils, VS Racing 7668 turbo, 4R70W, MS3x fw1.4 w/built in trans controller.
robs
Master MS/Extra'er
Posts: 564
Joined: Sun Jan 17, 2010 4:26 pm
Location: Sydney, Australia

Re: Re:Whittlebeast's RPMxMAP vs Duty function

Post by robs »

Dennis, my posting yesterday was trying a naive statistical fit of linear combinations of RPM and MAP to VE. Whether the VE was built with or without multiply map would change the VE values, but the geometrical effect would just be to apply a tilt to the whole VE table. The equation coefficients would change, but the goodness or badness of fit wouldn't change.

Ryan, that log file was surely generated with the Whittle curve (v1). The sort of log file I'd like to see would be of a "linear" engine, well tuned in the traditional way. I want to see whether the RPM coefficient (that I think is accidentally lurking in Andy's dead time expression) doesn't change much, from one engine to another.

I've convinced myself to add the RPM factor anyway. Code is easy; bit more fiddly doing the INI file. There will be a new "Whittle" parameter, saying how many VE percent to degrade per RPM (or 100 RPM or whatever). The VE value will become: Lookup(MAPxRPM) - degrade_parm*RPM. Setting degrade to 0 will behave like the version Ryan's running now.

The way I imagine tuning might work is that the user draws the initial curve and sets the degrade parameter (all somewhat plucked out of the air, just like the initial VE table has been traditionally). He has also set a reasonable AFR table -- something like Ryan described earlier: stoich for light to moderate load. A bit of free-revving tuning, just to get a feel for the slope of the curve. Then choose a MAPxRPM that covers a good range -- e.g. 150.000 (1500rpmx100kPa, 3000rpmx50kPa) and go for a drive. Although the lookup value itself always represents the maximum load VE, the user doesn't have to start by tuning at 100kPa. If he tunes 3000x50 so there's no EGO correction, then comes back to 2000x75 and sees it has gone lean, there's not enough slope -- the degrade factor should increase, as should the curve point. A few iterations should home in on a decent tune for this Whittle contour fairly quickly.

The big question: will the same degrade slope work for other Whittle contours. Picturing it on a real contour map, each Whittle contour follows a slightly descending curved path. As long as the "hillside" we're trying to model is reasonably smooth, this should be fine. If it's got peaks and ridges, not so good. But if it is smooth, once you've got the degrade value right, tuning all the other Whittle contours is just a matter of holding to that RPMxMAP and adjusting the control point as necessary. It lets you "broad brush" a decent table. If fine tuning is needed, it's not hard to generate a traditional VE table from the Whittle curve.

Have fun,

Rob.
whittlebeast
Super MS/Extra'er
Posts: 2221
Joined: Tue May 04, 2004 8:20 pm
Location: St Louis
Contact:

Re: Re:Whittlebeast's RPMxMAP vs Duty function

Post by whittlebeast »

Robs, have you played with the Motec data I sent you. That was tuned with a traditional Speed Density VE table.

Andy
robs
Master MS/Extra'er
Posts: 564
Joined: Sun Jan 17, 2010 4:26 pm
Location: Sydney, Australia

Re: Re:Whittlebeast's RPMxMAP vs Duty function

Post by robs »

Andy, I only see links to png files in your e-mails to me. Poking around on your website I see a motec directory with some pretty big zip files. If you can point me at a suitable log, I'd be very interested to look at it. It does fit the "linear" pattern doesn't it?

Have fun,

Rob.
robs
Master MS/Extra'er
Posts: 564
Joined: Sun Jan 17, 2010 4:26 pm
Location: Sydney, Australia

Re: Re:Whittlebeast's RPMxMAP vs Duty function

Post by robs »

Added the RPM ramp to INI file and code today, but haven't tried it on the MS. Did grab a new laptop battery, so I should be able to give it a go tomorrow.

Looking at Andy's Motec log file, it's certainly different from the log files I'm used to. Assuming it's running speed-density (though it does have values for "Inlet Mass Flow"), I tried a few plots. As Andy says, plotting MAPxRPM against Duty gives the straightest looking line, sitting within about 2% of the line of best fit. However, depending on speed, a wiggle of 2% duty can translate into a much greater pulse width change than a 10% VE wiggle.

I did the same statistical model as yesterday's (per 100 rpm degradation came out at 0.02%. The mean square error came out at 18, so that'd be a typical VE error of a bit over +/-4. Not wonderful.

Here is a plot that might be of interest:
wve.png
That's plain old RPM vs MAP, with the colour coming from the "Engine Efficiency" variable (i.e. it's the VE table). I've overplotted it with various Whittle contours -- points with equal MAPxRPM . Certainly kills the "smooth ramp down as revs increase" theory. There is definitely a ridge on this landscape.

It is interesting experimenting with this stuff. We'll see how the code scrubs up in my old French limo. Don't expect it has much of a ridge on it.

Have fun,

Rob.
Post Reply