• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

Table 1505

Sorry... L-M offered that up as a way to override the hard-coded turboprop spool behavior better. So... you saying they're wrong??
 
Technically, they didn't specifically say that it replaced that table so no they are not wrong. They only said that you could have more than one fuel_flow_gain:
A previously undocumented capability is to configure your fuel_flow_gain in the aircraft.cfg to be a function of engine speed (N2 for straight turbines, N1 for turboprops). It might look something like this...

[TurbineEngineData]
fuel_flow_gain.0 = 00.0, 0.011
fuel_flow_gain.1 = 25.0, 0.011
fuel_flow_gain.2 = 60.0, 0.05

You can configure up to 5 data points.
The only way to override the hardcoded table is to use 154B in P3Dv4.4 and newer. Prior to 4.4, it was completely impossible to override that table.
 
What about this?
TOKEN_BEGIN AIR_P3DV440_CORRECTED_N1_FROM_FF
; Translates internal corrected fuelflow to a target corrected N1.
; Note that "fuelflow" in this context is an internal state variable of the
; fuel controller, and does not precisely equate to the actual fuel burned by the engine.
;
;IN: Corrected Fuelflow
;OUT: Corrected N1
; Max table size is 8
UINT32 4
;FF Corrected N1
REAL8 0.0, 0.0
REAL8 100.0, 32.0
REAL8 150.0, 50.0
REAL8 610.0, 101.5
TOKEN_END

That confirms my thoughts on "corrected fuel flow"

That looks quite like this
;N2 (Corrected) vs. FuelFlow constant
; where the constant is a normalized ratio of actual fuelflow parameter to static thrust
;IN: Normalized Fuelflow constant
;OUT: N2 (corrected)
TOKEN_BEGIN AIR_70_CORRECTED_N2_FROM_FF

UINT32 10

REAL8 0.00000, 0.0
REAL8 0.00294, 10.0
REAL8 0.01180, 30.0
REAL8 0.02066, 40.0
REAL8 0.03397, 50.0
REAL8 0.05317, 60.0
REAL8 0.13391, 80.0
REAL8 0.25771, 90.0
REAL8 0.54000, 100.0
REAL8 0.68686, 105.0

TOKEN_END

Slight difference in definition of the fuel flow aspect.

Incidentally I used "mixture" to achieve control over the start up power surge when working on the C-2 ,E-2 project. These airplanes had a Low Speed Idle control which kept power down including prop RPM during taxi conditions.
This is the first time I have seen AIR_P3DV440_CORRECTED_N1_FROM_FF . I should examine and test that function
Roy
 
That's the table I'm referring to. TOKEN_BEGIN AIR_P3DV440_CORRECTED_N1_FROM_FF is the token for table 154B. It fills the exact same purpose as 1505 but the input is CFF instead of CFF/static_thrust.
That table is hardcoded (but with slightly different values) in all sim versions prior to v4.4. That's what my concern is about. I managed to get that hardcoded table for both FSX and P3Dv4.4 through intense experimentation, but what I'm concerned about is whether I should include it in the document or not (for legal resons).
What are your thoughts?
 
I'm no lawyer, but look at Air Wiz, AAM, etc. I'd say there is a precedent for publishing especially for non-commercial use.
"AIRCRAFT SIMULATION TECHNIQUES USED IN LOW-COST, COMMERCIAL SOFTWARE" by Zyskowski describes the turbine engine simulation in some detail. Of course he was a Microsoft employee.
Roy
 
I'm still working on the document. Let there be no mistake - it will be released. I just want to avoid as many silly mistakes as possible so I'm currently retesting all of the equations in all situations I can come up with.
 
Out of interest, where did the 154B designation come from?. I have not seen any updates to the old programs that were published prior to the official SDK description. I do find the old designations easier to remember than the official ones, hence my question.
Roy
 
Out of interest, where did the 154B designation come from?. I have not seen any updates to the old programs that were published prior to the official SDK description. I do find the old designations easier to remember than the official ones, hence my question.
Roy
It comes from the air-files. The table data blocks found in air-files always contain the following information:
ID (4 bytes)
Size (4 bytes)
Data (varying size)

The sim uses the ID to figure out what table is what. 0x154B is the ID that asm2air.exe assigns to AIR_P3DV440_CORRECTED_N1_FROM_FF when you compile.
 
What would be useful is example 154b files for:
1. Long spool start time turbojets and turbofans
2. Short spool start time turbojets like cartridge starts.
3. Smooth start turboprops and helicopter turbos with minimal overshoots of target idle RPM.
In case 3 it seems to me that the big issue is that prop/rotor RPM stability is dominant.
Roy
 
What would be useful is example 154b files for:
1. Long spool start time turbojets and turbofans
2. Short spool start time turbojets like cartridge starts.
3. Smooth start turboprops and helicopter turbos with minimal overshoots of target idle RPM.
In case 3 it seems to me that the big issue is that prop/rotor RPM stability is dominant.
Roy
I'll see what I can do. The equations for RPM are beyond the scope of the document (and my knowledge) and because of shaft friction, RPM affects torque spool up.
I'll still provide the equations for torque though, but without the RPM equations. The sad part about torque is that there's a hardcoded time constant used by a first order lag, which limits the control you have over that parameter.
 
Hi Johan,

I am sorry to revive this old thread, but I was curious if you ever released this documentation on engines spool up/down timings?
I am particularly interested in spool down computations when engine is shut down
 
No the document has not been released yet due to RL-stuff. I will most likely not include much guidance on how to fine tune the engine spool behavior and just focus on how engine spool works in the sim just to get the document released soon-ish.

