Stephe Posted January 16 Share Posted January 16 so too my knowledge the FG doesn't have a maf sensor but i saw a (MAF LEACKAGE) pid and thought ill log it and yer i have a value in my log. my question is where is it getting a value from if i dont have the maf Quote Link to comment Share on other sites More sharing options...
hjtrbo Posted January 16 Share Posted January 16 A whole bunch of maths I reckon. 🤷 Quote Link to comment Share on other sites More sharing options...
Roland@pcmtec Posted January 17 Share Posted January 17 On 1/16/2024 at 6:37 PM, Stephe said: so too my knowledge the FG doesn't have a maf sensor but i saw a (MAF LEACKAGE) pid and thought ill log it and yer i have a value in my log. my question is where is it getting a value from if i dont have the maf There is an inferred MAF value based on TPS and load. It is like alpha-N, very primitive and highly inaccurate for boosted applications in anything but steady state. Basically used when the MAP fails as as last resort. It is also where the inferred load value in the "Tuning Correction" table comes from, it is an alpha-N correction table. You can actually tune an NA vehicle with ITBs with no MAP sensor via these tables if you wanted to. 2 Quote Link to comment Share on other sites More sharing options...
Stephe Posted January 17 Author Share Posted January 17 thanks for the help roland Quote Link to comment Share on other sites More sharing options...
Roland@pcmtec Posted January 17 Share Posted January 17 Just for reference here is the Alpha N correction map. in a B series vehicle. Note that the axis is Inferred load, not actual load (as that would cause an infinite loop due to load being calculated via speed density). The inferred load is then calculated via this table. Obviously on a Turbo car your MAP (and hence load) is not static for a given TPS/RPM unless engine load/speed and practically everything else is static, so this is going to be highly inaccurate during transients and especially on turbo applications. Essentially a fail safe and a fudge factor for pressure drop across the TB/oscillations/reversion due to cam angles. Primitive and why Ford moved away from this in the Tricore platform (US vehicles 11+) where they model a delta pressure across the TB instead and blend the MAF signal with the estimated MAP/Speed Density calculation. 2 Quote Link to comment Share on other sites More sharing options...
Stephe Posted January 18 Author Share Posted January 18 9 hours ago, Roland@pcmtec said: Just for reference here is the Alpha N correction map. in a B series vehicle. Note that the axis is Inferred load, not actual load (as that would cause an infinite loop due to load being calculated via speed density). The inferred load is then calculated via this table. Obviously on a Turbo car your MAP (and hence load) is not static for a given TPS/RPM unless engine load/speed and practically everything else is static, so this is going to be highly inaccurate during transients and especially on turbo applications. Essentially a fail safe and a fudge factor for pressure drop across the TB/oscillations/reversion due to cam angles. Primitive and why Ford moved away from this in the Tricore platform (US vehicles 11+) where they model a delta pressure across the TB instead and blend the MAF signal with the estimated MAP/Speed Density calculation. Thanks for the info, just to be clear, are the numbers in the table lambda? Thanks Quote Link to comment Share on other sites More sharing options...
Puffwagon Posted January 18 Share Posted January 18 If you look at the picture you can see that the numbers are a multiplier. Quote Link to comment Share on other sites More sharing options...
Stephe Posted January 18 Author Share Posted January 18 13 hours ago, Puffwagon said: If you look at the picture you can see that the numbers are a multiplier. Forgive my ignorance, would you mind explaining some more please? Quote Link to comment Share on other sites More sharing options...
Puffwagon Posted January 19 Share Posted January 19 I didn't expand your quote so I only saw the top table. The values in the top table are a multiplier of a speed density map and the bottom table is inferred load. 1 Quote Link to comment Share on other sites More sharing options...
Roland@pcmtec Posted January 19 Share Posted January 19 Yes what Puff said. The Z axis output is inferred load (the y axis of tuning correction) and the Z axis output of tuning correction is a multiplier to the speed density slope table. Effectively it will fudge the VE for a given throttle/rpm position to account for reversion/oscillations or any other variances in airflow that are due to mechanical characteristics. They should never be more than 5-10% at an absolute maximum. Any more suggests a mechanical issue, eg lack of fuel or poor pipework placement, unequal runners causing oscillations at certain frequencies etc. This is covered in more detail here Quote Link to comment Share on other sites More sharing options...
Stephe Posted January 19 Author Share Posted January 19 1 minute ago, Roland@pcmtec said: Yes what Pufd said. The Z axis output is inferred load (the y axis of tuning correction) and the Z axis output of tuning correction is a multiplier to the speed density slope table. Effectively it will fudge the VE for a given throttle/rpm position to account for reversion/oscillations or any other variances in airflow that are due to mechanical characteristics. They should never be more than 5-10% at an absolute maximum. Any more suggests a mechanical issue, eg lack of fuel or poor pipework placement, unequal runners causing oscillations at certain frequencies etc. Ok, I get the theory behind what you said there, thankyou. To be able to get to the nitty gritty of poor pipework placement, does the datalogger have the ability to log something like that? Thanks Quote Link to comment Share on other sites More sharing options...
Puffwagon Posted January 19 Share Posted January 19 If you wanted to test the efficiency of a particular section of intake or exhaust pipe, you would place a pressure sensor in either end and log the pressure delta. It will work for vacuum as well as boost or back pressure. These pressures can be inserted into the data log with the DLP8 that most people already use for afr logging. This is already commonly used in a workshop setting as a tool for diagnosing intake and exhaust efficiency. 1 Quote Link to comment Share on other sites More sharing options...
Stephe Posted January 19 Author Share Posted January 19 38 minutes ago, Puffwagon said: If you wanted to test the efficiency of a particular section of intake or exhaust pipe, you would place a pressure sensor in either end and log the pressure delta. It will work for vacuum as well as boost or back pressure. These pressures can be inserted into the data log with the DLP8 that most people already use for afr logging. This is already commonly used in a workshop setting as a tool for diagnosing intake and exhaust efficiency. Ok, thanks, we will look into that Quote Link to comment Share on other sites More sharing options...
Roland@pcmtec Posted January 22 Share Posted January 22 On 1/19/2024 at 11:54 AM, Stephe said: Ok, I get the theory behind what you said there, thankyou. To be able to get to the nitty gritty of poor pipework placement, does the datalogger have the ability to log something like that? Thanks Log Boost, MAP, RPM and load and you'll easily see if there is noise/oscillations on the signal. If it is bad enough you'll see the torque source go into OSC which is oscillation control, eg for manual cars where people stab the throttle in first gear causing the car to buck around. It will pull spark in the inverse direction to attempt to smooth the torque out. You can also see this with small turbo's that spool excessively fast. 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.