ETC Angle Error Doesn't Make Sense

[murfie]

The TB patent says they use a beam of light and shine it through the TB and measure the effetive area that is lite up at different TB angles.

You can do nearly same thing with some trigonometry to get a rough idea of how the effective area should change.
The area of a circle is pi*r^2. The area of an ellipse is pi*A*B.

Elipse area.PNG

A. would just be the radius. B. would be the radius*Sin(TB angle). sin comes from looking at the blade sideways as it rotates out to get the height
of the ellipse it would make.

When the throttle opens the effective area would be the circle minus the ellipse of the blade. So you can see the relationship would be a sinusoidal curve. The inverse of sin is cos, to determine the angle the blade is at.

In a mono blade the model starts from an ellipse and goes from there. in a twin blade you need to calc the effective area of one side and double it as there are two circles.

Once you get near the 85-90* the effective area wouldnt grow as the cross section of the blade doesnt change and cant get out of the way.

[CCS86]

I definitely understand the geometry of calculating a "visible" open area, but they seem to be considering the dynamic behavior of pressure drop across the blade in these tables, by plotting them against ETC vacuum. The trend is for larger effective area as vacuum increases, which makes conceptual sense.

These tables no doubt affect the throttle response of the engine, but I don't think they are responsible for any of the ETC Angle Error calculation.

[murfie]

They are feed forward tables. So no they are not directly responsible for the error, air flow is. They do how ever provide a predictive element that you want accurate, so that your PID controller, has an easier time minimizing error between actual and desired airflow.

Ideally you would want this model to be so good you wouldn't need PID loop correction or at least very minimal, to avoid oscillations.

[veeefour]

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.

This is exactly how I feel about these. Some say start with modding the Predicted and Effective tables to fix your problems - I say leave them alone stock.

[MRRPMBRP]

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.

Attachment 81569

Go to your throttle errors in your torque table, and adjust. Errors will go away, once adjusted. If you have 5% error, adjust torque 5%, can't remember which way was what, I haven't tuned them in a bit, but go one way, if errors get bigger, go the other way.

[CCS86]

Go to your throttle errors in your torque table, and adjust. Errors will go away, once adjusted. If you have 5% error, adjust torque 5%, can't remember which way was what, I haven't tuned them in a bit, but go one way, if errors get bigger, go the other way.

Like I mentioned earlier, I tried this approach, modifying the torque/inverse values around idle conditions by 30% and saw the same amount of angle error. Maybe I missed something.

The other roadblock I have with editing the Torque tables, is not having a good way to calculate inverse. The stock TQ / Inverse tables from the FPDX0A8 strategy give 0.0 IPC TQ errors everywhere. I thought that PID was broken for me, but it isn't. If I run the built in calculator, or my linear interpolation spreadsheet, to recalculate inverse, I get giant IPC TQ errors everywhere. I'm reluctant to mess with the TQ tables without a good way to calculate inverse.

[MRRPMBRP]

I pay no attention to IPC errors, you can set them to whatever you like to cause no error.
I use the inverse calculator that comes with HPT, no issues so far.
I haven't had much idle errors, mine would occur in the middle of the tables, sometimes at the higher rpms/loads. A simple torque/inverse adjustment fixed them.

[CCS86]

I pay no attention to IPC errors, you can set them to whatever you like to cause no error.
I use the inverse calculator that comes with HPT, no issues so far.
I haven't had much idle errors, mine would occur in the middle of the tables, sometimes at the higher rpms/loads. A simple torque/inverse adjustment fixed them.

Do you have a specific reason why you just ignore IPC errors? They seem to imply a mismatch between TQ and inverse tables, which seems pretty fundamental to reliable throttle response in the driver demand system.

Can you post a log showing your fixed ETC angle errors?

[Devildog1325]

I also went the route of changing torque and inverse tables to correct throttle errors. I don't know if I fully understand but my understanding is the pedal input gives a torque number from the DD table this looks up load in the torque inverse table and then to the torque table then to the throttle body. Looks to me like after you have got it as close as you can with the Torque and Inverse tables then you will also have to the adjust the Driver Demand table or it might be easier to adjust only the Driver Demand table to reduce throttle errors. Either way at the end of the day you will have to adjust the Driver demand table if it is too far off because your torque table might be right but you may be commanding torque faster than the car can keep up with or you might be commanding too much torque at idle and adaptive is bringing the idle back down causing throttle errors. I haven't tried this method but I think the most effective way would be to log load against the axis's of your torque inverse table (indicated torque reference? and RPM), input those numbers and inverse it to the torque table then adjust the Driver Demand table to get rid of the throttle errors. The only problem with this is it seems like must of us cant log pedal position in AD counts without math that we are guessing at.

[MRRPMBRP]

