Doing some tuning on my new FRPP Twin 65mm TB and trying to get it idling better.
I thought that I had a grasp on the ETC Angle Error meaning, but am seeing odd values:
ETC-angle-error-q.png
For the idle condition shown, both my Effective Area and Predicted angle tables point to something around a 1.3* ETC angle, with the current angle being 1.2*. So why then, is my ETC Angle Error at 0.83*?
Your Baro is showing 28.3 inHg, to be at 14.1 inHg ETC vaccum your calculated MAP needs to be 28.3 -14.1= 14.2 inHg or lower. So higher than 14.2 MAP is when this table really helps the feed back loop, up until it fully takes over usually when ETC vacuum is low. Its showing 9.2 inHg MAP, which means your ETC vaccum is more like 28.3-9.2= 19.1 inHg. The table resolution doesnt do very well representing that much of a difference, so it depends a lot on the torque model to make the feed back loop accurate. People have a hard time dialing in the larger throttle bodies at idle as it isn't so much about the TB model and more about the torque model and getting your DD torque lined up with what your torque/load inverse tables are saying. The 11-14s had some airflow tables for idle and basically used torque for return to idle, so they were a little easier, but you would still get rev hang and stalling issues is torque wasnt fixed. The 15+ use torque nearly exclusively at low load.
Originally Posted by murfie
Thanks Murfie,
That brings up another question I had: Why is ETC Vacuum different than vacuum calculated from Calc MAP and Baro? I have edited my speed density tables to match my calculated MAP to my mechanical boost/vac gauge. But the ETC Vac must be calculated another way. Are there other tables I can tune to get that reading more accurately?
I still don't understand how it is calculating ETC Angle error, unless it's a bit more complicated: Maybe it it using the torque and DD tables to estimate airflow needed, and predicting a throttle angle to achieve that. When it needs a higher angle to maintain RPM, that is shown as ETC Angle Error?
I will look into my torque tables. Actually just last night, I noticed some weirdness in my MP0 torque/inverse table. The stock settings in the FPDX0A8 tune seem to have a really jacked up inverse table. I made an Excel inverse lookup chart/comparison (since I don't like the way the built in calculator works). When I run the stock GT indicated TQ table through it, my calculated inverse table has a max error of 0.6% compared to the stock table. Most values are exactly the same. When I run the FPDX0A8 table through, all values are nearly 50% off. The other MPs are more like 11% off. But in spite of this, my car drives very nicely, and has IPC Wheel TQ Error of 0.0 everywhere. I don't get it!
CCS86, it seems to be shooting for 2* angle, perhaps from the Throttle Angle vs Pedal table? If you take your actual TA vs 2* in that table, I wonder if this is the ETC angle error? Is it really a problem or just what's expected vs actual?
If it's any help my vehicle's desired vs actual always ends up being 0* difference.. they match perfectly. I'm wanting to know what causes the actual angle to be offset? Is it intentional?
Last edited by blackbolt22; 06-23-2018 at 09:08 AM.
Where do you see it shooting for 2*?
Desired is 1.13*, actual is 1.20*. Both tables point to something near 1.3* for this effective area and ETC vacuum.
I saw it in your other post under "Late model Ford's torque control" It said desired 2* and your actual vs error matched.. Here in this post it doesn't seem so unless that's just a blip in your log?..
I clarified in that other thread, that the precision was wrong. It was rounding 1.55* to a single decimal 2*.
I got you, thanks for pointing that out
Still in both cases Actual + Error = 2* ? I was just pointing out something I noticed and why is it expecting 2*? Where is it pulling the 2* value from? Throttle angle vs pedal was the only place I saw that value.
Last edited by blackbolt22; 06-23-2018 at 09:32 AM.
Since 2* =/= 2.00*, I'd say it is just a coincidence
Anyone?
I am still trying to figure out why the factory calibration data for the Twin 65mm TB has such significant Angle Errors, and how I can fix them!
I have one on mine, errors are fine, as I told you before, tune your torque tables.
What do you mean "errors are fine". Having nearly a 0.7* throttle angle error, when the total opening amount is 1.0* seems not "fine".
You have made no mention of torque tables in this thread, maybe in another.
I did a test today, and see essentially no change in Throttle Angle Error from adjusting Torque tables. Idle is pretty easy to attack, since the RPM and load are very consistent, and you are only in MP0. I adjusted the MP0 TQ and Inverse tables by 30% and saw no difference in the Throttle Angle Error.
Am I missing something?
I think its part of another great formula between both tables. After messing with my throttle body so much, I don't have a correct/proper method. I can get idle right, I can get rid of torque errors, but the throttle angle errors will always be there. Try the first few columns of this.
tb1.JPG
See how it does, then combine it with this driver demand.
dd1.JPG
I tend to think like you, that we don't have a full understanding on how these tables are used. That's a shame, nearly 8 years later.
Which TB are those tables for? The axes are quite a bit different than the Twin 65mm data I am using.
Here is a little snip of a log where Angle Error bounces up and down, during fairly steady pedal, ETC angle, and ETC Vacuum.
r12e-2-Angle Error osc.hpl
There is really no correction you could make in the Effective Area or Predicted angle tables which would fix this. What I do see, is that calculated MAP oscillates with Angle Error, as mapped points shuffle a bit. To me, this indicates that either Calc MAP, or another table which uses it (like TQ/Inverse) are being used here. However, during steady idle conditions, I changed both TQ and Inverse tables about 30%, reflashed, and saw essentially no change in Angle Error.
Here is another example at idle, where you can see that Angle Error definitely tracks with actual angle. Any time the ETC stops moving, error gets very stable, but doesn't go away.
I have tried a math parameter that takes the difference between Desired and Actual Angle, but that only seems to show "lag" in the PID control; spiking heavily when the throttle moves fast, but essentially disappearing during normal movement.
ETC-err-r12e.jpg
If you want the airflow not to affect what angle the ECU decides the blade needs to be at, and have more control over your blade, make the model have less variable control by having no over lapping data column to column.
An easy way to avoid this is to make sure the data in a vacuum row is the same as the axis of the inverse table. You then control your ETC vacuum by placing the angle and effective area you want to create the ETC vacuum.
The starting point you had was a bad one. 6 columns describe the same angle and effective area as the other tables 4 columns do. recipe for overlapping data and lack of control over airflow.
I would start by re normalizing the axis values of your model. something like so. Goal is to get rid of overlapping Throttle angles, so that one angle means one ETC vacuum and not multiple.
copy the 14.1 row to the axis of the inverse table. set your min and max column values.(missed the max effective area in this snip)
67mm TB model renormalize step 1.PNG
After calculating effective area, reset max and min columns and fix any overlapping angles, column to column. There was only a little around 1.25*
67mm TB model renormalize step 2.PNG
Effective area can overlap(air is compressible/ can be pulled into vacuum), throttle angles can't.
Now you are set to slide the predicted angle columns up or down by applying angle error to the entire column. Your goal is to shift them so the angle and effective area in the model makes the ETC vacuum match the MAF(calculated MAP) making the airflow model happy.
Last edited by murfie; 07-11-2018 at 03:49 AM.
Interesting idea Murphie.
I made an Excel chart to lookup Effective Area using linear interpolation on the Predicted Angle table. I'm just not a fan of the HP Tuners built in calculators (both throttle body and TQ/inverse). They try to curve fit the data, which is most likely not a clean mathematical function. This cause very big erros to be introduced. If the ECU is using these as lookup tables, I highly doubt they are doing curve fits. It seems more likely that they just linearly interpolate the data. We obviously want to emulate how the ECU behaves when trying to generate new table data, using other tables.
The results of my calculations are interesting. The stock 2012 GT throttle body Effective Area I calculate matches perfectly with the OEM table. But when you look at the stock GT500 data, up to about 3* of angle, there is significant error/difference. If you move on the the Twin 65mm data, there is error scattered around throughout the table. I'm curious to hear your thoughts on this.
Inverse TB Area lookup.xlsx
Another question I have, is where does the value for the Effective Area PID come from? It does not appear to be simply looked up from these tables, or obviously it would match. Is the ECU looking at RPM and MAF rate (maybe other things like SD), and calculating this logged effective area? If that is the case, would it not make sense to log Effective Area against ETC Vacuum and ETC Angle, then use this logged data to populate the Effective Area table, and finally use it to create a new Predicted Angle table?
Beyond that, how does the ECU connect Effective Area to the Torque tables? Obviously Driver Demand makes torque requests. So, how does it connect these two things?
Last edited by CCS86; 07-11-2018 at 01:26 PM.
I tried a test today.
I took a long driving log where I plotted ETC actual angle against ETC Vacuum and Effective Area. I filtered, smoothed and extrapolated to complete the table. Then I used my calculator to generate a new Effective Area table.
The car ran smoothly in general and didn't feel very different. The ETC Angle Errors also did not change appreciably. It's easy to look at idle, since the conditions are pretty stable and the relative % error can be high. The values near my idle conditions did not change too much.
ETC Tables Before
ETC-Tables-Before.png
ETC Tables After
ETC-Tables-After.png
Log Before
Ang-Err-Before.png
Log After
Ang-Err-After.png
Notably, at idle, at ~1* ETC angle and 13.5 in-hg ETC vacuum, the Effective Area table says 0.050, but the logged value is ~0.065. This IMO shows that it is not looking up Effective Area in the TB tables.
I decided to plot logged Effective Area against some other PIDs (MAF rate, ETC Angle, ETC Desired), to see how they all trend together. I think that it matches very closely to ETC Desired. But this still doesn't really explain the connection between ETC Desired and Torque Request.
EffArea-vs.png
Interestingly, when I reverse the calculation and derive Predicted Angle from the Effective Area table, things change a little.
The Stock 2012 GT table is still very accurate across the board, but now with some 1-3% error instead of all zeros.
The Twin 65mm tables which had some scattered error between +/- 16%, now looks much cleaner. Mostly 0%, a few cells of up to 4%, and two cells with 40% error, right in the idle zone.
Next test is to go back to the stock twin 65mm data, make some updates to the Effective Area table, based on logged values, then calculate new Predicted Angle values.
After this last test, I feel prepared to say that you cannot change ETC Angle Error by manipulating the throttle body Effective Area and Predicted Angle tables.
Changing them in the way I describe above definitely changed the throttle response character. It was okay, but I think I prefer the original data.
Looking at a long log, I see no significant changes to the general trend of ETC Angle Error.
Check out this snapshot: both tables point to this angle, effective area, etc vacuum combination being correct. Yet, the angle error of 3.2* is like 23% error.
ETC-error-not-from-TB-tables.jpg
Reply With Quote