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.
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.
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.
This is quick GIMP job to show the difference between the pitch at IAS 153kts and 300kts:
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:
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.
FlyAndWire 
This is amazing, just an absolute amazing job putting this together! Ive tried to use the MDC but have a hard time figuring it out. I dont understand why i need to give a speed and a fuel flow, should the MDC not pick the optimal FF for the speed ive choosen? Maybe this is the “major flaw” you speak of.
Keep up the work. And thank you so much!!
LikeLike
Hey mate, thanks!
The fuel calculator in the MDC public right now (v1.1) is just a placeholder. V1.2 has it up and running but I wanted to add more features before releasing it. In v1.2 you set the speed and the fuel consumption for every leg is automatically retrieved.
At the moment in my MDC you set the speed whereas setting the TOT should be more accurate: in more complex missions especially, where multiple assets work together, the timing is king. On the other hand, I doubt that most players would use TOT rather than speed. Maybe at some point I can add it as option though.
You know what, here is the version that will be the 1.2 once completed: https://docs.google.com/spreadsheets/d/10QPWm5iFgB9G275oubLN1G62gzNMGVv9FoxyvtxFw8M/copy
Some features are missing, other things need testing. The Fuel Flow for Default loadout works though. You have technically nothing to do besides filling the flightplan. The altitude is automatically rounded to the nearest value of the Fuel model (unless you put something weird) and the same goes for the GS. There’s also a tolerance value for safety. The bingo part is still missing, same as “task-value”, basically something that takes into account your task: for instance, if you are doing a CAP, you may need to go Gate for a bit, then manoeuvre at high speed. Such function should take that into account and remind you at some point.
Anyway, feel free to play with it. I wish I had more spare time to invest in DCS and my site!
LikeLike
Aaaah, that is super cool thank you so much! I will start using this for missions and see how accurate it actually is. I did a quick run just between batumi, kutaisi and then kobuleti all at Angels10, 250GS and the fuel left was only off by 200 pounds. I really like the fact that you put a tolerance percentage in there aswell, i will see which percentage fits best to the missions. I did notice you put a *2 on the fuel flow for the first leg, i expect it it because of the extra needed from take off and climb. But i removed this for my quick test. I will leave it there for the missions.
If you want me to test something i might be able to help.
Once again thank you so much for all this work!
LikeLike
No problem, glad you like it! 🙂
One thing to bear in mind: the fuel flow is calculated at constant speed and at a precise weight. Even something as simple as maintaining formation (hence often correcting your speed) will create discrepancies between the model and the actual fuel consumption. Moreover, you will hardly fly at a certain, exact speed even if you are the leader of your Section. Another big factor is the weather, for obvious reasons. On the other hand, the more you fly, the lighter you become.
So what is the point then? The model is a reference: you know that you are going to use *that* fuel, plus the fuel needed for your tasking (and you can estimate that by using the values from the fuel model at high speeds for prolonged time), plus the fuel required for safety reasons (AF busy, for instance, so you need enough fuel to orbit for 20 minutes, although I am not sure that these regulations apply to military aircraft).
Another reason to use the model is estimating if, for instance, post engagement you have enough fuel to RTB safely (by summing the fuel needed in each leg) or you have to divert or top up at a tanker.
I use the model in the following way: I get the total fuel needed by summing each leg, then apply a 10% tolerance factor to represent climbing, and other minor manoeuvres. Then I add the bingo and a factor that represents the fuel needed by my task. If the total is reasonably within the 20000lbs of the ‘cat, then I’m happy. Otherwise, I have to plan AAR and/or choose a suitable divert Airfield. The feedback I got from real life pilot is that this level of detail is overkill because once airborne, there are too many factors that affect the flight. On the other hand, I enjoyed building this model, so I did it anyway 😀
The *2 is because the fuel flow is calculated on one engine only so all the values must be doubled. Or I did a mistake and I didn’t notice. The link I gave you is still WIP, unfortunately I’m very short on spare time.
LikeLike
hmm, that might be a mistake then. I see you divide each FF value with 1800 instead of 3600 compensating for the right engine. But on the first leg theres a single *2 at the end of the cell value. And i understand it is supposed to be used just as a reference and not something written in stone, but when i check in with JTAC i want to tell them the amount of play time in seconds xD
LikeLike
Yep, I just checked, it’s probably a leftover. I was planning to add something to take into account the T/O but then a friend suggested leaving it out because it is somehow compensated by the diving and landing phase. It makes sense.
As I said, v1.2 is not ready yet and I made the fork just for you 🙂
Sorry to disappoint, I tried to calculate the time on station in milliseconds but I failed 😀
LikeLike