It will be up to someone else to take the information from the document and figure out more in depth how to apply it to actual development.

Skickat från min SM-G955F via Tapatalk
 
This project is not doing many knots at the moment due to a severe lack of motivation, which is mostly caused by the fact that MSFS2020 will render this document obsolete.
The parts of the document that describes how engine spool and response works is finished but what's missing is how to apply that knowledge practically.
If anyone wants a copy of the document in its current shape, send me a PM. The reason for distributing it in this weird fashion is because I don't want to upload an incomplete copy of it.
 
Your interpretation of 1505 is incorrect. These tables are designed based on a real world charting system. All 1505 was intended to do was give the corrected (SSL) fuel flow of the engine, which would allow you to determine exact fuel flow at an altitude or speed per RPM. They couldn't get it to work (because the didn't realize they had the net thrust fuel bug) so they disabled it and let that table control engine spool. That is ALL 1505 does. The sim does not use 1505 for any other purpose. It still tries to compute the equation but it's not applied to fuel flow. If you set a flat line in 1505, the engine will stop spooling at that CN2 value and fuel flow burned from your tanks will equal net thrust * tsfc. If you set that table to a vertical line the CN2 will spool instantly and hold the top value. Fuel flow will still equal FN * TSFC.


Fuel flow in all MSFS = NET THRUST * TSFC

Had they did GROSS THRUST * SFC it would've worked just fine. They sim already corrects the fuel.

Had it worked, table 1505 would have allowed manipulation of engine efficiency at various RPM
 
and CN2 is driven by throttle position. If the engine is on and you set throttle position to 0 CN2, the stupid sim will maintain that RPM and burn ZERO fuel, while COMBUSTION = 1
 
Your interpretation of 1505 is incorrect. These tables are designed based on a real world charting system. All 1505 was intended to do was give the corrected (SSL) fuel flow of the engine, which would allow you to determine exact fuel flow at an altitude or speed per RPM. They couldn't get it to work (because the didn't realize they had the net thrust fuel bug) so they disabled it and let that table control engine spool. That is ALL 1505 does. The sim does not use 1505 for any other purpose. It still tries to compute the equation but it's not applied to fuel flow. If you set a flat line in 1505, the engine will stop spooling at that CN2 value and fuel flow burned from your tanks will equal net thrust * tsfc. If you set that table to a vertical line the CN2 will spool instantly and hold the top value. Fuel flow will still equal FN * TSFC.


Fuel flow in all MSFS = NET THRUST * TSFC

Had they did GROSS THRUST * SFC it would've worked just fine. They sim already corrects the fuel.

Had it worked, table 1505 would have allowed manipulation of engine efficiency at various RPM
The calculation is done as follows, although quite a bit simplified:
  1. Interpolate 1503 and 1504 to get a CN2 target based on mach, throttle and IAP.
  2. Calculate corrected fuel flow using the following equation: CFF_new = (CN2_target - CN2_current) * fuel_flow_gain * static_thrust * delta_time + CFF_current
  3. Calculate the fuel flow constant k using this equation: k = CFF_new / static_thrust
  4. Get a new CN2 value from 1505. The input is the fuel flow constant from above just like the SDK says.
  5. Apply a first order lag on the CN2_value from 1505 to get the final CN2. Note that the time constant in this first order lag function is calculated based on the CN2 from step 4, so the time constant is not a fixed number.
Step 2 and 3 is basically the fuel controller. (for CFF, not FF!)
During startup (prior to combustion) and shutdown, the time constant in the first order lag function at step 5 becomes fixed at 0.1. Step 4 is replaced by CN2=25% or CN2=0%.

It is 100% correct that the target CN2 is driven by throttle position (1503 and 1504), however the actual CN2 is the output from 1505 (if there is combustion).
Let's say that you command a CN2 that is higher than the highest CN2 in 1505. In that scenario, CFF will increase towards infinity as the fuel controller is desperately trying to increase CN2 towards the target CN2.
If the commanded CN2 is lower than the lowest CN2 in 1505, then the fuel controller will decrease CFF and once CFF becomes 0.0 the engine(s) will shut down because one of the combustion requirements is that CFF > 0.0.

EDIT: If the commanded CN2 < 20% and the lowest CN2 in 1505 is lower than 20%, then the engine will die as soon as it goes below 20%. CFF has a lower limit of 0.0001 when there is combustion to keep the engine from dying.
This is due to the fact that one of the combustion requirements is that CN2 >= 20%. If you had the starter engaged in this scenario, the CN2 oscillated around 20%. The reason for this is that once the combustion goes out (CN2 < 20%), then the CN2 at step 4 becomes 25%, meaning that the CN2 will increase again. Once the CN2 becomes 20%, then step 4 becomes active again, however since 1505 outputs a CN2 lower than 20%, the engine will go below 20% again, where it will bounce back and keep doing this over and over until either the starter is switched off or you select a CN2 target that is 20% or higher.
I shouldn't write technical stuff when I'm tired...

Very simplified, for a running engine:
1503 & 1504: commanded CN2
1505: actual CN2 (the first order lag is also applied)
 
Last edited:
Here's some actual data (measured and calculated): https://www.dropbox.com/s/c4a681sucx7sl3l/Engine Spool Rate.xlsm?dl=1.
I wrote some custom functions in VBA to make the calculations easier. If you want to see what actually happens inside these functions, just enable the Developer tab in Excel and click on Visual Basic.
Note that you need to enable macros if Excel asks you whether you want to enable them or not.
 
Last edited:
Back
Top