FSX Fuel consumption problem

[Fdd_fr]

Hi,

I work on the FMC Airbus A320 project.

But I have a problem with the FSX fuel consuption.

Engines are too gluttonous near sea level, when they are in IDLE position. The consumption is 2 x more important that the reality at idle position (2000kg/h instead of 800kg/H ).

I have modified the 1502 to 1507 table for a real thrust curves of the engines and set the right value for the thrust. But it is very difficult to find documentation and information about .AIR file.


And I think that the fuel consuption is too low at high altitude (cruise altitude).

Is it possible to change in the AIR file the curves of the fuel consuption according altitude and if yes, which tables must I use ?


I would like to make a fuel prediction gauge, but with these actuals settings, taxi phase is very "heavy" in the operating range.


Thank you for your help

Francois

 

[hervesors]

see the first post below..
http://www.fsdeveloper.com/forum/showthread.php?t=425707

On jets fuel flow only depends on engine thrust and TSFC. So the only way is to play on one of them but there are some restrictions for idle thrust

 

[jx_]

You will never get realistic fuel flows at both Cruise and SSL idle due to the drag bugs in all FS9+ versions.

You will have to compromise. Mach drag in FS adds to parasite drag, when it should be independent of parasite drag (constant per Mach regardless of airspeed), while induced drag should increase with the higher Lift coefficient required by high mach flight.

 

[JB3DG]

The only other way around it is to tune for proper thrust/RPM indications at SSL and altitude, then control the fuel tank level directly to simulate proper fuel flow via SimConnect.

 

[WarpD]

It's not usually about the total amount of fuel burned for a trip but rather the correct fuel flow values at a given condition for a trip. So simply changing the amount of fuel onboard isn't going to 'fix' the problem itself at all.

Correct fuel at idle is possible, but difficult. Correct fuel at specific phases is also difficult but possible. However, correct fuel flow at all phases you're unlikely to get because FS models a single TSFC where in a real engine TSFC is not constant.

 

[jx_]

Correct fuel at idle is possible, but difficult. Correct fuel at specific phases is also difficult but possible. However, correct fuel flow at all phases you're unlikely to get because FS models a single TSFC where in a real engine TSFC is not constant.

Sounds like a smart guy to me!

I got a project for you Ed. Email me...

 

[Heretic]

I don't know how TSFC varies in a real engine, or what exact factors play a role in it (ambient temperature, engine wear, fuel quality?), but a simple fuel system coupled with appropriate fuel flow indication gauges could alleviate this one a bit.

 

[jx_]

I don't know how TSFC varies in a real engine, or what exact factors play a role in it (ambient temperature, engine wear, fuel quality?), but a simple fuel system coupled with appropriate fuel flow indication gauges could alleviate this one a bit.

Here are your four issues:

1. The biggest difference between real world and FS is the FS induced drag bug. At high altitude, the CL vs AoA chart of a real wing compresses from left to right. The CL line becomes steeper, and thus at the same angle of attack, a high altitude wing is producing a higher lift coefficient than a low altitude wing at the same AoA. The high altitude wing is also producing more induced drag. This is not a negligible amount, and can be a few thousand pounds of drag in a typical modern airliner.

2. Then there is the mach drag bug. Mach drag in the real world is tied exclusively to the ratio between current True Air Speed and the Speed of Sound. At high altitude Mach, where indicated airspeed is lower, the Mach drag curve is roughly the same as at low altitude Mach where the same Mach is at a higher indicated airspeed. FS ties Mach directly to parasite drag. At higher altitude, the same Mach in FS will produce the same and correct drag coefficient, but the lower indicated airspeed will produce less drag pounds of Force because parasite drag is based on dynamic q (density) while the speed of sound is based on temperature, and their curves don't match.

3. TSFC varies in the real world for a bunch of reasons, but the main difference that will concern you in FS is the fuel burn from net thrust bug. In a real engine, fuel burn is tied to gross thrust, and as net thrust changes, SFC changes. At high altitude and high Mach, your FS engine has a given value in Ram Drag that is reducing gross thrust to equal net thrust. Because FS bases fuel burn on net thrust, your fuel burn under those conditions will be lower than the real thing as well.

4. Number four is the Lift table bug. If this bug didn't exist it would help problem #1. The lift table bug is simply a bug where the lift scalars in tables 401 and 402, that are applied to the CL vs AoA table 404, are not taken into account in induced drag calculations. You can double the lift in these tables, but with no increase in drag. This may be a good thing for the ground effect table, but for increases in lift due to mach it is not. This exaggerates problem #1.


Add all of those up and you end up with low fuel burns at high altitude. What I recommend for anyone who doesn't want to build a complex system with simconnect or FSUIPC hacks, is to focus on the operating envelope. Get your sea level performance right, then reduce some low mach drag while adding some induced drag. Reduce some low speed drag while adding a little more induced. Your performance will be off outside of the operating envelope but should be close while within it. This will be much harder with military jets and other high speed aircraft that fly at a wide range of altitudes and speeds, but it's a starting place to work out the issues you are having.

 

