Page 1 of 4 1234 LastLast
Results 1 to 20 of 61

Thread: MAF Tuning Automated?

  1. #1
    Tuner in Training
    Join Date
    Jan 2021
    Posts
    48

    MAF Tuning Automated?

    Been working on a way to automate MAF tuning (Gen3 Coyote). Currently using excel to scale period and lbs./min. for MAF size changes and then to analyze logs to fine tune the MAF transfer function. What I need now is some more data to refine the automation and test to see if it works well with different size MAFs and different setups. Esentially excel corrects the MAF data using the trims, then filters the data to take out noise, then estimates a curve, and outputs the new tune in a format that can be loaded into both VCM Editor and the new periods for VCM Scanner.

    Need:
    Stock MAF size
    New MAF size
    Stock MAF transfer (ECM 44317 MAF Airflow vs. Period, or equivalent)
    Log with the following PIDS:
    RPM
    Mass Airflow
    Mass Airflow Period
    Short Term Fuel Trim Bank 1
    Short Term Fuel Trim Bank 2
    Long Term Fuel Trim Bank 1 (if active)
    Long Term Fuel Trim Bank 2 (if active)

    snip1.jpgsnip2.jpgsnip3.jpg
    Last edited by 61unicoyote; 12-05-2024 at 01:59 PM.

  2. #2
    Tuner in Training
    Join Date
    Jan 2021
    Posts
    48
    I get it, no one has time to post some data. I went ahead and took a log from a recent post. With a push of the button the MAF transfer function was fine tuned to be smoother and a closer fit.

    If anyone wants to be a guinea pig, post your info.
    Attached Images Attached Images

  3. #3
    Senior Tuner
    Join Date
    Jan 2013
    Location
    Hawaii
    Posts
    2,134
    Put this effort into tuning the speed density models.
    Its what smoothes and cleans up the noise of the MAF sensor and helps with anticipation and adaptation. Pretty much why Ford made it so it can do what a MAP sensor normally does.

    The goal with the MAF sensor transfer is to get it close enough and not pull your hair out trying to model inperfect air flow past the sensor.n You shouldnt need such an elaborate scheme to achieve this.

  4. #4
    Tuner in Training
    Join Date
    Oct 2024
    Posts
    10
    I have a 2006 Mustang GT with the stock MAF and throttle body + a CAI. There doesn't seem to be a MAF Period channel for this generation unless I'm missing something. I can give you RPM/Mass Airflow Volts/STFT Bank 1/LTFT Bank 1 (exhaust leak in the Bank 2 manifold, useless to log as it throws everything off by 5-10%). I'm doing some testing this weekend so let me know if you're interested and I'll set up a few logs. My MAF is pretty well dialed in but curious to see the program you've put together!

  5. #5
    Tuner in Training
    Join Date
    Oct 2024
    Posts
    10
    Murf, can you explain what you mean? I've been slowly dialing in my Load with Failed MAF table and have been kind of curious about the effects of Cylair Anticipation/Filtering/Adaptation. 80% of the time I get reproducible results and the other 20% I feel like the PCM is fucking with something. And it's hard to turn MAF filtering off because the acceleration is so jerky that it skews log results that way.

  6. #6
    Tuner in Training
    Join Date
    Jan 2021
    Posts
    48
    Quote Originally Posted by murfie View Post
    Put this effort into tuning the speed density models.
    Its what smoothes and cleans up the noise of the MAF sensor and helps with anticipation and adaptation. Pretty much why Ford made it so it can do what a MAP sensor normally does.

    The goal with the MAF sensor transfer is to get it close enough and not pull your hair out trying to model inperfect air flow past the sensor.n You shouldnt need such an elaborate scheme to achieve this.
    Thanks for the encouraging words Murfie! You're reading my mind. My next project was what I call AutoSpark. It will take the log and look for knock data that is within a user defined distance of the mappoint and output a recommended knock retard amount for load and RPM. Drafted up a file and here is what the current output screen looks like. Top matrix is number of counts that meet multiple user defined criteria/filters. The lower matrix is the amount of knock retard logged in that zone.

    Hoping that much of my work on this will translate directly to SD tuning...next to come. If anyone is interested in the knock/spark "AutoSpark" development, I can post up which PIDS to log.
    Attached Images Attached Images

  7. #7
    Tuner in Training
    Join Date
    Jan 2021
    Posts
    48
    Quote Originally Posted by Black_Sunshine View Post
    I have a 2006 Mustang GT with the stock MAF and throttle body + a CAI. There doesn't seem to be a MAF Period channel for this generation unless I'm missing something. I can give you RPM/Mass Airflow Volts/STFT Bank 1/LTFT Bank 1 (exhaust leak in the Bank 2 manifold, useless to log as it throws everything off by 5-10%). I'm doing some testing this weekend so let me know if you're interested and I'll set up a few logs. My MAF is pretty well dialed in but curious to see the program you've put together!
    Definitely, Black_Sunshine (love White Zombie)> It will use either bank or both depending on which "switch" the user flips. Post up your log and tune.

  8. #8
    Tuner in Training
    Join Date
    Jan 2021
    Posts
    48
    Quote Originally Posted by murfie View Post
    Put this effort into tuning the speed density models.
    Its what smoothes and cleans up the noise of the MAF sensor and helps with anticipation and adaptation. Pretty much why Ford made it so it can do what a MAP sensor normally does.

    The goal with the MAF sensor transfer is to get it close enough and not pull your hair out trying to model inperfect air flow past the sensor.n You shouldnt need such an elaborate scheme to achieve this.
    Murfie: Do you have any log files I can use where you logged the needed PIDs for SD tuning. Want to try some ideas on it.....thanks!

  9. #9
    Quote Originally Posted by 61unicoyote View Post
    Hoping that much of my work on this will translate directly to SD tuning...next to come.
    Speed Density is much more difficult to accomplish. I assume you intend to make a tool that would generate inputs into the HPT Speed Density calculator, that will likely not work well (albeit maybe slightly better on NA cars versus EcoBoost).

    I spent more time than I care to admit trying to generate a better approach to SD tuning; to generate a decent curve you need to fit the actual equation being used in the code, not just a standard polynomial fit (I don't think that equation was shared directly on this forum but I could be wrong). Excel won't do it natively but I did manage it via python. At the moment I don't see a way to circumvent the user needing to have an extremely solid grasp of the underlying logic, but maybe someone can think of something I haven't. If anyone is interested, I can gladly infodump a more detailed explanation of what I'm talking about.

  10. #10
    Advanced Tuner
    Join Date
    Sep 2022
    Location
    Clearwater FL
    Posts
    410
    Id be interested. I think SD tuning is one of the topics many people don't know everything about. I sure don't.

  11. #11
    I have a 2014 mustang engine here if it would help with your research i can take some logs for you. Your project looks awesome and i appreciate your work, looking forward to seeing where this leads as it could end up being an awesome little collection of tuning automation tools. I was actually working on something similar for dodges as that its my favorite to work on but i had put it on the back burner, now you just fueled my creative flame and im going to get working on that again. Let us know how your project turns out, im excited to see the development of the tool.

    If you need help i could probably remake it in python and create a full standalone program with a GUI.
    Last edited by moesmopar; 01-11-2025 at 12:19 PM.

  12. #12
    Quote Originally Posted by Rob@HPTuners View Post
    Speed Density is much more difficult to accomplish. I assume you intend to make a tool that would generate inputs into the HPT Speed Density calculator, that will likely not work well (albeit maybe slightly better on NA cars versus EcoBoost).

    I spent more time than I care to admit trying to generate a better approach to SD tuning; to generate a decent curve you need to fit the actual equation being used in the code, not just a standard polynomial fit (I don't think that equation was shared directly on this forum but I could be wrong). Excel won't do it natively but I did manage it via python. At the moment I don't see a way to circumvent the user needing to have an extremely solid grasp of the underlying logic, but maybe someone can think of something I haven't. If anyone is interested, I can gladly infodump a more detailed explanation of what I'm talking about.
    please info dump

  13. #13
    Tuner in Training
    Join Date
    Oct 2024
    Posts
    10
    Ack, I forgot about this! Here's a 23 minute drive with MAF volts , MAF AD counts, all the fuel trims and a bunch of other stuff (used it to dial in spark tables). MAF housing is the stock 05-09. If anyone wants to critique the tune as well be my guest, it's an in-progress E40 frankenstein tune between BAMA, '08 Bullitt and '10 GT

    Hell yeah, that album is a classic and she's been "Black Sunshine" to anyone who's asked since 2008

    2006 Mustang GT E40 Tune.hpl
    2006 Mustang GT E40 Tune in progress.hpt

  14. #14
    Tuner in Training
    Join Date
    Jan 2021
    Posts
    48
    Quote Originally Posted by Rob@HPTuners View Post
    Speed Density is much more difficult to accomplish. I assume you intend to make a tool that would generate inputs into the HPT Speed Density calculator, that will likely not work well (albeit maybe slightly better on NA cars versus EcoBoost).

    I spent more time than I care to admit trying to generate a better approach to SD tuning; to generate a decent curve you need to fit the actual equation being used in the code, not just a standard polynomial fit (I don't think that equation was shared directly on this forum but I could be wrong). Excel won't do it natively but I did manage it via python. At the moment I don't see a way to circumvent the user needing to have an extremely solid grasp of the underlying logic, but maybe someone can think of something I haven't. If anyone is interested, I can gladly infodump a more detailed explanation of what I'm talking about.
    That was my first thought, to develop a tool that would generate inputs to the calculator. Is the issue with that related to whether the calculator will spit out useful quad terms?

    The only equations I've seen are those "theoretical" equations in the discussion on the SD sticky. I think we would all like to learn more about SD. infodump please!

  15. #15
    Senior Tuner veeefour's Avatar
    Join Date
    Oct 2016
    Location
    Poland
    Posts
    2,006
    Quote Originally Posted by Rob@HPTuners View Post
    Speed Density is much more difficult to accomplish. I assume you intend to make a tool that would generate inputs into the HPT Speed Density calculator, that will likely not work well (albeit maybe slightly better on NA cars versus EcoBoost).

    I spent more time than I care to admit trying to generate a better approach to SD tuning; to generate a decent curve you need to fit the actual equation being used in the code, not just a standard polynomial fit (I don't think that equation was shared directly on this forum but I could be wrong). Excel won't do it natively but I did manage it via python. At the moment I don't see a way to circumvent the user needing to have an extremely solid grasp of the underlying logic, but maybe someone can think of something I haven't. If anyone is interested, I can gladly infodump a more detailed explanation of what I'm talking about.
    Well SD calc works Rob but there are quirks especially when you want to change multiple columns.

    We developed a good way to tune SD that includes HPT calc as a viewer only. Works quite good. Not additional tool is needed IMHO, just less plp trying to make shortcuts.
    Last edited by veeefour; 01-12-2025 at 02:57 AM.

  16. #16
    Advanced Tuner
    Join Date
    Sep 2022
    Location
    Clearwater FL
    Posts
    410
    Quote Originally Posted by veeefour View Post
    Well SD calc works Rob but there are quirks especially when you want to change multiple columns.

    We developed a good way to tune SD that includes HPT calc as a viewer only. Works quite good. Not additional tool is needed IMHO, just less plp trying to make shortcuts.
    It works well if you use the 2D model to adjust values. Then use the 3D to view it like you were saying.
    The calculator does weird shit if you input a number it doesn't like.

  17. #17
    Senior Tuner
    Join Date
    Jan 2013
    Location
    Hawaii
    Posts
    2,134
    Quote Originally Posted by 61unicoyote View Post
    Murfie: Do you have any log files I can use where you logged the needed PIDs for SD tuning. Want to try some ideas on it.....thanks!
    Id have to dig through some old computer backups to find logs for you. Kind too busy with work, and too tired when not working for that right now. sorry. If I recall there was someone I was chatting with in one of these threads and they were posting logs with the data, and I was tring to walk them through how to collect better data and better coeffecient terms. I dont recall how it ended.

    Quote Originally Posted by Rob@HPTuners View Post
    Speed Density is much more difficult to accomplish. I assume you intend to make a tool that would generate inputs into the HPT Speed Density calculator, that will likely not work well (albeit maybe slightly better on NA cars versus EcoBoost).

    I spent more time than I care to admit trying to generate a better approach to SD tuning; to generate a decent curve you need to fit the actual equation being used in the code, not just a standard polynomial fit (I don't think that equation was shared directly on this forum but I could be wrong). Excel won't do it natively but I did manage it via python. At the moment I don't see a way to circumvent the user needing to have an extremely solid grasp of the underlying logic, but maybe someone can think of something I haven't. If anyone is interested, I can gladly infodump a more detailed explanation of what I'm talking about.
    Please info dump and explain what you are talking about. Because...

    "The parameters air offset, air slope, and air quad
    represent the conventional non-blow-through curve 204 and
    can be calibrated by a least squares fit of the engine data."
    (which excel can do,The polynomial trendlines in charts use least squares based on a QR decomposition method like the LINEST worksheet function ( http://support.microsoft.com/kb/828533 ). A second order or quadratic trend for given (x,y) data could be calculated using =LINEST(y,x^{1,2}))

    Thats directly from the Ford patent, Its fits with the tables HPT editor allows us to change, and it isn't as complicated as it sounds. So it is as easy as collecting the data points and fitting a polynomial curve to the points collected, well the bulk of it is with the exception of finding where the data says the engine has gone into blow through operation where it changes to the blow through slope. Its also not like HPT editor gives much else to change for correcting the SD that isnt mentioned in the "Method for determining and compensating engine blow-through air" patent that describes all this.

    The push back ratio which handles the IVC events effect on the MAP is based of the air slope found from fitting that polynomial curve. So as long as you are collecting accurate data and getting a good fit curve, out side of the blow through conditions, the rest of the logic you are talking about should just work out through the mapped points HDFX system.

    The exhaust pressure scaling for the overlap window should be handled by having an accurate throttle body model and MAF transfer to agree upon what the barometric pressure is. Some cars even come with barometric pressure sensors and Im sure it would use the sensor data and the models just for diagnostic checks.

    Its a time consuming process of holding things at steady states while you work through each MP and RPM that puts a lot of stress and wear on an engine to collect the amount of data needed to get every quad, slope, and offset. There's nothing thats going to simplify that out side of locking the cams in place and eliminating the IMRC/CMCV. Tuning MAP sensor based cars this long process is required to get an accurate air load value for correcting fueling error. Tuning MAF cars is far far quicker, simpler, and easier.
    Last edited by murfie; 01-12-2025 at 05:23 PM.

  18. #18
    Tuner in Training
    Join Date
    Jan 2021
    Posts
    48
    Quote Originally Posted by murfie View Post
    Id have to dig through some old computer backups to find logs for you. Kind too busy with work, and too tired when not working for that right now. sorry. If I recall there was someone I was chatting with in one of these threads and they were posting logs with the data, and I was tring to walk them through how to collect better data and better coeffecient terms. I dont recall how it ended.
    No worries, I’ve been reading some of your other SD posts and am getting a good idea how to automate the sorting and regression process similar to the Autospark tool I’m working on. I’ll look closer for a usable log to run through the automation tool (iterative sort and regress).

    If anyone has a log with external map, please post.
    Last edited by 61unicoyote; 01-12-2025 at 06:18 PM.

  19. #19
    Advanced Tuner
    Join Date
    Sep 2022
    Location
    Clearwater FL
    Posts
    410
    Quote Originally Posted by murfie View Post
    Id have to dig through some old computer backups to find logs for you. Kind too busy with work, and too tired when not working for that right now. sorry. If I recall there was someone I was chatting with in one of these threads and they were posting logs with the data, and I was tring to walk them through how to collect better data and better coeffecient terms. I dont recall how it ended.



    Please info dump and explain what you are talking about. Because...

    "The parameters air offset, air slope, and air quad
    represent the conventional non-blow-through curve 204 and
    can be calibrated by a least squares fit of the engine data."
    (which excel can do,The polynomial trendlines in charts use least squares based on a QR decomposition method like the LINEST worksheet function ( http://support.microsoft.com/kb/828533 ). A second order or quadratic trend for given (x,y) data could be calculated using =LINEST(y,x^{1,2}))

    Thats directly from the Ford patent, Its fits with the tables HPT editor allows us to change, and it isn't as complicated as it sounds. So it is as easy as collecting the data points and fitting a polynomial curve to the points collected, well the bulk of it is with the exception of finding where the data says the engine has gone into blow through operation where it changes to the blow through slope. Its also not like HPT editor gives much else to change for correcting the SD that isnt mentioned in the "Method for determining and compensating engine blow-through air" patent that describes all this.

    The push back ratio which handles the IVC events effect on the MAP is based of the air slope found from fitting that polynomial curve. So as long as you are collecting accurate data and getting a good fit curve, out side of the blow through conditions, the rest of the logic you are talking about should just work out through the mapped points HDFX system.

    The exhaust pressure scaling for the overlap window should be handled by having an accurate throttle body model and MAF transfer to agree upon what the barometric pressure is. Some cars even come with barometric pressure sensors and Im sure it would use the sensor data and the models just for diagnostic checks.

    Its a time consuming process of holding things at steady states while you work through each MP and RPM that puts a lot of stress and wear on an engine to collect the amount of data needed to get every quad, slope, and offset. There's nothing thats going to simplify that out side of locking the cams in place and eliminating the IMRC/CMCV. Tuning MAP sensor based cars this long process is required to get an accurate air load value for correcting fueling error. Tuning MAF cars is far far quicker, simpler, and easier.
    Interpolate, interpolate, interpolate... Lol

  20. #20
    Quote Originally Posted by murfie View Post
    Please info dump and explain what you are talking about.
    I'll do my best. Just to be clear, this is meant as an addendum/clarification to the groundwork that was already done on this topic, not an effort to invalidate or discredit it. Maybe some of this stuff is already known, so apologies if I infer that it wasnt

    1) The software does provide the quad/slope/offset/etc. and in that sense, you're 100% correct that you have everything you need to calibrate this model. If anything, it's the SD calculator that I take potential issue with (but with absolutely no disrespect meant towards those who designed it).

    2) The equation. Yes the patent suggests a second order polynomial, but it does not explicitly say that it's y=ax^2+bx+ c. In this, case the code suggests that it isn't. Steven calls this "orthogonal" but I can't remember if the actual equation was shared on the forum (that might be a confidentiality thing, so I'll double check). The patent might also have a more vague version of this equation, I can't remember. But in any case, the X/Y relationship is slightly different than if you were to fit a standard quadratic equation in excel.

    3) The pushback ratio. You might be the first person I've seen make mention of this. It's based off the slope and the maximum trapped aircharge, but it plays an important role on the calculation of in-cylinder aircharge, and I disagree that it "just works" provided that you generated a decent quadratic curve. I had written a tool to execute the OEM code almost verbatim to what's on the PCM, and I noticed that changes to the maximum trapped aircharge line were not affecting the in-cylinder airmass past the point where the polynomial curve intersects (leaving blowthrough out of the picture for now just to keep things simpler). I'll attempt to explain but I'm sorry if I over or undershoot the level of detail.

    First, a couple of groundrule definitions:
    - I'm leaving exhaust manifold pressure correction out of this for now for further simplicity. EcoBoost and NA calculate this differently and in some cases it can and should be considered an entirely separate model.
    - Maximum trapped aircharge (AIR_C) is effectively the engine displacement adjusted for the environmental density corrections, the HDFX maximum load multiplier, and possibly exhaust manifold pressure (I can't remember where or when that factors in).
    - Blowthrough logic is disabled (recalculating in-cylinder airmass is a much higher priority and there probably needs to be a separate discussion about what blowthrough does throughout the logic anyway).

    I believe the current consensus is that at the point where the curve intersects with the maximum trapped aircharge line, we clip the in-cylinder aircharge at the maximum aircharge and calculate blowthrough airmass as the difference of the blowthough slope and the maximum trapped aircharge line. The problem is that the in-cylinder aircharge is always multiplied by the inverse of the pushback ratio (the assumption being that air that was "pushed back" is no longer in the cylinder). That seems frustrating because now it seems as if we need to keep track of another variable, except for the fact that the pushback ratio is already explaining the proportion between the slope and the max aircharge line, and this logic ultimately ends up cancelling itself out.

    So, we can refine it to say that we're looking for the intercept of the polynomial curve and the slope (instead of maxairchg), UNLESS the slope exceeds maximum aircharge, in which case the pushback ratio is 0 and we clip to the max aircharge line. Easy peasy, except now our slope is multivariate, because depending on the source of our collected data points, the slope can provide either: a very accurate linear fit to the data above our intersect point, OR, a very accurate fit to the polynomial data below that point, but not both. What I've been doing in my own personal calibration attempts has been prioritizing the polynomial in idle/cruise areas and prioritizing the slopes in higher rpm/boost areas, and it's worked out quite well (meaning, I can produce a curve that goes through the exact aircharge/load point that I intended).

    There's more to get into but that's probably a good basis for initiating discussion.
    Last edited by Rob@HPTuners; 01-13-2025 at 07:21 AM.