Jump to content

MAP/BAP pressure ratio as fuel table load axis


Dan Bailey

Recommended Posts

Hi there,

It has been pointed out to me, and after doing some thinking and mathsing - seems evident that using MGP as the fuel table look up axis is not an entirely accurate way of doing that look up for a VE/PW value, albeit usually being "close enough" in most cases.

This is because you are just using a fixed offset from the ambient air pressure, when infact if you are operating in a different ambient pressure situation - the whole density has changed, meaning that the table you use as a part of how to effectively estimate air mass needs to be treated as running on a different scale... not just by using an offset.

Funnily enough, as MAP pressure gets closer to BAP the current fuel calculation gets more "accurate" - but particularly as MAP gets lower when BAP is different to the environment the car was tuned to, the error from what it "should be" looking up gets bigger and bigger... to the point where in full vacuum you could be doing look ups to quite incorrect load zones for the environment.  

The logical load axis should be MAP/BAP as opposed to the current MAP-BAP - which presumably would flatten the table a little more, as well as make mixtures more consistent in different barometric conditions.  I of course accept that I could just have my wires crossed, but I'm just trying to communicate as clearly as possible what has recently come up and couple explain a few things.  

Obviously any error is not enormous, we've been using this for YEARS with decent results - but you know, ignorance is bliss and now knowing that perhaps it could or should be better is pretty hard to ignore.

Any input, corrections, questions, or changes if it makes sense would be massively appreciated :)

Thanks,

Dan

