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

Post Reply
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 »

I've been grappling with the ini file for several hours. Not the easiest thing in the world to deal with. I felt like a break and thought I'd just reread everything in this thread. Several things I didn't get back then make sense now, so that's progress.

Looking at one of Andy's graphs shows a well tuned engine obeying the thin curve rule, but with multiple different AFRs along the way -- AFR doesn't just ramp cleanly up the curve. One of the other graphs had a rainbow effect as you looked along the curve, but that's because the colour and y axis were both %Duty.

So in the end, we just have to trust that the tuner has entered a reasonable AFR table. The software (probably using least squares) aims for the middle of the GEGO adjustments so there's a balance between + and -. The 2d AFR table is critical to the tune so this ends up behaving much more like VEAL than I had pictured earlier. All the same, it will be updating stripes of the VE table, and that has to converge on a decent tune much more quickly than VEAL.

Ryan: At this stage my plan is only to write tuning software; the firmware will behave exactly as it does now. I'm pretty sure the tuning software will need to allow for dead time when it calculates Duty% from PW. The basic autotune style flow I have in mind is:
  1. poll MS for variables
  2. display variables graphically and save to log file
  3. accumulate MAPxRPM, GEGO, PW (converted to Duty -- basically (PW-deadtime)*RPM [probably worth including nsquirts/alternating in case they get change]
  4. work out which control point(s) are affected by that MAPxRPM value and update their cumulative GEGO error value
  5. once a point's cumulative error gets above some threshold, calculate new Duty and derive VE values for all cells affected by that control point; send them to the MS. The VE would be derived as in the Perl script I posted earlier.
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, are you thinking the VE table will develop the same striping pattern as the MAPxRPM calculation table (for lack of a better name) showed?

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 think it will mirror the striping pattern of MAPxRPM. I have wrongly been thinking of it as oblique lines; they actually follow a hyperbola.

The output of the Perl script I posted earlier in this thread showed that the VE mirrored the values in the RPMxMAP array. Here it is again 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 
So, for example, wherever you have a 90000 for MAPxRPM, you have 36.7 for VE. I think I have the calculation right. Here's the crucial part of the Perl script that turns RPMxMAP through Duty% into the necessary VE value:

Code: Select all

 $duty = interp($rpm * $map);
 $pw = 1200 * $duty / $rpm;
 #
 # pw = req_fuel * map/100 * ve/100
 # therefore:
 $ve = 10000 * $pw / ($map * $req_fuel);
To put it all in one formula:

Code: Select all

ve = 10000 * 1200 * interpolate(RPMxMAP) / RPM / (MAP * req_fuel)
   = (12000000/req_fuel)*interpolate(RPMxMAP)/(RPMxMAP)
Since everything else is constant, the VE is fully determined by the value of RPMxMAP; there is no independent RPM or MAP component.

Unless I've messed up in the formula, this seems to be a direct consequence of the RPMxMAP->Duty% thin curve relationship.

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 wrote: Since everything else is constant, the VE is fully determined by the value of RPMxMAP; there is no independent RPM or MAP component.

Unless I've messed up in the formula, this seems to be a direct consequence of the RPMxMAP->Duty% thin curve relationship.

Have fun,

Rob.
So why fuss with some tuning scripts for TS when "we"(as in you code guys) could create a new fueling algorithm to replace %baro, alpha-n and speed density with "load"xrpm.

I'm sounding like a broken record..

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 »

You know Ryan, you're right.

Though I now think (again!) it belongs as an option inside speed-density rather than as an alternative. If this is just a substitute for looking up the VE table and we leave everything else in place (AFR target table, optional VE Trim table), that should be a pretty small change in the code. If anyone selects this option and tries VEAL, it won't do much for them, but it won't do much harm either -- unless (as I'm thinking) I store the 12 value MAPxRPM -> %Duty table in the (now unused) VE table flash page.

I think the hardest part (for me -- never done it before) will be getting the appropriate curve editor into the INI file.

I have a feeling the circles we've been going might at last have reached the centre.

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 »

See if I can help with the ini file

Took a bit to wrap my brain around the curve editor.

Curve=LoadRPM_curve "Load x RPM Duty Curve"
ColumnLable = "Load x RPM","Duty"
Xaxis = 0,{rpmhigh * 400}, 12
Yaxis = 0 , 100, 12
Xbins = matclt_flow, calcflow
Ybins = dutycycle1

The calcflow value might not be right. You'll have to sort out a gauge, I think. The value matclt_flow all ready is made up of load x rpm. I think it's times 100 though.

It looks like there are 12 (24 bytes) used for the old MAF correction curve that you might be able to use and leave standard MAF curve alone.

Page7,
mafv, 110, [64]
mafflow, 238 [64]

OR page5,
MAFFLOW, 960 [12]
matclt_flow, 1008 [6] "load x rpm" 100


**edit**
So dutycycle won't work as its a variable and not a constant with in the flash pages. Needs a different name and placed in a page taking up 12ish places.

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 »

I can help with Channels in TS. The only trick is I run TunerStudio Ultra Beta and I an not sure all of these tricks are in the normal release versions of TS.

http://www.nbs-stl.com/CRX/Custom%20Channel.PNG

The gauge in the middle has as the background gauge either Max Allowable DC or MAPxRPM, depending what I am looking for. For what we are doing here, I would have the two gauges scaled to run in sync. The background gauge would be MAPxRPM and the foreground one DC.

My data logs have MAPxRPM in the data log.

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 »

Thanks guys. Other things took over this afternoon, but I think I got more done this morning that I had expected. Here's where it stands:

Haven't actually tweaked the INI file yet, but the option will be in feature4_0VEtblsize. I have extended it to two bits [2:3] so you get 0:16x16, 1:12x12, 2:Whittle curve, 3:Invalid. I have opted for 12 control points, and the curve's duty values live in the same spot as the no longer needed veTable1; the corresponding load values (MAPxRPM/100) live in the likewise unneeded frpm_table1. I had to add a new interpolation function taking and returning unsigned integers. Will need to give some more thought to scaling -- I'm not scaling MAP at the moment (and it's in 0.1kPa units) so overflow is possible as it is. Could possibly make use of rev limits to scale according to the engine. Likewise with the MAP limits used by the AD conversion.

I have punted on secondary load tables and other stuff that made the 12x12 and 16x16 options really complex. This code just uses MAPxRPM, ignoring other fuel load settings. Probably leaves some dead options. AFAICT, the VE trim table option will still work -- I've never used one. From my quick look it appears to always be 16x16, even if your VE table is 12x12, which is a little odd.

Still to do is to turn the value from duty into VE -- looks like I can use the "Divider" constant to deal with # squirts etc. That's what I was up to when I got dragged away. Apart from that is the INI file juggling, pulling a MS out of one of the cars, finding where I've hidden the Stim, and giving it all a test. With a bit of luck we'll have Ryan stuck on the side of the freeway again for next weekend.

Have fun,

Rob.
P.S. Still builds too. Haven't run out of resources yet!
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 »

Had a decent idea overnight. I was a bit worried about whether there would be enough control to keep a stable idle.

My idea is to let the user keep a 12x12 VE table and put the curve control points (48 bytes) in the 112 bytes of free space where the 16x16 table would have been. If the idle falls within the first RPM band, use conventional VE metering, otherwise use the curve. I'll position things like that but, for now, we can try the curve based metering on its own. It will be pretty easy to add the special case for idle if need be.

Had some time for thinking, but no time for coding today. That's OK; efficient conversion of duty% to VE isn't all that simple.

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: How goes it? Yer done yet?

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 »

It's close Ryan. Here's the plot from the first Stim session:
first.png
Colours are in order of time; swept the RPM range up and down while gradually reducing MAP. Points at the bottom are where I accidentally hit the rev limit.

Two problems strike me:
The graph is thicker than I'd have expected -- this may be due to throwing out the last two digits of RPM and the last digit of MAP, but might be something else too.
Duty should get to 120%. The MS calcs for divider (whatever it's meant to be), alternating pulse, 2-stroke, number of cylinders, it's enough to set your head spinning. Anyhow, this appears to be a factor of 2 and I should be able to sort it out. Tomorrow, I hope.

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 »

Nice.. just for reference when I get to try this in the car my MAP can get to 200kpa at 6000 rpm.. will the math support this rpm and map level with out over flow?

We have several engines to build over the next few weeks. I can give this ago on those. Load is tps though. Max rpm of 7k

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 »

Rob, can you please post a standard MS data log of that test so I can open it up in MLV HD. I may be able to get to the source of the issue.

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 »

In theory you should be able to set the rpm and pull the MAP value up and down then go to the next rpm bin and repeat. Do that for the entire rpm range then look at the relationship.

Need a known good VE table though...

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, here is the log from that session; I've thrown in the msq, just in case I've done anything insane:
whit.zip
Ryan, the way the code is at the moment, it caters for a lot more than that: RPM/100 * MAP < 65,535 -- e.g. 20,000RPM x 300kPa gets you to 60,000. Mind you, allowing for this large range is what cost those low-order digits of RPM and MAP. Adding some complexity, it would be possible to scale RPM according to the rev limits and MAP to the MAP sensor limits which would mean only people with big boost and high speeds would have to put up with the current level of fuzziness.

On the question of the plane engines, I haven't catered for using TPSxRPM for the load at this stage. It wouldn't be hard to make a one-off for you to try, but it might be tricky to make it yet another user-configurable option sitting alongside the multitude of options MS already has.

Given the objective -- that one value of MAPxRPM should give one value of Duty* -- I'm not happy that the line is so thick. I'll do some off-Megasquirt C experiments to see if I can work out where the precision is being lost. A thought just occurred to me. I proved earlier that if one value of RPMxMAP equates to one value of Duty, it also equates to one value of VE. So plotting RPMxMAP vs VE1 from that log file might be interesting:
ve.png
That looks a bit more like a functional relationship+rounding error than the earlier graph. Would still like to thin it down if I can.

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, your EGO correction is coming in and messing with your head. Change the EGO authority to 0 and retest please.

Andy
Last edited by whittlebeast on Wed Oct 19, 2016 7:42 pm, edited 2 times in total.
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 »

I just sent a screen shot to Robs that is extremely promising. It appears that his code is spot on.
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 »

Good deal. I've been screwed by ego correction before. Not sure why it's turned on from a freshly installed firmware.

I chased a tune on a heavy fueled conversion for most of a day until I found ego correction was on and moving the fuel around.

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 »

Thanks for working that out Andy -- way better looking. Didn't think the default config enabled feedback. Would have probably taken me days to realise.

The result is promising and has pretty much settled the precision worries. It's not spot on though, and getting the target and output Duty values to match is still proving elusive.

Unfortunately, my brain isn't up to much today. Burglar alarm went off in the wee hours this morning. No burglar, but a ruined night's sleep.

I did another run with EGO authority zeroed (and somewhat different firmware from that previous run). Here it is plotted with the target duty curve. Shape looks about right; it appears to just need scaling down in y.
noego.png
Of course even with this code, it would be possible to empirically tune to the curve -- the values don't mean a whole lot anyway -- but I won't be happy with it until we get the values right. Maybe tomorrow...

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 »

What resolution for PW are you seeing for each step? My first numbers were 99.001 duty but that was with xxxx rpm X xx.x map and not rpm/100 * 90 [map].

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.
Post Reply