MP9 Causing Major ETC Spike and TQ Error

[CCS86]

MP9 is giving me fits!

I am running MP0, 1, 2, 3, 4, 9, OP on my blown 2012 GT.

My torque / inverse tables are GT tables, rescaled for a 1.6 max load. These have worked the best for me.

As I smoothly roll on the pedal, almost always, when it blends through MP9, the throttle surges open, causes an IPC torque error, closes back down, then blends into OP and smoothly opens to WOT.

I cannot understand what is causing this and feel like I have crossed all my T's and dotted my I's. I must be missing something!

I made an infographic to show as much relevant info as I can:

MP9 mfr.jpg

It shows the inverse tables for MP3 MP9 and OP, which is the blend that is occuring.

For this RPM and pedal position, my torque request should be 410 ft lbs.

Using MP9's inverse table, that should equate to an air load of 1.00.

So, why then is it winding the throttle open to a max of 1.272 load and 480 ft lbs? It just doesn't make sense to me!!!

[murfie]

Correlates with your power enrichment. Have you tried raising or lowering the pedal position the PE comes on at?

[CCS86]

Correlates with your power enrichment. Have you tried raising or lowering the pedal position the PE comes on at?

I haven't tried that specifically for diagnosing this issue.

Looking closely, to me it seems like even though the PE enable points to the peak of the ETC spike, the throttle had been deviating for a good amount of time before PE.

