F-14B Fuel Consumption Model – Part I: Modus Operandi

I’ve been working on a simplified Fuel Consumption Model for quite a while now and it’s slowing coming together.

Defining Speed: IAS, TAS, GS, Mach

The starting point was my MDC Generator v0.9. It works fine but it also has a major flaw: the speed implementation is heavily simplified, therefore the ETA calculations use a monolithic approach and support only a generic “Speed” that corresponds to the GS. Therefore, I had to expand it and introduce a number of variables to obtain values that match DCS as close as possible. The model still needs a bit of work and it is included in the MDC Generator v1.1.

fuel-model-MDC-generator
New values calculated: GS, TAS, MACH.

Ground Speed is fundamental to calculate values such as Mach speed, timings and fuel usage and eventually set Joker and Bingo or decide, for instance, whereas an AAR is needed or not.

Iceman’s Data

As usual, I used a very hands-on approach. I used both DCS-BIOS and readings from the Fuel Flow Indicator.

fuel-model-TFT
DCS-BIOS based TFT

I collected the first round of data by means of Iceman: I set a specific Ground speed in the mission editor at a specific altitude, spawned the aircraft, jumped in the comfy RIO seat and sped up the time. The latter operation is necessary because the aircraft tends to sink right after spawning and Iceman needs a few seconds to get back to constant altitude and speed.

Funny stuff happening

At this point, I paused the game, jumped back in the pilot’s seat and wrote down the fuel flow, and this is where weird stuff started to happen. I noticed that, even when the aircraft was flying smoothly at a constant speed and altitude, the fuel flow displayed on my TFT was bouncing wildly, with a Δ of even 4000 lbs/h. This behaviour also causes the nozzle to open and close periodically, like a sinusoid. In other words, Iceman was jumping from idle to Buster and Gate and back to maintain the aircraft at a constant speed. This fact probably explains why the AI often has terrible fuel management skills. A human player can, in fact, find a stable throttle input to maintain the status quo, whereas it looks like that the AI simply can’t.

Going Manual

Due to Iceman’s “wild throttling” behaviour, I had to use my own throttle. I spawned the F-14, moved to the back seat and sped up time until the aircraft was stable. Then I activated the Active Pause, jumped back to the front seat, turned on the Alt AP, disconnected the Active Pause and carefully adjusted the throttle to maintain speed. When the speed was stable for 2-3 minutes (good bless time acceleration!), I noted the fuel flow values.
I also noticed how the Altitude Autopilot affects the pitch in order to maintain the aircraft at the desired altitude. Therefore, the results are affected by the logic of the autopilot. Later on, I will try to get into specific conditions of altitude and speed without the use of the AP to test if there is any difference between the results.

fuel-model-35000-spd-275kts-550kts
Aircraft data, 35000ft, speed 275kts-550kts

fuel-model-35000-pitch-aoa-rpm

This is quick GIMP job to show the difference between the pitch at IAS 153kts and 300kts:

fuel-model-35000-compare

First results and bugs (?)

Due to time constraints I decided to be pragmatic and use loadouts that I know will be used in the missions. The first example is a classic CAP with 4xAIM-54, 2xAIM-7, 2xAIM-9, 2x Fuel Tanks and full Gun on top of full internal fuel.

The following are some (now outdated) early results:

fuel-model-results-1

fuel-model-results-1-chart
CFG A: GS vs Single Engine Fuel Flow

Before focusing on the data, I decided to play with the weight and the payload, gathering different values with similar DI and different weight; simplest case being flying with same loadout but empty tanks. Here I run into an odd situation that looks like a bug (I never exclude the human error 🙂 ). I reported it on ED’s forum.

Polishing

Another interesting aspect of these results is the presence of “spikes” (e.g. 375kts, 35000ft) and their relation to the AoA. Are these “glitches” of the Altitude Autopilot? The solution is flying the numbers from a lower speed, up to the value to check and see what happens.
Eventually, the ultimate test is a complete flight, from ground to certain altitudes and speed and then RTB.

Model targets

This model has two main objectives:

  • In primis, finding the “sweet spot” between a speed too low and requiring additional thrust to compensate for the loss of lift and the point where the aircraft drag causes the ratio between speed and thrust to decrease too much. This value corresponds to the maximum endurance setting.
  • The second objecting is creating an automatic routine that gives an idea of how much fuel is used depending on the flight plan, leg by leg. This information helps to define correlated assets such as Tankers and tells the crew how much fuel can be committed for the specific task and how to recover from a low-fuel situation.

At the end of the day, the more the crew knows about their aircraft, the more they can take advantage of its capabilities.


A thorough analysis of the gathered data will be the topic of the second part of this series of articles.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.