[edit - I could SWEAR I put this in the Wishlist forum, though it seems to have shown up in G4+... not sure how I did that wrong, but I can't delete or change it.  Sorry!!]
 

Edited by Dan Bailey
Link to comment
Share on other sites

Why not link to the original discussion?  https://www.facebook.com/groups/737420992943719/permalink/1530326236986520/

I'm fairly sure there's more to Link's modelled fuel equation than what Andy is talking about for his adap stuff.  When you setup a "VE" fuel table with adaptronic it doesn't take into account the fuel type or fuel pressure for instance.  Link/Vipec and Adaptronic are the main platforms I work on.

Link to comment
Share on other sites

I havent yet done any worked examples to prove it to myself but it would need more than a facebook post to give me the motivation to do that.  I have seen enough logs from our aircraft/pikes peak/race to the sky, etc customers to make me reasonably comfortable that our equation works quite well for most users.  As JMP says it sounds like some of the logic has been taken out of context to how MGP is used in the modelled fuel equation.  

That is not to say it cant be improved and I am open to passing good suggestions on to the engineering team if you can provide some good compelling logs that show an example of a run that could have been improved by using MAP/BAP as a table axis.

For your info, there is an old post here that explains some of the logic of the MGP axis (sorry it got a little corrupted when we changed forum platforms, you will have to ignore the random "A" symbols): http://forums.linkecu.com/index.php?/topic/2609-map-or-mgp-for-fuel-table/&do=findComment&comment=32813

Link to comment
Share on other sites

You can see the point that the discussion is getting at by substituting something other than WOT in the below (from the forum link you gave). I think I have this right...:

If we had our fuel table spanned with MAP (rows at 40, 50 and 60 (-60, -50 and -40 MGP) 80, 90 and 100). At sea level, [x% throttle] WOT we would be in the 50100 kPa row.  Lets say that row has 30 as the fuel number.  Lets say we are delivering 3.000 ms pulse width. We close the throttle until we get 40 80 kPa MAP.  The fuel delivered is reduced by the use of MAP in the fuel equation to 80% of what we had at WOT (now 2.400 ms).  But at the same time we have throttled the motor and altered its volumetric efficiency (maybe by altering the intake dynamics). This means to achieve the correct AFR we need a smaller fuel table number in the 40 80 kPa row (eg 25).  So the actual fuel delivered is 2.000ms.

Now we drive to the top of a big hill where the atmospheric pressure is 80 kPa. At [x% throttle] WOT the MAP reading will be [40] 80 kPa [note - my assumption - 50kpa at bottom of hill becomes 40kpa at top of hill]. So, we would want 80% of the fuel required at sea level (100 kPa). So that would be 2.400 ms fuel. But as [x% throttle] puts us in the [40] 80 kPa row and the fuel table number is 25 there we only get 2.000 ms fuel. This is 66% of what we had at sea level, not 80%. Uh oh, we are a bit lean!!!

If instead we had used MGP on the fuel table load axis, [x% throttle] would be in the [-50] 0 row at sea level and [-40] the top of the hill. This is not great great because at [x% throttle] we have the same VE at the bottom and top of the hill, and so we are not in the same row in the VE table at the bottom and top of the hill although at WOT its great. Our number 30 would be in the fuel table at our [x% throttle] WOT row (-50 0 kPa MGP) at sea level but say 35 in the fuel table for -40 0 kPa MGP at altitude and the delivered fuel at sea level would be MAP = 100 kPa, table = 30 = 3.000 ms and our delivered fuel at high altitude would be MAP = 80 kPa, table = 35 30 = 2.800 2.400 ms fuel. Not Exactly 80% the fuel at sea level!

Although its looking up a table row that is rich and not lean like a MAP lookup would be in para 2.

Of course you might be doing something else in the fuel equation to address this and/or this may be practically of no consequence. 

Note: Using IMAP/baro when in boost would imply an MGP axis could look up a fuel table row that is too low lean (eg at 80kpa barometric pressure, MAP 180, MGP 100 (like MAP 200 at sea level), MAP/baro *100 = 225). I suspect this does not reflect your experience with aircraft / pikes peak / race to the sky.

Edited by CamB
added note, then edited it. Even "low" isn't the right word
Link to comment
Share on other sites

Please excuse me if i miss understand - first paragraph . 50 kpa row with 3ms delivered . Then you throttle the engine back to 40 kpa and get 2.4 ms delivered . It then goes on to say - at the same time we have throttled the motor to 40 kpa - and now you need 2.0 ms delivered .Why?- Sorry but what am i missing ? 

Link to comment
Share on other sites

If you had "30" as the number in the fuel table for both 50kpa and 40kpa rows, assuming the fuel mode chosen is Load=MAP then the fuel the ECU calculates will be multiplied by 40/100 rather than 50/100 as MAP is applied against the fuel table numbers. The simplified (traditional fuel) equation would be something like:

Master Fuel (20ms) * fuel table number /100 * MAP / 100  

However when the (hypothetical) engine was tuned, the 40kpa row had "25" in it as the VE is lower. So the relative change in MAP is applied against 2.5ms (which corresponds to "25"). 

The question is whether using MGP as a load axis  for the fuel table (which fixes a problem with using MAP looking up the wrong fuel table number with a change of barometric pressure) is a less useful basis to lookup fuel at < WOT. There may be a difference between theoretical and practical too...

 

Edited by CamB
Link to comment
Share on other sites

I havent yet done any worked examples to prove it to myself but it would need more than a facebook post to give me the motivation to do that.  I have seen enough logs from our aircraft/pikes peak/race to the sky, etc customers to make me reasonably comfortable that our equation works quite well for most users.  As JMP says it sounds like some of the logic has been taken out of context to how MGP is used in the modelled fuel equation.  

That is not to say it cant be improved and I am open to passing good suggestions on to the engineering team if you can provide some good compelling logs that show an example of a run that could have been improved by using MAP/BAP as a table axis.

For your info, there is an old post here that explains some of the logic of the MGP axis (sorry it got a little corrupted when we changed forum platforms, you will have to ignore the random "A" symbols): http://forums.linkecu.com/index.php?/topic/2609-map-or-mgp-for-fuel-table/&do=findComment&comment=32813

Cheers Adam, yeah I am pretty familiar with how the Link does it's base fuel calculations - or at least with how the documentation states it does it, and have been tuning them for a few years now so thus far I think I am reasonably familiar with it though absolutely accept that I don't know EXACTLY how it works so understand I could be incorrect.  All the documentation and logging seem to indicate that the MGP value recommended to be used in the fuel table look up is "MAP - BAP" and that is what I am suggesting isn't ideal.  

Just to be clear here, I'm talking about looking up a value from the fuel table - NOT the fuel calculation done after the fact.  I understand the Fuel=MAP part of the fuel equation later down the line deals with baro etc correction, but if the VE or PW value looked up from the main fuel table in the first place is incorrect then it's just doing good calculations on the wrong data.  Also, I realise that in most cases people probably won't have any real issue - however to show where and how there could/probably would be issue if you are being pedantic I threw together a graph showing how far off the "MGP" look up would be from what it SHOULD be looking up if you had a properly corrected load look up.  

This example assumes a car was tuned on a "typical" day at sealevel, say 1013ish hPa - the X-axis is to show different ambient pressures, each line represents manifold absolute pressure and on the Y-axis you can see the error (+/- x kPa) that the fuel table look up would be for that given MAP and BAP combination.   It shows that in any situation the baro pressure is exactly that every load point will be on point, however the more baro correction involved, the greater the error.  

Unfortunately I don't have the ability to take a car with a Link in it for a drive to Taupo and back to Wellington to get logging to prove the theory, a bit of a shame as timed right this low coming through could really offer some pretty sweet barometric pressures if you were at a decent altitude :)

I've also attached a screenshot of some code from one of the freely available MoTEC M1 Packages showing they do the same thing as what I am suggesting/requesting.  Obviously, if this change happens this can't be a "fix" as any fuel map done using gauge pressure would need the fuel table to be remapped - it would be a different kind of load option.

Hope this explains what I'm getting at and why, let me know if there is anything clearly wrong with what I'm saying - especially if the Link actually does something to deal with this.   


Cheers :)

 