I think the pcm takes torque value to calculate fueling & airflow. It takes x amount of fuel & air to make x amount of torque. If the torque table is telling the motor, for example, to make 500ft/lbs, it needs x throttle opening, along with x amount of air. It knows the amount of air that's going through the mass air flow sensor, so if the tb model commands more opening than it needs to flow the correct amount of air, this creates an error. Make torque less to match the airflow that the motor is seeing, and tb errors go away.

Of course you tune torque inverse to match modded torque tables.

This is my theory at least, may or may not be 100% accurate.

[CCS86]

I also went the route of changing torque and inverse tables to correct throttle errors. I don't know if I fully understand but my understanding is the pedal input gives a torque number from the DD table this looks up load in the torque inverse table and then to the torque table then to the throttle body. Looks to me like after you have got it as close as you can with the Torque and Inverse tables then you will also have to the adjust the Driver Demand table or it might be easier to adjust only the Driver Demand table to reduce throttle errors. Either way at the end of the day you will have to adjust the Driver demand table if it is too far off because your torque table might be right but you may be commanding torque faster than the car can keep up with or you might be commanding too much torque at idle and adaptive is bringing the idle back down causing throttle errors. I haven't tried this method but I think the most effective way would be to log load against the axis's of your torque inverse table (indicated torque reference? and RPM), input those numbers and inverse it to the torque table then adjust the Driver Demand table to get rid of the throttle errors. The only problem with this is it seems like must of us cant log pedal position in AD counts without math that we are guessing at.

I did enough testing to feel pretty confident in my pedal position % to AD count conversion: https://forum.hptuners.com/showthrea...ve-Pedal-Count

I really don't think the Driver Demand table has any influence on ETC Angle Error. I have tuned my DD table quite extensively, and have not seen a change in my angle errors. It has made the car MUCH nicer to drive though. I'm a road racer at heart, so predictable, linear throttle response is important to me. Lund laughed at me when I said this was what I wanted with my PD blower. I made it happen. It's ironic because he mocks "HP Tooners" like everyone is just copying and pasting tables here. In my eyes, he's the one doing simplistic tunes, failing to solve actual drivability issues, blaming cars, bragging about how many cars he has tuned. Meanwhile, people here are trying to figure out a deeper understanding of these PCMs.

I have read that the 15 row in driver demand can affect the idle, but I'm not sure how true it is. Looking at the stock GT DD table, it has a value of 18.44 ft-lb in the 15 row, at the stock idle of 650 rpm. But this is at AD pedal count of 15. My tests show 0% pedal to equal 8 AD counts. If you plot a line between the first two TQ entries in the 650 rpm column (ad counts = 15 and 42), then project that downwards, you hit 0 ft-lb torque very close to ad counts = 8.

[Thatwhite5.0]

Driver demand will get rid of torque errors for sure. Throttle Area and Predicted Throttle tables will get rid of angle error. When you're calibrating the throttle body, you'll need to play with all three tables. There may be a time when you're adjusting driver demand and you're engine torque is higher than your requested torque. No matter how much you request, your engine keeps producing more torque than requested. Or it may be opposite and you can't lower your request enough. This is usually why the idle is rough. One will have 15 AD Counts at -5 ftlbs, and the next row down will be requesting 120 ft lbs. That's giving a rough slightly oscillating idle with the RPM, throttle angle/ area, fuel trims, etc... making a wave in your datalog.

The throttle body model pic I posted, I started with the twin 65mm throttle body calibration for the twin 67mm throttle body I have on my cobra jet.

My idle
idle_error.JPG

ETC Area, Predicted Throttle Angle and Driver Demand are the tables you need.

Explaining this is beyond me, I don't have a special formula, I adjust according to datalogs. That datalog will tell you where things should be, raised, lowered, rough.
compare_2.jpg
compare_1.png

In the last screenshot, by "spread" I mean your throttle desired was wanting to basically close. So it requested torque which increases throttle angle to keep your car from dying.

[CCS86]

I don't agree, based off of what I have seen.

When you say "Driver demand will get rid of torque errors for sure", are you talking about IPC Wheel Torque Error? I have modified nearly every cell on my driver demand table, and my IPC TQ Errors are 0.0 everywhere... because I haven't jacked with the Torque tables.

I have made both sweeping and targeted changes to to Effective Area and Predicated Angle tables, and observed no change in ETC Angle Error.

In your second screenshot, where you show a big "spread", it looks like you have set a minimum throttle angle of 0.7*, and that is the only reason it doesn't trend closed with desired. I have mine set to 0.7* minimum angle and this keeps the car from stalling, when it would otherwise try to stall. I'm still trying to figure out why when the idle is already 100 rpm below the setpoint, it would "desire" such small throttle openings.

I'm having a hard time deciphering your screenshot notes, without more explanation.

[CCS86]

