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 »

Built and e-mailed.

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 »

Awesome thanks

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.
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 »

Which email did you send it to? I haven't seen it 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.
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 »

Sorry, I found it


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.
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 »

Revive from the dead! I went back to this code revision. Now that I have a better handle on the injector dead time I want to give it another ago. The drive this morning we good. I'll keep on poking at it.

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 »

This screen shot is off a 450 HP +/- turbo drift car

http://www.nbs-stl.com/tuning/Turbo%20D ... APxRPM.png

Andy
seijirou
Helpful MS/Extra'er
Posts: 145
Joined: Sun Dec 12, 2010 6:51 am
Location: DFW, TX

Re: Re:Whittlebeast's RPMxMAP vs Duty function

Post by seijirou »

I stumbled upon a blog, which reminded me of this thread.

Granted I basically just skimmed both so I could be making a correlation here that doesn't exist. But Ford has done away with MAF and essentially gone back to speed density on their turbo vehicles (ecoboost) and at a glance with limited understanding it reads to me as if their method is essentially the same as the method proposed here.

Here's an excerpt to pique your curiosity...
Ford’s version of speed density is quite clever, ignoring volumetric efficiency and getting straight to the point, which is air mass....

Ford's method is based on the observation that for a given RPM, a plot of manifold pressure vs cylinder air mass lies on a straight line.
Anyway here is the blog. Scroll down to 8-12-12 and check out that post plus the one that follows. http://injectordynamics.com/articles/shelby-gt500/
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 pointing out the article, it was fun and informative. Not really the same as the method here.

Ford's approach still uses a 2-dimensional table of RPM vs MAP it's just that it gives you the air mass directly rather than VE. Any VE table could be converted into an air mass table (and vice versa) with no loss of information.

The method experimented with here uses a 1-dimensional table looked up by the product RPMxMAP (a later tweak added a constant n x RPM slope adjustment) to give the VE. It can only represent a very restricted subset of possible VE tables. The hope was that this subset would include the optimum and simplify tuning. I think it was easier to tune, but didn't get very close to optimal.

I don't think Ford's approach would be any easier to tune than the usual VE table -- it might have some benefits (or drawbacks) when it comes time to working out the injector pulse width.

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 »

It just happens that I was working on this concept today. The big issue is that it requires a division by RPM that painful to do in code. Here is how the logic flows.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Multiply MAP * RPM to get a Scaled function of Mass Air Flow.

Pass thru the MAP*RPM lookup curve to get Base Duty Cycle

Divide by RPM to get Base Pulse Width

Multiply by a RPM by MAP lookup table to have a Speed Density correction if needed. (Most motors would contain mostly 100 in most cells)

Multiply by a RPM by RPM lookup table to have a Alpha-N correction if needed. (Most motors would contain mostly 100 in most cells)

Multiply by Gamma (the air correction)

Multiply by the AE correction

Multiply by ReqFuel

And you get PW to send to the injector. The best part is most motors have the majority of the fuel tuning done on one simple curve.

Andy
seijirou
Helpful MS/Extra'er
Posts: 145
Joined: Sun Dec 12, 2010 6:51 am
Location: DFW, TX

Re: Re:Whittlebeast's RPMxMAP vs Duty function

Post by seijirou »

whittlebeast wrote:It just happens that I was working on this concept today. The big issue is that it requires a division by RPM that painful to do in code. Here is how the logic flows.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Multiply MAP * RPM to get a Scaled function of Mass Air Flow.

Pass thru the MAP*RPM lookup curve to get Base Duty Cycle

Divide by RPM to get Base Pulse Width

So this is over my head I'm sure but just on this bit and you mentioning the pain of dividing by RPM has me wondering.

Can you skip that division? If you can look up air mass from MAP * RPM, let's go straight from air mass to fuel mass?

I don't know the normal units so try to contain your laughter...

Let's say you're measuring 10lbs/ms of air.

Pass through the MAP*RPM lookup curve to get the target AFR antecedent and then divide the air mass by that. So you want 12:1 AFR. We have 10lb/ms divided by 12 = 0.8333 of fuel mass needed. (I embarrassingly realizing now that I'm not sure if 12:1 means 12 parts fuel to 1 part air for a total mass of 13 parts, or a total mass of 12 parts 1 part of which is air.. I'm going to go with the 2nd).

Okay our injector flow rate is say 0.04lb/ms. divide needed fuel mass by flow rate, 0.8333 / 0.04 = 20.8333 so we need 20.8333 milliseconds of injector.

I think the formula would then be Pulsewidth = (air mass lookup / AFR antecedent lookup) / fuel flow rate.

Okay if you want to know duty cycle you do have to divide by RPM, but I don't think megasquirt needs that number? Let tunerstudio crunch it.
seijirou
Helpful MS/Extra'er
Posts: 145
Joined: Sun Dec 12, 2010 6:51 am
Location: DFW, TX

Re: Re:Whittlebeast's RPMxMAP vs Duty function

Post by seijirou »

robs wrote:Thanks for pointing out the article, it was fun and informative. Not really the same as the method here.

Ford's approach still uses a 2-dimensional table of RPM vs MAP it's just that it gives you the air mass directly rather than VE. Any VE table could be converted into an air mass table (and vice versa) with no loss of information.

The method experimented with here uses a 1-dimensional table looked up by the product RPMxMAP (a later tweak added a constant n x RPM slope adjustment) to give the VE. It can only represent a very restricted subset of possible VE tables. The hope was that this subset would include the optimum and simplify tuning. I think it was easier to tune, but didn't get very close to optimal.