MoTEC M1 Fuel.png

Fuel table Lookup error.png

Edited by Dan Bailey
Link to comment
Share on other sites

  • 1 month later...

While I don't have a working vehicle to test this, hasn't stopped me thinking about it. If one was absolutely keen to try IMAP/baro as a load axis for the fuel table table, could one:

- set up a GP PWM on an Aux which outputs a frequency being IMAP / baro * 100 (i.e., one axis MAP, one axis baro, table populated appropriately)

- feed the GP PWM into a DI

- use that DI for the fuel table axis

I plan to set mine up with an Aux linked into a DI anyway, as I have spare and there are other things that you can do.

It does occur to me an easy way to implement this in the software might be to create a math channel (I am pretty sure I have seen this as a feature request anyway), and make that available for the fuel table axis.

 

(Edit) Also to the discussion above I think Motec's "engine load normalised" is similar to Link's "Load (Abs)" (and not the same as IMAP / baro), which is good (probably) for ignition, but not fuel as it effectively requires VE as an input.

 

Edited by CamB
Link to comment
Share on other sites

I still havent had time to do this justice but I did take a look at a few logs where BAP varied greatly through the run and measured lambda stays near target over large elevation changes.  So for now although I cant argue that there isnt possibly a better option out there for fuel table load axis I can say the present system seems to do the job well even in far more extreme environmental variations (aircraft) than our typical users will ever see.

Nice workaround though Cam - you will just need to find a very big hill...

Link to comment
Share on other sites

Thanks for the follow up.

I am probably less worried about MAP vs baro and more interested to try it on a turbo car where it's MAP / Exhaust Mani Pressure as this could take into account backpressure change on a turbo charged car (i.e. Further flattening the fuel table). Of course if one isn't actually changing turbos this is arguably a fairly limited value add, but still ... it's got me curious.

Link to comment
Share on other sites

  • 11 months later...
On 6/7/2017 at 12:04 AM, CamB said:

Thanks for the follow up.

I am probably less worried about MAP vs baro and more interested to try it on a turbo car where it's MAP / Exhaust Mani Pressure as this could take into account backpressure change on a turbo charged car (i.e. Further flattening the fuel table). Of course if one isn't actually changing turbos this is arguably a fairly limited value add, but still ... it's got me curious.

MEGA late responding to this, I had an insane year last year but this stuff still hasn't left my mind.

Agreed, the MAP/EMAP pressure ratio option would be quite nice too and I have in my head added that as a wishlist item at some point in the past and wasn't well received - though I've asked for a few weird things ;)     A couple of things which come to mind as an advantage for IMAP/EMAP aside from what you already listed, is if people are playing with things which manipulate the exhaust flow to improve spool etc.  Variable geometry turbos, quick spool valves, compressed gas injection into the turbine etc which would result in the engine's VE changing for a given RPM/MGP cell.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...