If I draw a line of what the ETC should have done (scooping out MP9's apparent contribution), it looks like it isn't related to PE:

MP9 mfr2.jpg

[CCS86]

Here's the actual log segment and my layout:

[CCS86]

Before reverting back to the rescaled GT TQ/Inv tables, I had chased the TQ error with the "conventional" method of reducing the load value in the inverse tables, where the error happens.

I would scale the whole row down by say 0.9, then interpolate the other rows to maintain the stock linear relationship between load and TQ. Then I used the new inverse values to calculate a matching TQ table.

This did have the effect of reducing the IPC TQ errors, but had side effects. The reported TQ goes up every time you do this. By the time TQ errors disappeared, the indicated torque was over 700 ft lbs. Also, the ETC behavior became "angry". Where I used to get smooth flowing motion, it moved in a much more ragged way after the inverse reductions.

[murfie]

Load is determined by MAF and fuel trims.
Load determines indicated Torque from the model. The model assumes MBT and stoic fuel.
From actual spark and fuel, actual engine brake torque is estimated.

MAF goes into TB model. This works as a feed forward to correct desired load. The DD table is used to determine torque request. This is how your desired torque and desired load relationship is established.

You need to get DD table and TB model torque/load request closer to your engine brake torque and actual load. Determine if you think it's TB model, DD table, or torque tables. It could also just be your MBT spark tables relationship to your borderline tables making the ECU estimate engine torque wrong.

[CCS86]

Load is determined by MAF and fuel trims.
Load determines indicated Torque from the model. The model assumes MBT and stoic fuel.
From actual spark and fuel, actual engine brake torque is estimated.

MAF goes into TB model. This works as a feed forward to correct desired load. The DD table is used to determine torque request. This is how your desired torque and desired load relationship is established.

You need to get DD table and TB model torque/load request closer to your engine brake torque and actual load. Determine if you think it's TB model, DD table, or torque tables. It could also just be your MBT spark tables relationship to your borderline tables making the ECU estimate engine torque wrong.

Good point on the spark advance!

I haven't really edited the MP9 spark values, from the FDPX values... but there is definitely a bigger delta between borderline and MBT in MP9 versus the neighboring MPs.


MP9-mfr-spark.jpg

I'll try closing that gap and see what happens...

[CCS86]

After looking more carefully at the stock GT MP9 spark tables, they also have a fairly big delta between borderline and MBT, during this condition (~10*), so I don't think that is the issue:

Stock-MP9-spark.jpg

I tried reducing the MBT spark values and running again, and it didn't make much of a difference.

[CCS86]

Last night I dug back in with a different approach. I was wondering if MP9 specifically has something out of "alignment", or if it's just a hard job to blend torque requests as it moves from fuel econ to OP...

MP7 seemed a better candidate to blend my VCT between MP3/4 and OP, so I disabled MP9 and enabled MP7.

At first, it seemed like the same exact issue, but as the car warmed up, things improved.

Here, the car had been running for only about 5 minutes, with ECT at 177*. Just as it crosses load of 1.0, at 2800rpm, there is a giant TQ error. It had been solidly in MP7 for a while, with no real VCT action before or after. It is a very localized error:

MP7-cold-spike.jpg


Once the car warmed up a bit more, the ETC action was smoother and the TQ errors much smaller. This shot shows back to back roll-ons, one lower gear / lower speed, and one higher. Similar RPMs :

ETC-spike.jpg


What temperature based modifier might explain this change?

I still don't understand what the IPC TQ error is checking against.

I did discover a very interesting pattern in these TQ errors. Just before each IPC TQ error spike, my spark source briefly triggers 'tip-in det. control'. But, there are a tone of instances where I hit that spark source without an ETC bobble of TQ Error, so I don't think they are related.

I can also observe that a "clean" roll-on and a "lumpy" one, both take the same path through the predicted angle table (Effective area vs ETC vacuum), so I don't think there is a global fault in the TB tables.

[murfie]

The hard job is to get your desired load to follow the MAF when the bypass closes. It happens when MAP is only a few inHg below barometric, so your load is usually right around 1.0. It causes a spike as the airflow is taken over by the supercharger from the engine.

The throttle body model along with a NA like DD table does not do a good job at handling the rapid airflow changes, If the torque request doesnt increase at that point, the rapid increase in airflow causes it to close the throttle to get the ETC vacuum up to satisfy the airflow. Its easier to leave WOT start above the pedal position the bypasses closure happens at. This allows you to modify your driver demand to match the engine torque changes easier. Once your torque request follow the engine torque at different pedal positions you can lower it back down and let it be controlled by the throttle, mainly for safety if a TP sensor fails or something.

SD has temperature compensation so the calculated MAP could be helping the ETC vacuum once its warmed up.

As an example this is a stock DD table vs the one from a Whipple calibration. Notice how the first 45% looks like the stock curves, From then on its rapidly climbing with RPMs. Their WOT start is 50%. Think about this table as torque at calculated load of 100% or the maximum torque the engine can make at that pedal position and RPM. The torque can be lower when airflow is lower than 100% for the given throttle position, but not higher. Calculated load comes from SD and calculated MAP. The SD model does a very good job of determining this from MAF, even at the stock values with just a modified calculated max.
Stock vs whipple.PNG

[CCS86]

I agree the the bypass valve on a PD blower presents some challenges for the PCM. I made an orifice tube for my bypass line, to smooth the transitions a bit.

I have already gone through tuning speed density for MP0, 1, 2, 3, 4, 9 & OP using my physical MAP sensor (now I have to do MP7). This was done the clean way of flashing tunes that locked out the correct set of cam angles for each, instead of trying to pry out blended data. The end result is that my calculated MAP is very close to actual in all driving conditions, which improved fueling quite a bit.

I'm not convinced that the bypass shutting is the cause of this surge though. If it was, I would expect a predictable curve for ETC opening (roughly exponential), but a surge in the MAF curve as the bypass closes, then the ETC closing in response. Instead we see MAF follow the ETC in my logs, with the throttle physically opening too fast and causing the surge. When I am driving, I can see the surge in my boost gauge, and it usually happens when I am already at ~5 psi of boost, not just crossing through 0.

Here is a log from a drive last night. Again, TQ errors were far more significant before full operating temp. This screenshot shows very similar pedal action, at similar RPM, one with ECT at 164* and the other 183*. The cooler side got a giant TQ error (270 ft*lb), and warmer only 50 ft*lb. The only real differences I see are the coolant temp and the fact that the warm one got into PE. This lack of consistency make it very hard for me to understand how the IPC system is working:

Spike-no-spike.jpg


Then from the same drive, another roll-on with absolutely no TQ error, and very smooth throttle action... WTF??? What am I missing to differentiate between these?


no error.jpg

[murfie]

https://patents.google.com/patent/US6279531B1/en

How your pedal request is translated into a torque request.

https://patents.google.com/patent/US5241855A/en

How your engine brake torque is estimated, as the first one refers to this one a lot.

Error is determined through a feedback loop between the desired torque and engine estimated torque giving a second intermediate torque, which then goes back into the loop as desired. A third torque to compensate for friction and extra load is applied to give the final torque request. You mainly are concerned with the desired and estimated feedback loop.

[CCS86]

Thanks murfie, I'll dig into those when I get some time to focus.

If you want, PM me your email address. I wanted to send you an excel sheet I wrote to calculate TQ from INV and INV from TQ. I think it is more advanced than other worksheets that have circulated.

On this issue I'm having that seems far worse when the engine is cooler: I found one table that could possibly have an effect like this:

VE-correction.jpg

What are your thoughts on that? It has stock GT values in here, but I'm suspicious that with the PD blower on top, these corrections might be excessive. I'm not even sure how you would go about using logged data to correct this table, aside from arbitrarily bringing the values closer to 1 and seeing if it helps.

[murfie]

Yeah that is the SD table I was referring too. The multiplier would increase the maximum VE and calculated load until about 150* ECT, you are already not commanding high enough torque, so it calculating the engine is making more isn't going to help. Setting it to 1's in your warm up area would be a test, but not exactly the right way to fix it if that helped. You would probably have to fix it through torque loss tables, if you need to once you get your desired torque and load correct.

[CCS86]

I'm already doubting that table could cause this. Using the ACT in my log, a 50* change in ECT would cause only a 1% VE correction here.

Hmm, I haven't seen torque loss tables in my tune. I was wondering if they just weren't added by HPT. Can you give me ECM #'s?

[murfie]

In 2015+ they are 9298 and 9301.


You should compare your DD table to a stock one. Your values at part throttle at 3000 RPM are actually lower than stock. I suspect you are looking at the wrong part of your DD table. Instead of calculating it from %, I think there is something under transmission that you can log to get it directly. If not ask support for that as well.

Id work off a DD table starting like this.
[ATTACH=CONFIG]86668[/ATTACH

]PD DD vs stock.PNG

[CCS86]

Hmm, I don't have either of those. What are the names of them? I'll see if HPT can add something similar.

I know my DD table is significantly different than stock. I have taken a lot of time crafting it. It works far better for my application.

I'm not looking at the wrong section of the DD table. I have logged the A/D pedal count and compared to my calculated version and they are spot on. This ETC surge I see is always coming from the last 2 rows of DD (406 and 542). If I set those rows equal to the values in 312, and disable the WOT start/end, full pedal nets a smooth 0 psi MAP through the whole rpm range.

[CCS86]

More testing is confirming the same things:

• There is a temperature dependance, worse when ECT is cooler
• There is an RPM dependence: above ~3500 rpm doesn't seem to be affected

Here are 3 roll-ons that were done back to back. RPM at surge and TQ error for each shown:

3-roll-ons.jpg

You can see that the first one has a tiny surge in throttle, second one has a big surge, and the last one has almost perfectly smooth throttle action.

If I could just get the 2000-3000 rpm roll-ons to behave like like the 3000+, I would be happy. Looking at my TQ tables, I can't see any contribution there. The difference in indicated TQ between those two engine speeds is like 1.5%:

MP7-Tq-Table.jpg

The driver demand table has an appreciable difference at these pedal positions and RPMs. But if the TQ lookup curve is almost flat, and the commanded TQ drops with RPM in this range, why is the throttle surging open? Does this mean I should raise my TQ request, hoping for an opposite response? Or should I try to lower it further, even though the numbers don't make sense?

DD.jpg

[CCS86]

Lowering DD in this area, has helped a bit. But, I feel like it is just masking the issue.

I'm wondering if the large spans in ETC angle axis values, in the TB effective area table could lead to these inconsistent errors:

Eff-area-spans.jpg

15* - 40* and 40* - 70* are giant spans in throttle opening. I'm not sure if the computer uses linear interpolation to get between these, or if it tries to curve fit. Maybe dragging those angles down a bit could help generate better data.

[murfie]

At 2000 RPMs and full pedal you could put 50ft lbs or 1000ft lbs, it doesn't mean the engine is actually going to make that. If you looked at the patent your request is corrected in a feed back loop with the estimated engine torque.

You ether need to match you driver demand to what the engine is doing, or match what the engine is doing to your driver demand. Any deviation of the two will cause surging or a dead pedal feeling. The ECU can take a little error and you probably won't notice, but when they are just too far off it has to take drastic measures to fix it.

If your pedal was requesting 500ft lbs and the engine was only making 300, if it didn't correct your request, you would have to let of the pedal far more than expected to stop accelerating. Same goes for the opposite, if you were requesting 300, and the engine was making 500, you would need to press the pedal more than expected to accelerate.