2018 Mustang Mapped Points not responding

[engineermike]

Folks, I've been trying to understand how the Mapped Points and Distances work in my 2018 Mustang 5.0. I've attempted to apply logic posted on the forum and the results never seem to correlate to logged data as they should.

In an attempt to establish understanding and demonstrate control, I changed all Mapped Points in Emissions Reduction, Fuel Economy, and Optimum Stability (tables 38222, 28223, and 38224, respectively) to 0's, top to bottom. Running the engine yielded the exact same behavior as before this change was made. Logs showed it using Mapped Points 12, 14, 15, and many others. I then changed the same 3 tables all to 1's and once again, no change in the logged Mapped Points used.

Could this be an error in the software? Or am I doing something grossly wrong?

Note: I did not disable any additional Mapped Points because the exercise was meant to prove that I can command specific Mapped Points with others being available/enabled.

Thanks in advance for any guidance.
Mike

[murfie]

Mapped points are a representation of cam positions, to provide information for the rest of the calibration. Its what gives the illusion of high control variability, because the cam phasers are not in perfect control. Change the commanded cam angle and the mapped points weight will change.
In 15+ IMRC position is also a factor, mostly open/closed, but also transition from open to close is usually done with 3 or 4 points depending on RPM.

Can you force OP mode or use the manual override and command specific cam positions at all? If you can do that, then I would say there isn't a problem with HPT editor, with the exception of maybe a missing table.

[blackbolt22]

Folks, I've been trying to understand how the Mapped Points and Distances work in my 2018 Mustang 5.0. I've attempted to apply logic posted on the forum and the results never seem to correlate to logged data as they should.

In an attempt to establish understanding and demonstrate control, I changed all Mapped Points in Emissions Reduction, Fuel Economy, and Optimum Stability (tables 38222, 28223, and 38224, respectively) to 0's, top to bottom. Running the engine yielded the exact same behavior as before this change was made. Logs showed it using Mapped Points 12, 14, 15, and many others. I then changed the same 3 tables all to 1's and once again, no change in the logged Mapped Points used.

Could this be an error in the software? Or am I doing something grossly wrong?

Note: I did not disable any additional Mapped Points because the exercise was meant to prove that I can command specific Mapped Points with others being available/enabled.

Thanks in advance for any guidance.
Mike

Unless you adjusted the IMRC settings to match your new settings, I'm thinking your settings would use MP0 at startup and idle but once you started driving it would blend/use the IMRC Mapped Points. I'd love to see a log of the effect of your settings to see if it does what I think it would.

[engineermike]

@murfie, are you saying the cam timing determines the mapped point, not vice versa?

@blackbolt22, my MP0 is not enabled so it is never used.

[murfie]

A mapped point is the cams parked at one set of angles mapping the SD, spark, and torque values for that point. It doesnt command the cams where to go, just defines other things for when the cams are at or near that position.

The cams are commanded to move through a path of distance, ideally single points or on direct lines between two points as thats the easiest thing to describe optimal SD,spark, and torque with.
The snap to point and snap to line are what determine this control distance, but its not very clear on how the tables go about doing that, the axis are ?'s, descriptions are not there, so changing control of the different modes with it is limited to modifying the actual cam angles of the mapped points(38150/38151) to change where these lines run from and to.

You've probably seen the 2d graphs of intake position vs exhaust position. This is snap to point/snap to line to make SD/Spark/Torque determination less dynamic like the cams actually move from the nature of the phasers control not being perfect. Those lines are only defined, not commanded, by an array of mapped points the VCT mode can use(what you tried to change). When the cams are commanded to go from one position to another or just aren't controlled well enough, letting them into positions the line/point arrays are not close to, the weight can no longer snap to a point or line to follow, so it just "bends", and distributes to other points that are available and defined closer to where the cams actually are. When a line bends it takes three points or more to define. Essentially trying to predict an entire 2D plane that the cams can travel through with a single squiggly bent line, usually doesn't give you as accurate SD,spark, torque. So you want your cams to stay on defined points or lines (that we can't easily define due to HPT editor limitations).