I don't think Ford's approach would be any easier to tune than the usual VE table -- it might have some benefits (or drawbacks) when it comes time to working out the injector pulse width.

Have fun,

Rob.
I see. I sort of understand, I'll read back through and see if I can get a better grip. Thanks for the clarification!
subwoofer
Super MS/Extra'er
Posts: 884
Joined: Sat Apr 30, 2011 12:34 pm
Location: Sandefjord, Norway

Re: Re:Whittlebeast's RPMxMAP vs Duty function

Post by subwoofer »

Andy: the division may be unnecessary if you can squirrel away a clock count for a revolution of the crankshaft. That count will be proportional to 1/RPM and only needs a single multiply to be useful.
Joachim
1974 Jensen-Healey
1990 VW Caravelle Syncro - running MS3+X
2014 Ford Fiesta EcoBoost
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, left out from your calculation is the injector dead time. While it's reasonable enough to say it belongs at the end -- just another correction step -- the thing is that dead time IS included in the MS2 logged pulse width. Your graphs from log files exclude all the other corrections, but not dead time. If a function truly fits the log file, it IS fitting the dead time. That's where I've run aground with this approach -- where is the voltage parameter?

Division isn't all THAT bad on the S12 -- 11 clock cycles (a smidge under 0.5usec) to divide a 32-bit by a 16-bit number. Subwoofer's suggestion is fine too, though the big difficulty is that, whether you track cpu cycles/rev or revs/cpu cycle, the range of engine revs is more than 20:1 (redline:cranking speed) -- that eats more than 4 binary digits. The S12 processor is great with 8-bit numbers and pretty handy with 16-bits, but cumbersome with 32-bits. Those 4+ bits that engine speed requires just to look after magnitude mean that 16-bits are not enough. The hard thinking is in working out when and how to efficiently step up to 32-bits to hold precision, and to step back to 16-bits for fast execution.

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 »

I am working James on this and I am sure he has a good grip of all the issues. I would find it interesting to test the theory on a live motor.

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,

You couldn't do better than that. I'm all for experimentation, especially if it makes tuning easier. I did have a crack at it, but maybe my own scepticism got in the way. Hope it goes better with James's effort and to read about it here in due course.

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 »

So............. Got my car put back together in July, it was down since April with a broke crank(don't ask..). I reloaded this code and gave it another go (3rd times the charm), Set the rpm scaling factor to zero and reduced my dead time by 100us, from 900us to 800us. I seem to get good EGO correction across the RPM range at the same RPMxMAP value. I'll keep poking at it.

I like the thought of RPMxMAP to g/s and shove it directly into the MAF math. The little bit of time I've spent inside a Ford EEC5 and EEC4, they have a max VE value curve that needs to be close to help the MAF math work out correctly. James mentioned pages ago that the one variable missing for RPMxMAP ==> MAF is VE. MegaTune had that nice VE table generator that would give you a VE table matching your inputted tq, rpm, hp ranges which should follow max torque curve. Desktop dyno200 is used often to generate a max VE curve and plugged into the EEC table.

Andy: is there anything posted on the work James is doing with this? The weather is cooling down a little so walking home is the ECU crashes is no big deal. :roll:
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.
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 »

Ran into another snag.. Vetrim tables dont work. I pulled the plugs and noticed that the outer 4 holes were fat while the inner 4 were lean. All 4 trim tables had garbage data in them. I fixed that but pw1 and pw2 always show the same pw. So for now i switched back to standard %baro.
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.
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 »

Take #3.. new idea. I have a Teensy3.2 receiving CAN messages. I can do RPMxMAP in 32 bit math and I'm logging it into a uSD card. The teensy has a 12 bit DAC output, so I took the 32bit RPMxMAP and divided it by 300 to get me under 4096 for 6000 rpm X 200 kpa max value. The DAC output is now tied to ADC7 (my old MAF input). Long story, longer... :roll: I'll have a 30 minute log from the ride home tonight and can convert fuel flow into airflow g/s and create a MAF trasfer curve to ADC7...

Yes.. RPMxMAP to analog for MAF input. I think I mentioned something like this many pages ago, just repurpose the MAF code using RPMxMAP as the voltage input into MAF transfer function.

I'll report back tonight or in the morning.

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.
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 »

Finally reporting back... Didnt quite work as planned. I could get good steady afr while cruising but increasing the load would reault in a big lean hole. My guess is the lack of VE values to sort out the airflow through the motor at different engine speeds. If i created a ve table with 100s and the top row and ramped them down and readjusted the maf curve it might work well. But this defeats the purpose of easy tuning. Have a straight maf line(rpmxmap) amd still have to adjust a ve table until correct.

If rob could enable the trim tables in the whittlebeast code i could give it a better go. I finally got the 4 injector channels worked out and the engine run really smooth now. All 8 plugs now show the same even fuel distribution and the wobble delta in my afr reading has narrowed quite a bit.

Let me know.

Hows that James mod coming?
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 »

I suspect you're right about the need for arbitrary VE settings and definitely agree that this does away with the benefit of easy tuning. Using trim tables suffers from the same problem doesn't it? Have to admit I'm a bit rusty on the MS2/Extra code now and not overly keen to burrow down and work out how to enable trim tables in the Whittlebeast "special", so maybe I'm just looking for excuses.

Still interested to hear how Andy and James have gone on this. It is a nice concept, even if I failed to make it do anything exciting.

Have fun,

Rob.
Post Reply