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

Re: Re:Whittlebeast's RPMxMAP vs Duty function

Postby robs » Thu Jan 19, 2017 9:10 pm

Built and e-mailed.

Have fun,

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

Re: Re:Whittlebeast's RPMxMAP vs Duty function

Postby ol boy » Thu Jan 19, 2017 9:11 pm

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, MS2extra 3.4.x_ish
ol boy
Super MS/Extra'er
 
Posts: 1211
Joined: Mon Sep 10, 2007 3:06 am
Location: Tucson, Az

Re: Re:Whittlebeast's RPMxMAP vs Duty function

Postby ol boy » Thu Jan 19, 2017 9:44 pm

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, MS2extra 3.4.x_ish
ol boy
Super MS/Extra'er
 
Posts: 1211
Joined: Mon Sep 10, 2007 3:06 am
Location: Tucson, Az

Re: Re:Whittlebeast's RPMxMAP vs Duty function

Postby ol boy » Thu Jan 19, 2017 9:49 pm

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, MS2extra 3.4.x_ish
ol boy
Super MS/Extra'er
 
Posts: 1211
Joined: Mon Sep 10, 2007 3:06 am
Location: Tucson, Az

Re: Re:Whittlebeast's RPMxMAP vs Duty function

Postby ol boy » Tue Mar 28, 2017 9:19 am

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, MS2extra 3.4.x_ish
ol boy
Super MS/Extra'er
 
Posts: 1211
Joined: Mon Sep 10, 2007 3:06 am
Location: Tucson, Az

Re: Re:Whittlebeast's RPMxMAP vs Duty function

Postby whittlebeast » Tue Mar 28, 2017 9:27 am

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

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

Andy
User avatar
whittlebeast
Super MS/Extra'er
 
Posts: 2154
Joined: Tue May 04, 2004 8:20 pm
Location: St Louis

Re: Re:Whittlebeast's RPMxMAP vs Duty function

Postby seijirou » Fri Jun 09, 2017 9:16 pm

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/
seijirou
Helpful MS/Extra'er
 
Posts: 131
Joined: Sun Dec 12, 2010 6:51 am
Location: New Braunfels, TX

Re: Re:Whittlebeast's RPMxMAP vs Duty function

Postby robs » Sat Jun 10, 2017 5:14 pm

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.
robs
Master MS/Extra'er
 
Posts: 518
Joined: Sun Jan 17, 2010 4:26 pm
Location: Sydney, Australia

Re: Re:Whittlebeast's RPMxMAP vs Duty function

Postby whittlebeast » Sat Jun 10, 2017 8:02 pm

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
User avatar
whittlebeast
Super MS/Extra'er
 
Posts: 2154
Joined: Tue May 04, 2004 8:20 pm
Location: St Louis

Re: Re:Whittlebeast's RPMxMAP vs Duty function

Postby seijirou » Sat Jun 10, 2017 8:45 pm

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: 131
Joined: Sun Dec 12, 2010 6:51 am
Location: New Braunfels, TX

Re: Re:Whittlebeast's RPMxMAP vs Duty function

Postby seijirou » Sat Jun 10, 2017 8:50 pm

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!
seijirou
Helpful MS/Extra'er
 
Posts: 131
Joined: Sun Dec 12, 2010 6:51 am
Location: New Braunfels, TX

Re: Re:Whittlebeast's RPMxMAP vs Duty function

Postby subwoofer » Sun Jun 11, 2017 12:40 am

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
subwoofer
Super MS/Extra'er
 
Posts: 879
Joined: Sat Apr 30, 2011 12:34 pm
Location: Sandefjord, Norway

Re: Re:Whittlebeast's RPMxMAP vs Duty function

Postby robs » Sun Jun 11, 2017 5:01 pm

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.
robs
Master MS/Extra'er
 
Posts: 518
Joined: Sun Jan 17, 2010 4:26 pm
Location: Sydney, Australia

Re: Re:Whittlebeast's RPMxMAP vs Duty function

Postby whittlebeast » Sun Jun 11, 2017 5:34 pm

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
User avatar
whittlebeast
Super MS/Extra'er
 
Posts: 2154
Joined: Tue May 04, 2004 8:20 pm
Location: St Louis

Re: Re:Whittlebeast's RPMxMAP vs Duty function

Postby robs » Sun Jun 11, 2017 5:52 pm

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.
robs
Master MS/Extra'er
 
Posts: 518
Joined: Sun Jan 17, 2010 4:26 pm
Location: Sydney, Australia

Re: Re:Whittlebeast's RPMxMAP vs Duty function

Postby ol boy » Thu Aug 31, 2017 9:29 am

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, MS2extra 3.4.x_ish
ol boy
Super MS/Extra'er
 
Posts: 1211
Joined: Mon Sep 10, 2007 3:06 am
Location: Tucson, Az

Re: Re:Whittlebeast's RPMxMAP vs Duty function

Postby ol boy » Sat Sep 02, 2017 4:09 pm

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, MS2extra 3.4.x_ish
ol boy
Super MS/Extra'er
 
Posts: 1211
Joined: Mon Sep 10, 2007 3:06 am
Location: Tucson, Az

Re: Re:Whittlebeast's RPMxMAP vs Duty function

Postby ol boy » Fri Sep 29, 2017 2:16 pm

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, MS2extra 3.4.x_ish
ol boy
Super MS/Extra'er
 
Posts: 1211
Joined: Mon Sep 10, 2007 3:06 am
Location: Tucson, Az

Re: Re:Whittlebeast's RPMxMAP vs Duty function

Postby ol boy » Mon Oct 30, 2017 9:29 pm

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, MS2extra 3.4.x_ish
ol boy
Super MS/Extra'er
 
Posts: 1211
Joined: Mon Sep 10, 2007 3:06 am
Location: Tucson, Az

Re: Re:Whittlebeast's RPMxMAP vs Duty function

Postby robs » Mon Oct 30, 2017 11:22 pm

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.
robs
Master MS/Extra'er
 
Posts: 518
Joined: Sun Jan 17, 2010 4:26 pm
Location: Sydney, Australia

Previous

Return to MS2/Extra Development

Who is online

Users browsing this forum: No registered users and 2 guests