Both the distance and the mapped points defining it need to line up and agree with each other in the calibration for things to make sense. Other wise you are looking at actual cam angles vs mapped point weight and trying to determine how a complex algorithm has determined when and how much to allow a line to bend, and if that was actually enough to truly define the actual path the cams positions took. Most find it easiest to force it in to OP mode and set up some cam angles for it to transition through and watch the mapped point weight from those changes. Then, with a feel for different angles giving different weights, move on to manipulating the existing snap to point/ line and distance/ arrays structure directly from 38150 and 38151, and redefining SD,spark, torque mapped points for their new cam angles, if ever.

Another words if you see your car using 50% mp14 and 50% mp15%, then 100% mp16, then 75% mp17 25% mp18 as it goes up in the RPM range with a certain load or throttle input, you can leave that the same and still command different cam angles with different values in 38150 and 38151. You would still adjust the SD, spark, and torque in those mapped points to optimize them for the new cam angles.

[blackbolt22]

@murfie, are you saying the cam timing determines the mapped point, not vice versa?

@blackbolt22, my MP0 is not enabled so it is never used.

If you set those tables to "0" like you said here it's trying to use MP0 ----> "tables 38222, 28223, and 38224, respectively" <----- If you disabled MP0 you will get unexpected behavior. Those are the mapped point tables to tell the system which mapped point to use! On one hand you're saying use only MP0 and on the other you disabled it. What else can the PCM do?

[engineermike]

@murfie, that?s going to take some processing time. I went ahead and made my own IVC vs EVO plot of the Mapped Points then added the snap to lines. Point 0 falls right on top of point 15 so it makes sense that with 0 not being enabled it would use 15. Point 1 is by itself and also not enabled so perhaps it was blending surrounding points. I need to check my thinking against more log data to see if it proves correct for each case.

@blackbolt22, the cal is from a mainstream tuner and works fine as it is. If I understand the logic correctly, it commands locations of mapped points that arent enabled. But the log data returns points that are enabled. I was testing commanding 0 to verify it would consistently return 15 in every case.

Thanks for the responses, guys.

[blackbolt22]

@blackbolt22, the cal is from a mainstream tuner and works fine as it is. If I understand the logic correctly, it commands plants of mapped points that arent enabled. But the log data returns points that are enabled. I was testing commanding 0 to verify it would consistently return 15 in every case.

Thanks for the responses, guys.

Oh I wasn't saying anything was wrong with the cal.

Your explanation there about disabled MPs and how the log returns enabled MPs actually fits better than my original understanding. I always thought that if a MP was targeted yet disabled... it just blended and interpolated the enabled points to achieve the same outcome. Very interesting concept. I will have to do some testing on that with my next ghost cam tune lol

[engineermike]

Ok I applied to my newfound logic to several log snapshots and it has consistently been accurate in emissions reduction, fuel economy, optimum stability, drivability, and WOT. Thanks for helping me understand.

Two odd observations:

My cal has 10 snap-to lines defined. However, 7 of them are between disabled points. The only ones between enabled points are at evc 0, so all the lines are colinear and coincident with the x axis.

In looking at a stock 2018 5.0 cal, I can see how the commonly used transitions across loads and speeds would pretty much keep you on the snap-to lines. However, I don?t see where the stock 2018 cal commands Mapped Points above 9. However, 13 of the Mapped Points above 9 have coincident points 9 or below. So it may command 6 but it?s the same as 18. If it commands 0 it?s the same as 14.

I still don?t quite get the snap-to points. I?ve logged mine blending 12 and 14 even though both are snap-to points. It did not pull nearby points into the mix though.

[blackbolt22]

Ok I applied to my newfound logic to several log snapshots and it has consistently been accurate in emissions reduction, fuel economy, optimum stability, drivability, and WOT. Thanks for helping me understand.

Two odd overservations:

My cal has 10 snap-to lines defined. However, 7 of them are between disabled points. The only ones between enabled points are at evc 0, so all the lines are colinear and coincident with the x axis.