I think the pcm takes torque value to calculate fueling & airflow. It takes x amount of fuel & air to make x amount of torque. If the torque table is telling the motor, for example, to make 500ft/lbs, it needs x throttle opening, along with x amount of air. It knows the amount of air that's going through the mass air flow sensor, so if the tb model commands more opening than it needs to flow the correct amount of air, this creates an error. Make torque less to match the airflow that the motor is seeing, and tb errors go away.

Of course you tune torque inverse to match modded torque tables.

This is my theory at least, may or may not be 100% accurate.

I believe some version of this.

Fueling calcs are dominated by MAF rate, but are supplemented by a ton of other tables like speed density, transient gain, etc.

I do believe it is making some sort of assumption of torque generated based on fuel flow, rpm, spark timing, etc; and comparing against the torque tables. My question, is which PIDs would you use to calculate this error? Some of the torque PIDs are redundant ("Scheduled Torque" and "Engine Indicated Torque Reference", or "ETC Torque Request" and " Desired Brake Torque" for example). I don't think IPC Wheel Torque error even generates data at a stop. So which torque PIDs do you look at to figure out error in the torque tables?

Beyond that, I don't have any frictional torque tables in my strategy. I'm not sure where it is calculating how much expected frictional loss there is in the engine, the AC compressor, alternator, etc.

[CCS86]

Here's a short log showing a little bit of idle, then a slow free rev and return to idle. Plus my layout.

I plotted 3 non-duplicate torque PIDs with the same scale. Even as the relationship between the torques changes, the ETC Angle Error stays pretty steady. I'm still not sure what to take away from this. It definitely looks under-damped during decel.

Torque-Idle-Free-rev.png

[murfie]

https://upload.wikimedia.org/wikiped...n_Animated.gif

Tune your PID to get rid of the error.

[Thatwhite5.0]

The first screen shot was my log. The second screen shots were from the datalog you posted.
I'm on my phone right now so going back and forth is a little difficult. What data are you using and how are you applying it when you make these changes to etc area and predicted tables?
Because the PIDs that need to be in your chart are throttle angle, throttle angle desired, etc area and etc vacuum + add ipc torque error to your torque group on the lower half. Throttle percent does not allow for proper adjustment unless you're opening the throttle body 100 degrees. Spread apart from each other. If your angle showed .8 and .8 degrees, thats not spread and I wouldn't of said it. A throttle angle of .8 degrees and a desired angle of .06 degrees is spread. Throttle angle actual and throttle angle desired being spread means errors, especially at idle and your desired wants to close the throttle body. When you get these to close together you have less throttle angle errors. The actual PID throttle angle error is a formula. If it was actual angle error you could do the math desired - actual throttle angle and see the results are not the same.

You have 14 columns which you decide which angles you get detailed on. Do you spend more time driving between 0 - 40 degrees or 40 - 83 degrees?
You could erase your last 2 column's etc area cell values, the cells in your 83 and 64 degree column. Change the last column's cell values to 8.765 in the entire column and change your predicted table axis accordingly. Now 64 column is gone. You can populate a column with low throttle angle where it needs work so you have less interpolation and less errors. Your throttle body will open faster since you are telling your calling for 83 degrees at 8.765 instead of original values. But involves more work.

[Thatwhite5.0]

In the screen shot I posted it your datalog. The first log is of your .7xx column. Look at how it oscillates and shows a wave. The second part of that pic below shows the column right before the .7xx column looking smooth as can be.

[MRRPMBRP]

I believe some version of this.

Fueling calcs are dominated by MAF rate, but are supplemented by a ton of other tables like speed density, transient gain, etc.

I do believe it is making some sort of assumption of torque generated based on fuel flow, rpm, spark timing, etc; and comparing against the torque tables. My question, is which PIDs would you use to calculate this error? Some of the torque PIDs are redundant ("Scheduled Torque" and "Engine Indicated Torque Reference", or "ETC Torque Request" and " Desired Brake Torque" for example). I don't think IPC Wheel Torque error even generates data at a stop. So which torque PIDs do you look at to figure out error in the torque tables?

Beyond that, I don't have any frictional torque tables in my strategy. I'm not sure where it is calculating how much expected frictional loss there is in the engine, the AC compressor, alternator, etc.

I made a table with absolute load as rows, rpm as columns, indicated torque filled in, I look at my log, when I see my ETC error going too far out, I look see where the torque is, at that moment in time in the load/rpm/indicated torque table. I adjust the torque table where the problem is, then run the torque table thru the inverse calculator, so it's correct. This will reduce the ETC error for sure.

[CCS86]

https://upload.wikimedia.org/wikiped...n_Animated.gif

Tune your PID to get rid of the error.

That's a great GIF. I'm actually pretty good at tuning PID controllers. Which parameters in the tune? Is it these?


PID.jpg


It seemed odd for them to be equal to 0, unless these are adders to some baseline values.