Page 2 of 2 FirstFirst 12
Results 21 to 37 of 37

Thread: MP9 Causing Major ETC Spike and TQ Error

  1. #21
    Senior Tuner CCS86's Avatar
    Join Date
    Nov 2017
    Location
    Austin
    Posts
    1,089
    You are correct that the driver demand table changes the relative "feel" of the pedal. But you haven't explained a mechanism, where with almost no change to pedal position, or change in RPM, the DD table could cause the throttle to suddenly surge open, then back to normal. Sometimes this happens without an IPC TQ error to take credit:

    ETC-spike-low TQ-er.jpg


    This screenshot shows that actual load is exceeding desired load during the surge. Something directly involved with the ETC calculation is overestimated the required throttle angle... not the load required.

    I am going to test more with the throttle body tables. I think that fundamentally since the strategy sees boost as a reduction in pressure drop across the TB, it needs a different set of TB tables than an NA car would, with the same TB.

  2. #22
    Senior Tuner
    Join Date
    Jan 2013
    Location
    Hawaii
    Posts
    2,101
    The would be true for a centri or turbo car, not for a PD car. once the bypass closes the ETC vacuum actually would increase, hence the OEM calibrations using a SIP sensor. You are going to attempt to fool the TB model into thinking MAP is a few PSI less than baro+your delta baro table. I don't see you having much luck doing that, and if you succeed not causing some other unwanted behavior. There are maximum and minimum learned baro tables, you would want to start there making the maximum 36inHg or something higher than actual baro. Make the minimum the same. You want it to think baro is higher not lower.
    Last edited by murfie; 02-04-2019 at 11:15 PM.

  3. #23
    Senior Tuner
    Join Date
    Jan 2013
    Location
    Hawaii
    Posts
    2,101
    IPCminimumTQ.PNG

    I don't know if you modified your IPC min and max tables, But in the log you posted your engine brake torque is hitting the minimum table.

  4. #24
    Senior Tuner veeefour's Avatar
    Join Date
    Oct 2016
    Location
    Poland
    Posts
    1,711
    Quote Originally Posted by murfie View Post
    IPCminimumTQ.PNG

    I don't know if you modified your IPC min and max tables, But in the log you posted your engine brake torque is hitting the minimum table.
    Those tables are not really necessary IMO.

  5. #25
    Senior Tuner
    Join Date
    Jan 2013
    Location
    Hawaii
    Posts
    2,101
    Quote Originally Posted by veeefour View Post
    Those tables are not really necessary IMO.
    IDK its kinda discouraging, like the ECU saying "yeah you are getting to 1.1 load, but so inefficiently it cant believe its making so little torque, must need to open the throttle more".

  6. #26
    Senior Tuner veeefour's Avatar
    Join Date
    Oct 2016
    Location
    Poland
    Posts
    1,711
    Yeah this is yet another Ford's safety check of being right under safety rules of plausibility plan.

    I just min/max those and never come back again. You might get close with PD blower but not sure how this could work with centri or turbo. Anyways not worth the hassle.

  7. #27
    Senior Tuner CCS86's Avatar
    Join Date
    Nov 2017
    Location
    Austin
    Posts
    1,089
    Quote Originally Posted by murfie View Post
    The would be true for a centri or turbo car, not for a PD car. once the bypass closes the ETC vacuum actually would increase, hence the OEM calibrations using a SIP sensor. You are going to attempt to fool the TB model into thinking MAP is a few PSI less than baro+your delta baro table. I don't see you having much luck doing that, and if you succeed not causing some other unwanted behavior. There are maximum and minimum learned baro tables, you would want to start there making the maximum 36inHg or something higher than actual baro. Make the minimum the same. You want it to think baro is higher not lower.


    I wish we had a strategy that used an SIP for boosted Coyotes. It would be even better if all the "black box" aspects of the strategies were fully exposed. To be able to change which sensors are links to which tables, and the math used, would be very powerful.

    I'm not saying that the TB sees positive MAP in a PD car. What I'm saying is that the TB tables seem to be designed around having actual (and calculated) MAP used as the downstream pressure at the TB, and atmospheric on the upstream side. This means that the effective area of the TB always increases with manifold / ETC vacuum, and is lowest near atmospheric.

    The problem on a PD car, is that (especially at low RPMs) at partial throttle openings, the bypass can close. This means you can have legitimate vacuum across the TB, into the supercharger inlet, which is then compressed into above atmospheric MAP (if your SD is well tuned), and that positive calculated MAP seems to be used to drive the ETC vacuum parameter to a near atmospheric value. Using stock TB tables, this drives effective area to a minimum and that doesn't seem to match reality.

  8. #28
    Senior Tuner CCS86's Avatar
    Join Date
    Nov 2017
    Location
    Austin
    Posts
    1,089
    The other odd trend I notice, is that the loggable channel for effective area, seems to be driven by MAF.

    This means that for a fixed cell on the TB area table (0.3 in-hg, 82*), and a relatively constant calculated MAP, the effective area logged climbs and climbs:

    ETF-Area-Climb.jpg

    This suggests that you shouldn't really use logged effective area data to tune the TB tables.

  9. #29
    Senior Tuner CCS86's Avatar
    Join Date
    Nov 2017
    Location
    Austin
    Posts
    1,089
    This approach looks very promising. After two revisions to my TB tables, I am getting MUCH cleaner ETC action:


    Surge-improved.jpg

  10. #30
    Tuner in Training
    Join Date
    Oct 2017
    Posts
    35
    What table setup for logging did you settle on to finally help? I need to start playing with my throttle body tables to get them closer.

  11. #31
    Senior Tuner CCS86's Avatar
    Join Date
    Nov 2017
    Location
    Austin
    Posts
    1,089
    Quote Originally Posted by Sleek98 View Post
    What table setup for logging did you settle on to finally help? I need to start playing with my throttle body tables to get them closer.

    I've moved away from the Scanner graphs for a lot of my tuning. I don't like the way it populates data. Without being able to see the standard deviation of the data, you don't know how close the data is to the average value it reports.

    I do my best to create the data I want to see in little chunks on the road. I have done a pile of roll-ons, in different gears and at different speeds. For this last attempt at the TB tables, I logged ETC effective area, and find areas of my roll-on where the area is equal to a column axis label, then look at the actual ETC angle. I used that to tune the predicted angle table, then an excel sheet to calculate the effective area table from that.

  12. #32
    Senior Tuner veeefour's Avatar
    Join Date
    Oct 2016
    Location
    Poland
    Posts
    1,711
    Quote Originally Posted by CCS86 View Post
    I've moved away from the Scanner graphs for a lot of my tuning. I don't like the way it populates data. Without being able to see the standard deviation of the data, you don't know how close the data is to the average value it reports.
    There's a delay between actual data and a graph - not sure which is faster/right/wrong/slower but it can be confusing especially if your are trying to log like 40 pids.

  13. #33
    Senior Tuner CCS86's Avatar
    Join Date
    Nov 2017
    Location
    Austin
    Posts
    1,089
    Quote Originally Posted by veeefour View Post
    There's a delay between actual data and a graph - not sure which is faster/right/wrong/slower but it can be confusing especially if your are trying to log like 40 pids.


    Can you explain what you mean by this?

    It sounds like you mean a time delay between the actual event and the trace on a Scanner chart. I believe that there is a delay in that sense. But if you go back to review log data, whether in a chart or a graph, all the channels should be more or less synchronized.

    What I'm saying is that the graphs give you no confidence interval for the values they populate with. You can't tell the difference between:

    [-28%], [22%] = -3% average

    and

    [-4%], [-2%] = -3% average

    It's an important distinction. The first is essentially useless for improving your tune and the other is more likely to give you a good result.
    Last edited by CCS86; 02-06-2019 at 09:57 AM.

  14. #34
    Senior Tuner veeefour's Avatar
    Join Date
    Oct 2016
    Location
    Poland
    Posts
    1,711
    Quote Originally Posted by CCS86 View Post
    Can you explain what you mean by this?

    It sounds like you mean a time delay between the actual event and the trace on a Scanner chart.
    yes, exactly.

  15. #35
    Tuner in Training
    Join Date
    Oct 2017
    Posts
    35
    Quote Originally Posted by CCS86 View Post
    Can you explain what you mean by this?

    It sounds like you mean a time delay between the actual event and the trace on a Scanner chart. I believe that there is a delay in that sense. But if you go back to review log data, whether in a chart or a graph, all the channels should be more or less synchronized.

    What I'm saying is that the graphs give you no confidence interval for the values they populate with. You can't tell the difference between:

    -28% + 22% = -3% average

    and

    -4% + -2% = -3% average

    It's an important distinction. The first is more or less useless for improving your tune and the other is more likely to give you a good result.
    That makes sense. You would be able to see the large swings on on the graphs. I have been following your threads just trying to soak up information.

  16. #36
    Senior Tuner
    Join Date
    Jan 2013
    Location
    Hawaii
    Posts
    2,101
    I find that graphs in the scanner work best with small windows of data. Either use view zoom data only or if that doesnt populate cells even though there is a hit count, what I find works best is to export the visible range into its own short log and use the view all data.

  17. #37
    Senior Tuner CCS86's Avatar
    Join Date
    Nov 2017
    Location
    Austin
    Posts
    1,089
    Quote Originally Posted by murfie View Post
    I find that graphs in the scanner work best with small windows of data. Either use view zoom data only or if that doesnt populate cells even though there is a hit count, what I find works best is to export the visible range into its own short log and use the view all data.

    Yeah, scanner is nice software for sure, and it runs really fast, even with large data sets. But, I really wish they would add some basic statistical analysis tools. They don't seem interested.

    I had to write my own excel sheets for most of my tuning. The latest is helping me populate the SD calculator table in Editor. Instead of forcing all data to fall into a cell, with no control over where the split is between columns/rows, I have a sheet that lets me give a percentage above and below the column and row axis values (independently) to allow data to be counted in the cell's average. It also allows me to blank out cells with below a minimum count.