In looking at a stock 2018 5.0 cal, I can see how the commonly used transitions across loads and speeds would pretty much keep you on the snap-to lines. However, I don?t see where the stock 2018 cal commands Mapped Points above 9. However, 13 of the Mapped Points above 9 have coincident points 9 or below. So it may command 6 but it?s the same as 18. If it commands 0 it?s the same as 14.

I still don?t quite get the snap-to points. I?ve logged mine blending 12 and 14 even though both are snap-to points. It did not pull nearby points into the mix though.

I believe the upper half of the MPs 14 to 26 are only in use when the IMRC is open, when the car is in OP mode (your foot is into the throttle). As such it wouldn't make sense to use them for Best Fuel Economy, etc.

As far as snap to points: they add a sort of gravity to the MP so that if the angles are close enough they latch on. If they are a little far then it could certainly blend to the next best MP.

[superman07]

I have my car following mapped points pretty well, but it doesn’t seem to respond to the fuel economy and fuel economy drive load thresholds. So far no matter what I use in both tables it is really slow to come out of best economy mode. Load doesn’t work, maybe there are missing tables for pedal position like PE.

[4wheelinls1]

A mapped point is the cams parked at one set of angles mapping the SD, spark, and torque values for that point. It doesnt command the cams where to go, just defines other things for when the cams are at or near that position.

The cams are commanded to move through a path of distance, ideally single points or on direct lines between two points as thats the easiest thing to describe optimal SD,spark, and torque with.
The snap to point and snap to line are what determine this control distance, but its not very clear on how the tables go about doing that, the axis are ?'s, descriptions are not there, so changing control of the different modes with it is limited to modifying the actual cam angles of the mapped points(38150/38151) to change where these lines run from and to.

You've probably seen the 2d graphs of intake position vs exhaust position. This is snap to point/snap to line to make SD/Spark/Torque determination less dynamic like the cams actually move from the nature of the phasers control not being perfect. Those lines are only defined, not commanded, by an array of mapped points the VCT mode can use(what you tried to change). When the cams are commanded to go from one position to another or just aren't controlled well enough, letting them into positions the line/point arrays are not close to, the weight can no longer snap to a point or line to follow, so it just "bends", and distributes to other points that are available and defined closer to where the cams actually are. When a line bends it takes three points or more to define. Essentially trying to predict an entire 2D plane that the cams can travel through with a single squiggly bent line, usually doesn't give you as accurate SD,spark, torque. So you want your cams to stay on defined points or lines (that we can't easily define due to HPT editor limitations).

Both the distance and the mapped points defining it need to line up and agree with each other in the calibration for things to make sense. Other wise you are looking at actual cam angles vs mapped point weight and trying to determine how a complex algorithm has determined when and how much to allow a line to bend, and if that was actually enough to truly define the actual path the cams positions took. Most find it easiest to force it in to OP mode and set up some cam angles for it to transition through and watch the mapped point weight from those changes. Then, with a feel for different angles giving different weights, move on to manipulating the existing snap to point/ line and distance/ arrays structure directly from 38150 and 38151, and redefining SD,spark, torque mapped points for their new cam angles, if ever.

Another words if you see your car using 50% mp14 and 50% mp15%, then 100% mp16, then 75% mp17 25% mp18 as it goes up in the RPM range with a certain load or throttle input, you can leave that the same and still command different cam angles with different values in 38150 and 38151. You would still adjust the SD, spark, and torque in those mapped points to optimize them for the new cam angles.

Hi Murfie,

Do you know how the mapped points are scheduled when the array points to an inactive mapped point. In the Whipple tune the array is calling upon mapped points that are not active, there is a connection however, is there a missing array or is the line bending to the nearest cam points? When I have built SC tunes without IMRC I use the lower mapped points as it makes the scheduling easier to follow.

Mapped Pts.PNG

[engineermike]

I’m not Murfie but I’ve completely reconfigured the way my Whipple cal manages the mapped points. It is true that the Whipple cal only commands disabled mapped points. The cams go to the angles of the disabled mapped points but it doesn’t use the spark, torque, or sd data. Instead, it does a weighted average of all the enabled points. It’s a screwy way to do it but it works well enough I suppose. Ive reconfigured mine to only command enabled points or on a snap-line between enabled points, even at wot.