[Heretic]

Get your sea level performance right, then reduce some low mach drag while adding some induced drag. Reduce some low speed drag while adding a little more induced. Your performance will be off outside of the operating envelope but should be close while within it. This will be much harder with military jets and other high speed aircraft that fly at a wide range of altitudes and speeds, but it's a starting place to work out the issues you are having.

Noted.



If these bugs have been there forever, I wonder why it took seven years for add-on makers to work around that (by tieing in YASIM via SimConnect).

 

[jx_]

If these bugs have been there forever, I wonder why it took seven years for add-on makers to work around that (by tieing in YASIM via SimConnect).

Most payware, including the expensive ones, fake it or lie because they know 99% of the customers have no clue what the real numbers are. You can't check how good the work is without real data, and then you still won't know what it "feels" like. If you don't have real data to put in, how can you know if the sim output is bugged or not? The rest of them probably don't know or make guesses. I have yet to find an accurate flight model in any payware I have tested. Otherwise, I would assume no one wanted to invest the work into building something external...

 

[EduHir]

If you have Real World Data, download and use Doug's fueldump gauge and do some
XML - programming, it should be possible to make proper fuelconsumption!

I would like to do it for the JT8D-17R mounted on the B727-200.

Has someone Real World Data for the JT8D-17R??

Edi

 

[jx_]

If you have Real World Data, download and use Doug's fueldump gauge and do some
XML - programming, it should be possible to make proper fuelconsumption!

I would like to do it for the JT8D-17R mounted on the B727-200.

Has someone Real World Data for the JT8D-17R??

Edi

This is faking it... there are several ways to do that, but it doesn't fix the problem of the drag, lift, and performance being wrong.

 

[Heretic]

If you don't have real data to put in, how can you know if the sim output is bugged or not? The rest of them probably don't know or make guesses. I have yet to find an accurate flight model in any payware I have tested. Otherwise, I would assume no one wanted to invest the work into building something external...

To be fair, real data is a bit hard to come by.

This is faking it... there are several ways to do that, but it doesn't fix the problem of the drag, lift, and performance being wrong.

Well, than just fake that as well.
Humanity got away with faking stuff for eons, so you might just do it in a bloody simple end-user based simulation.


(Nota bene: I'd love to have a proper working "Available real data in, available real data out." approach available, but MS ensured that this simply just can't happen. So just fake it to at least get 90% of the real data in the output slot.)

 

[jx_]

I don't necessarily disagree with faking it, it is sometimes necessary, but the comment I was replying to started by saying "If you have real world data..." Why fake it when you actually have the data? Seems like a half-ass approach to designing an air file to me.

(Nota bene: I'd love to have a proper working "Available real data in, available real data out." approach available, but MS ensured that this simply just can't happen. So just fake it to at least get 90% of the real data in the output slot.)

What do you mean by MS ensured this can't happen??

I have personally tested real data in MSFS, and the sim is very accurate with the exception of some minor bugs that were either an over simplification or programming errors made by computer engineers who must have not understood what the aeronautical engineers wanted; and limitations of imposing a 18Hz frame rate limitation on physics. Many of the things that people think the sim can't do it can actually do quite well and within the real world margins of error on real data.

 

[Heretic]

I don't necessarily disagree with faking it, it is sometimes necessary, but the comment I was replying to started by saying "If you have real world data..." Why fake it when you actually have the data? Seems like a half-ass approach to designing an air file to me.

Well, it depends on what data you have. From my understanding, due to the aforementioned inaccuracies in some aspects of MSFS flight dynamics modeling, you can't attian real output data (= instrument readings) with real input data (= e.g. thrust curves).
Hence, you'll have to fake - or adjust, to put it less negatively - things either on the input or on the output side by derivating fromt he real input numbers or by making the instruments show the real output numbers.

What do you mean by MS ensured this can't happen??

By not ironing out the bugs for FS or in the service packs. I'm pretty sure that some of the simplifications and bugs were there since at least FS2000...

and limitations of imposing a 18Hz frame rate limitation on physics.

This is actually a good thing as it makes the physics independent of frame rate.
FlightGear's physics are not limited to a specific update frequency and the effect is all kinds of weirdness (sliding aircraft on runways) happening when framerates are very low.

 

[jx_]

Well, it depends on what data you have. From my understanding, due to the aforementioned inaccuracies in some aspects of MSFS flight dynamics modeling, you can't attian real output data (= instrument readings) with real input data (= e.g. thrust curves).

Now I understand what you are saying, and you make a good point, but you can attain real output data from MSFS. The sim engine is complete and accurate enough to get the output right, IF the designer is aware of what's missing. There are workarounds that will ensure the sim engine resolves to the real number. It's all just simple math anyway. Once the math is right, the sim's output is spot on.



.......

As an aside, regarding the suggestion about using a fuel dump gauge or other method... It might be easiest to reverse the Thrust equation to find gross thrust, then plug in a target fuel burn number from that.