Jet Engine Performance

[taguilo]

... The engine isn't failing because of 1502. It is failing because the N2 has declined below the red line in table 1505.

I never touched 1505, and besides N2 never declined below idle (62%) and also FF never falled until the engines quit. The failure happens because, as there is no N1 rotation, oil pressure is 0. Another wrong conclusion

So, my own's is:

FSX thrust is indeed affected by the values of CN1 and CN2 returned from tables 1502 , and indirectly 1503 and 1504. They are not merely cosmetic or gauge-reading. Period.

If you were to take that same table you asked me to import and set your thrust 1506 "0 CN1' column to let's say 1.00 at all mach, you would get full static takeoff power at all mach, corrected for altitude.

That is pretty obvious I'll have full power with the engines off because I indicated so in the table for 0 CN1, which precisely means that CN1 is taken into account!

And though you may think I am wrong, and that's okay... you aren't grasping the concept of how the air file works.

I already told you once, and I repeat: either you are still confused about some concepts in FSX dynamics, or you are unable to express them in a proper way for us to understand you.

Tom

 

[Roy Holmes]

Although I said that I was not going to post again in this thread, on reviewing what I said in post #51, I do need to make a correction.

1503 and 1504 do set N2 according to throttle position and Pressure ratio. However N2 sets N1 in 1502 and N1 sets thrust in 1506. Therefore 1503/1504 are the mechanism by which thrust variation with altitude is calculated in FSX.

I should have said 1503 and 1504 are the tables that need to be adjusted to affect the rate of thrust variation with altitude. The actual variation is calculated in 1506 by the term delta2 in the formula
Gross Thrust = Static Thrust * [TBL 1506] *delta2
where delta2 = delta*(1+(M^2)/5)^3.5
and delta is Air Pressure Ratio.(APR)

The formula could be written for better clarity as:
Gross Thrust = Static Thrust * [TBL 1506] * APR * (1+(M^2)/5)^3.5.

My apologies for this error.

Roy

 

[jx_]

The failure happens because, as there is no N1 rotation, oil pressure is 0. Another wrong conclusion

No, you are incorrect. It looked up the 0 CN1 column in table 1506 and used whatever value is there to plug into the thrust calculation. I don't know what panel you used, but without custom gauges interfering, an engine in FS will remain lit with 0 N1 and 0 N2, while producing WHATEVER thrust is looked up in 1506 0 CN1 column. The only thing that will cause it to fail without failures or gauges is N2 falling below the x=0 in 1505.

You also claim N1 rotation is needed to produce thrust, which is also incorrect, but then you try to justify your position by saying:

"That is pretty obvious I'll have full power with the engines off because I indicated so in the table for 0 CN1, which precisely means that CN1 is taken into account!"

All it really means is it uses CN1 to look up the CN1 column in table 1506, nothing more. You give the sim too much credit. It definitely doesn't simulate oil pressure failures without custom gauge code.

I never touched 1505, and besides N2 never declined below idle (62%) and also FF never falled until the engines quit.

In 1505, x=0 at y=ignition CN2 is the point by which minimum combustion fuel flow must be maintained or the engine will die. Minimum combustion fuel flow in FS is:

SSL thrust * number of engines * TSFC * approx~0.671xxxx

I don't know by how much this number varies, but I do know it sets the initial fuel flow you see when the igniter fires during start up in all gauges that read raw MSFS fuel flow. It also affects the CTRL-E auto-start ignition point.


The N2 number is defined by the CN2 table, but the sim doesn't care what that CN2 number actually is. It's just an numerical value at that point.


Another way to think about it is to set all your CN1/CN2 tables back to normal, then set your 1505 to decline below x=0 at some other y=CN2. While you advance the throttles forward, and while the CN1/CN2 charts are commanding a higher RPM, CN1/CN2 and fuel flow will decline per 1505 until the engines die below x=0. If thrust was fan speed dependent this would not be possible.

Or try setting your 1505 to a straight line and watch the CN1/CN2 tables become completely useless. They will have no effect whatsoever, other than the look up of 1506 CN1 column, which will remain constant at the red line no matter what.

The CN1 and CN2 tables are used for look up referencing only. They calibrate the throttle to the visual gauge, simulate mach/airspeed/altitude changes in fan speed, and allow you to calibrate the gauge indications to the desired thrust pounds and fuel flow.

You can even reverse CN1/CN2.... meaning flip the engine backward so that off is at 100% CN2 and full throttle is at 0% CN2, and FS will calculate the thrust as if it is normal.

You can produce negative thrust and you can produce negative fan speeds. Fan speeds and thrust are independent of each other.

 

[jx_]

The actual variation is calculated in 1506 by the term delta2 in the formula
Gross Thrust = Static Thrust * [TBL 1506] *delta2
where delta2 = delta*(1+(M^2)/5)^3.5
and delta is Air Pressure Ratio.(APR)

The formula could be written for better clarity as:
Gross Thrust = Static Thrust * [TBL 1506] * APR * (1+(M^2)/5)^3.5.

My apologies for this error.

Roy

Welcome back Roy,

And as you can see, no reference to N1/N2. As I said earlier in layman's terms: SSL thrust * 1506 factor lookup * altitude/temp corrections = Fg - air flow factor scaling = FN

I should have said 1503 and 1504 are the tables that need to be adjusted to affect the rate of thrust variation with altitude.

You should say 1503 and 1504 are the tables that need to be adjusted to affect fan speed differences at altitude and Mach. That is all those tables change, the N2-->N1 speed that is produced by altitude at Mach. If your aircraft has no change in N1 with altitude or mach, all rows of 1503/1504 would be the same. And then you would realize the air file and fan speeds have no control over thrust changes with altitude. It's a separate calculation.

 

[Roy Holmes]

as you can see, no reference to N1/N2.

The reference to CN1 is [TBL 1506]. If CN1 is zero the table will output zero and thrust will be zero. Pretty obvious that an engine that is not rotating will produce zero thrust, I would have thought
Roy

 

[taguilo]

No, you are incorrect. It looked up the 0 CN1 column in table 1506 and used whatever value is there to plug into the thrust calculation. I don't know what panel you used, but without custom gauges interfering, an engine in FS will remain lit with 0 N1 and 0 N2, while producing WHATEVER thrust is looked up in 1506 0 CN1 column. The only thing that will cause it to fail without failures or gauges is N2 falling below the x=0 in 1505.

Ok, see the attached pictures of the the default CRJ700 that was used in the tests. I doubt it has a custom gauge to manage engine failures due to lack of oil pressure. Anyone can repeat my tests and sum to the evidence.

You also claim N1 rotation is needed to produce thrust, which is also incorrect, but then you try to justify your position by saying:

"That is pretty obvious I'll have full power with the engines off because I indicated so in the table for 0 CN1, which precisely means that CN1 is taken into account!"

All it really means is it uses CN1 to look up the CN1 column in table 1506, nothing more. You give the sim too much credit. It definitely doesn't simulate oil pressure failures without custom gauge code.

Again, lets start from the basics, and summarizing:

1) FS "generates" thrust according to the Y values of table 1506 (plus other additiona data). If all of the columns have Y=0, the aircraft will stay still on the tarmac at any X (CN1) value. I hope you agree with this elemental statement.

2) In any 2D table, for an Y value to exists, it needs first to exists an X one.

3) X values in table 1506 are related to CN1 values. As Y values depend on X column values, we can agree that thrust values (Y) will depend on CN1 values (X), can't we?. CN1 is a measure of rotation in percent, then it's not wrong to say N1 rotation values affects thrust values.

4) Finally, where does FS take CN1 values from? Obviously, from table 1502; then it isn't wrong to say thrust values in table 1506 depend on CN1 values in table 1502.

If you still question these basic conclusions, then I'll give up, sorry.


Tom

 

[jx_]

The reference to CN1 is [TBL 1506]. If CN1 is zero the table will output zero and thrust will be zero. Pretty obvious that an engine that is not rotating will produce zero thrust, I would have thought
Roy

ONLY if 1506 CN1/0 column is zero. If it is anything other than 0, that factor amount of thrust will be produced with a CN1=0 fan speed.

 

[Roy Holmes]

OK I give up. Why would any sensible person give a non-zero value for the thrust scalar at Zero CN1. Get real
Roy

 

[jx_]

hello Tom,

1) FS "generates" thrust according to the Y values of table 1506 (plus other additiona data). If all of the columns have Y=0, the aircraft will stay still on the tarmac at any X (CN1) value. I hope you agree with this elemental statement.

No, it finds the factor number to plug into the thrust equation by looking up the field AT row by column. These are interpolated to the header values of the table, not interpolated by CN1/Mach. (good to know because you usually get bumps at the intersecting whole value instead of a smooth slope...)

But I agree if all thrust fields have one figure thrust will not change, of course.

2) In any 2D table, for an Y value to exists, it needs first to exists an X one.

??? The Y value and the X value exist on their own.... not sure I follow you here. X/Y are look up values from somewhere else. In the case of these tables, Mach by CN1. Those values are separate. If the look up source was airspeed it would just look up the CN1 column value closest to the airspeed result it got when it inquired.




_______________| MACH lookup = 0 | MACH lookup = 0.50 | etc...

CN1 lookup = 0.00 | field value__ N _ | field value__ N ____ | etc
CN1 lookup = 0.10 | field value__ N _ | field value__ N ____ | etc
CN1 lookup = 0.43 | field value__ N _ | field value__ N ____ | etc

etc...


The field value is what determines thrust. I could make two completely different N1 tables that output the exact same thrust easily. I could even model an afterburner using just 1506 if I wanted to. The only thing I haven't been able to get the airfile to do is make me breakfast....

3) X values in table 1506 are related to CN1 values. As Y values depend on X column values, we can agree that thrust values (Y) will depend on CN1 values (X), can't we?. CN1 is a measure of rotation in percent, then it's not wrong to say N1 rotation values affects thrust values.

4) Finally, where does FS take CN1 values from? Obviously, from table 1502; then it isn't wrong to say thrust values in table 1506 depend on CN1 values in table 1502.

As I said, it is just a look up reference to calibrate visual gauge info to thrust pounds. If you grasp that you will realize CN1/CN2 tables only affect throttle relationship and visual gauge changes with mach and altitude. The final thrust factor look up can be set to whatever output you want that N1 to be, but FS does not take N1/N2 into account when calculating gross thrust and then applying the air flow and temp/altitude adjustments. Those calculations are separate with absolutely no consideration for N1.

So, if let's say for example, you wanted to bypass the FS starter and make your own starter system... you could set all your CN1 to be +20 of the real values and adjust your thrust table accordingly, then tell your gauge code to - 20 the N1 or whatever math you need to do, and put your starter system in between. There are a million scenarios that could be cited and twice as many reasons why someone may want to try a different way of achieve realistic performance. Maybe you want more precise control of the throttle to thrust table 1506 and use 0-1000% CN1 instead of the incorrect assumption that the table stops at 130 as cited earlier in this thread.... (the gauge code has a ceiling value in the display if you see a limit, the N1 variable will go to anything...the highest I have seen is 1810%.)


But the whole point of this conversation was because Roy claimed the problem he has with high altitude thrust fall-off is a result of the CN2 table adjusting with IAP instead of density. That's just not true, high altitude thrust adjustments are independent of N1/N2 settings. There is nothing we can do about the thrust calculation, but there are things we can do to make 1506 work right, but the number one issue is with SFC.

 

[jx_]

OK I give up. Why would any sensible person give a non-zero value for the thrust scalar at Zero CN1. Get real
Roy

Because that's the only way to illustrate to you, and anyone else who doesn't understand the thrust logic, how the sim is programmed.

It is software code, and the software code only considers what is directly within it's equation. The MSFS thrust equation takes no consideration of fan speeds in 1502/1503/1504.

This explains why a non-zero value at zero CN1, or even a negative thrust value anywhere, produces thrust accordingly, regardless of fan speeds.

 

[WarpD]

This explains why a non-zero value at zero CN1, or even a negative thrust value anywhere, produces thrust accordingly, regardless of fan speeds.

You just referenced a fan speed (zero CN1) and then stated fan speeds have nothing to do with thrust calculations. CN1 is a fan speed. You can't claim it as anything else but. If the thrust value (the 'Y' value) is directly tied to a fan speed (the 'X' value), then since the 'X' value is CN1 which is a fan speed... thrust is directly tied to fan speed.

In short... 'zero CN1' is a fan speed.

 

[jx_]

I didn't reference a fan speed, I referenced the title of a column. We see "CN1", the sim sees a column ID#...

What you just described is a simple table 1506 look up. That is the full extent of their relationship. What they are claiming in this thread is that fan speed affects the thrust calculation, particularly at different altitudes. It could be 0 N1 or 10,000 N1... the sim doesn't care. It will simply look up the thrust factor in 1506 and do the math.

Thrust can go up while fan speeds stay constant, and vice versa.

The original claim was that the calculation of thrust reduction with altitude is tied to CN2 fan speeds which are slaved to IAP... and that thrust fall off would be correct if MSFS used density instead of pressure, but that's just not the case. (please read the whole thread next time)

The fields of table 1506 that are looked up are dependent on fan speeds... then carried to a separate thrust equation.

They are then plugged into an equation that is oblivious to fan speeds and will spit out its thrust value regardless of what nonsense the fans may be doing. There is no "is the engine accelerating or decelerating?" or "is mass airflow increasing?" or any other kind of intelligent logic going on behind the scenes.

It will not say OMG, the N1 speed is 350% so the engine must be disintegrating!

It will not say !!!, the fan is spinning at 100,000 rpm with an inlet area of 40 square feet, which means thrust should be increased to: [insert complicated mass airflow equation here].

and it will not say hey, we're using pressure instead of density to come up with our N2 speed so that means I should reduce thrust output because pressure falls off before density.

It doesn't even care if you are burning 4,000 pounds per minute or 400... it's just a number to the sim. In the real world, one pound of fuel produces an exact amount of heat energy, but in the sim it's all just a bunch of numbers and scalars.


So if fan speeds and the 1506 thrust value were set to a constant, but altitude/temperature/airspeed etc.. changed, thrust would also change, because it's calculation within the sim engine is not dependent on 1502, 1503, or 1504.


The CN1/CN2 tables are simply pointers. What they point to is totally up to the designer. If you have a problem with your thrust, it's not the thrust calculation, it's where you are pointing the table look up to.

 

[jx_]

and furthermore, for those who really don't believe me... I can and have built an airfile that increases thrust with no change whatsoever in fan speeds.... idle, off, 58% whatever you like. This would not be possible if fan speed was a consideration.

 

[taguilo]

??? The Y value and the X value exist on their own.... not sure I follow you here. X/Y are look up values from somewhere else.

Oh, Ok, I knew that finally I would find the source of your confusions.

So, if Y and X values exists on their own, from where does the sim take its sources to calculate thrust???? How come that they are from "somewhere else"...from the Moon maybe?.

Look, I see you've done a lot of value research, and that should be appreciated, but the sad thing is that you've arrived to very wrong conclusions just because you have no idea on how data is extracted from a table to give a resulting value.

FS doesn't use tables for decorative or look up reasons, they are used to obtain critical data -extracted from Y fields- by searching through source -and previously known- data, located on X fields. This is a math fact, then it can't be discussed by you, me or anyone else. And of course it's not a sole property of FS, but any other software that uses 2D tables to find and extract related values. Equations used in the extraction are linear, polinomial, logarithmial, etc, etc. I recommend you do some research on these concepts, I'm sure you'll get the point, finally

Now, what happens when you build one of those tables?

-First, you define for each column (X) value, which value corresponds to extract, and put that in the (Y) field.
-Then the software will take (X), which was previously obtained from other source/table, find the proper position of the (X) column, make the interpolation and finally extract the matching (Y) value; for example to obtain Thrust (Y) FS uses CN1 (X) as data source. Notice that Ed (WarpD) is telling you exactly the same:

.. thrust is directly tied to fan speed.
In short... 'zero CN1' is a fan speed.

Because that's the only way to illustrate to you, and anyone else who doesn't understand the thrust logic, how the sim is programmed.

I honestly hope that you now understand it is otherwise.


Tom

 

[jx_]

No, Tom I totally understand tables and arrays... what you're not getting is how software thinks. You are presuming software thinks like a human.

and you are also confused with X and Y. If X is CN1, then Y is Mach not thrust. That produces the coordinate to find the two columns and two rows that the sim will look at to interpolate a thrust factor variable. This variable is committed to memory, then on the next pass, sent to the thrust equation.

Within that thrust equation, there is no consideration for fan speeds.

One more thing, it is impossible to use a table in any other way than a look up. smh.

Every time you look at a calendar, you are doing a table look up, but you need a pointer. The pointer doesn't give you the result, but it shows you where to FIND the result. Oh hey, look it's Friday the 13th....

CN1 tells FS where to find the columns to look at to interpolate and extract the thrust factor variable that will be plugged into the thrust equation.

 

[taguilo]

No, Tom I totally understand tables and arrays... what you're not getting is how software thinks. You are presuming software thinks like a human.

Hmmm...maybe you're right; after 25 years of programming software, sometimes I can think that, indeed

One more thing, it is impossible to use a table in any other way than a look up. smh.
Every time you look at a calendar, you are doing a table look up, but you need a pointer. The pointer doesn't give you the result, but it shows you where to FIND the result. Oh hey, look it's Friday the 13th....

Looking at a calendar is different than extracting a value from an FS table.
In the calendar you already know which X and Y fields to link. In the table, the software knows only the X value and uses an ecuation to find the matching Y value. The calendar is a true lookup, an equation table is not IMHO.

CN1 tells FS where to find the columns to look at to interpolate and extract the thrust factor variable that will be plugged into the thrust equation.

I see you are getting the point...If CN1 tells FS where to find and extract the thrust factor variable...then the thrust factor variable extracted will depend on which value CN1 tells FS to use in the search...ok? (simple reciprocity).
Conclusion= thrust factor variable depends on CN1 variable.

Now we're coming to a principle of understanding...

Tom

 

[jx_]

no again, because you are concluding that "Conclusion= thrust factor variable depends on CN1 variable" covers all scenarios without investigating alternatives.

I am speaking of actual results, but I am obviously talking to someone who is set in their own 'beliefs' so it doesn't matter. Also, as I explained to Ed, the original argument is that 'high altitude is producing less thrust than it should due to CN2 using IAP instead of density.' You are talking as if you think I am saying 1506 doesn't need a pointer. I've been calling it a pointer the whole time, because that is ALL it is. A column pointer. It is NOT included in thrust calculations, it just points to a column.


Also, you are still wrong about the x & y.... y is Mach, you can't look up a table without both x & y. The thrust factor is not Y. X down, Y across... Thrust factor is a field at the intersection of x,y. There is no equation to find Y.

and in the calendar example, I wouldn't know where to look if I don't already have it in memory. I would need to ask someone for a week by day or date by month! If I already know, it is in memory (the stack??) and everyday when I wake that value is ++ incremented.

 

[WarpD]

Y is definitely not mach. Wow.

Oh... and snide remarks about how I need to read the whole thread (been here from the start, actually) are totally inappropriate and uncalled for. You do not need to be rude.

 

[Roy Holmes]

There have been several incorrect inputs in this thread concerning the method I have used to

get a fall off in thrust with altitude in FSX that tracks with that in Engine Sim and the real

world. The aim of this post is to explain the whole method in simple terms so it can be easily

understood.


My initial reason for developing the method was that full throttle Mach always decreased as

altitude was increased in FSX whereas it should slowly increase to a higher value and peak

around the tropopause. Since one of the factors that governs maximum Mach is net thrust I

started comparing FSX net thrust with Engine Sim net thrust as altitude is increased. I have

Flight Manuals that include performance data for all of the 15 jet fighter/trainer models whose

FDE I have worked on and they all showed FSX high altitude performance to be too low. In

addition to Max Mach, ceilings were always too low.

My starting point in DFE/air file development has always been to use Jerry Beckwith's excellent

Flight Dynamics Workbook because it calculates the correct aerodynamic coefficients based on

the input of specific data for the subject airplane. That way I can be sure that the

performance is not skewed by incorrect results for induced drag, for example.The workbook will

give performance points within 1% of FS results, because it uses the exact same calculations.

The only problem is that the thrust/altitude results do not match Engine Sim or real world

values.

At low altitude FSX thrust is correct. The problem is how to reduce the thrust loss as altitude

is increased. To keep it simple I will consider two points, low (around 500 ft msl) and high (

around 40,000 ft msl)

Any adjustment to the scalars in 1506 will increase thrust at both low and high altitude. So

1506 by itself will not do the trick.

1503 and 1504 are the tables that directly input IAP, so this is where to make changes. What I

have done is to make the values of CN2 higher in the rightmost column (high altitude) than in

the center column (low altitude). This obviously causes CN2 to increase with increasing

altitude. Because I am concerned with maximum performance, I use full throttle in all

calculations.

Since 1502 controls CN1 according to CN2 the increase of CN2 with increased altitude in 1503

and 1504 is reflected by a corresponding increase in CN1 with increased altitude.

Finally, in 1506, the increase in CN1 with altitude increase means that higher value scalars

are used and the gross thrust fall off is reduced.

Using this method I can make FSX thrust track EngineSim thrust with less than 1% difference at

low altitude and at whatever IAP I use for high altitude. In between the maximum error is 1.8%

low, due to only having two IAP columns at present. With two columns FSX does a straight line

interpolation of a curved function which can be mitigated by one or more in-between IAP

columns. I have not done that yet only because it adds a further complication to my

spreadsheet. Flight tests confirm that the thrust, maximum Mach values and ceilings now track

with the Flight Manual data for the test airplane and the spreadsheet calculated values.

When I first started looking at this subject I was of the opinion that thrust should decrease

with density ratio squared (sigma squared) rather than with pressure ratio. The drop-off with

thrust in EngineSim for zero Mach is much closer to sigma squared than air pressure ratio.

Non-realistic situation, but I wanted to isolate Mach effects in the equations and just look at

altitude effects. Density is one of the factors causing thrust decrease with altitude and is

significant if you use N1 in your calculations


However FSX uses corrected N1 (CN1). The correction involves dividing N1 by the square root of

total temperature ratio using degrees Kelvin. In this case the thrust decrease will be with

pressure ratio, because of the relationship between density, pressure and temperature in

degrees Kelvin.

The reason for using "corrected" values that I have read is that it simplified creating charts

of thrust versus speed and altitude. Instead of having a different chart for thrust versus

speed and N1 for each altitude, because thrust is a function of density, using corrected CN1

allows the presentation of the data for all altitudes on one single chart.

To sum up. FSX thrust does decrease more rapidly, with increase in altitude, than it should

based on flight test data in Flight manuals and EngineSim. Given the equations in FSX that we

are stuck with, the only way I can see of offsetting the decrease is to increase CN2 in

1503/1504 at high altitude, which increases CN1 in 1502 and the CN1 increase in 1506 restores

some of the thrust decrease.

Naturally, in a quest for realism, all of the tables have values aimed at creating a realistic

result, since realism is the goal of any FDE work.

Roy

 

[taguilo]

no again, because you are concluding that "Conclusion= thrust factor variable depends on CN1 variable" covers all scenarios without investigating alternatives.

This is pure blah blah, sorry.

Also, you are still wrong about the x & y.... y is Mach, you can't look up a table without both x & y. The thrust factor is not Y. X down, Y across... Thrust factor is a field at the intersection of x,y. There is no equation to find Y.

Now you're confusing a grid (or 3Dtable) which is a reference element, with a 2Dtable, or equation table, which is the one needed for calculations ...
Ok, just take a look at the attached picture, it's a 1506 table from the default CRJ-700. Can you see the references? Can you read, top right, "Corrected Thrust Factor (Y axis) vs. CN1(X axis) and Mach number"??
Can you read , bottom center, "Thrust Factor Y = 0.281 CN1 X = 45"??
Can you realize that there are two tables implicit in the grid, one for CTFvsCN1 at Mach0 and the other for CTFvsCN1 at Mach0.9 ???

As I suspect it's not going to be enough for you, let's take your own statements:
"Thrust factor is a field at the intersection of x,y. There is no equation to find Y."

Ok, I have this grid:

CN1        M0            M0.9
==================================
0	 0.00000        0.00000
20 	 0.02540	0.07409
25 	 0.05080	0.15929
30	 0.07983	0.25563
35	 0.11249	0.34829
40 	 0.20000        0.44457
45 	 0.28100	0.54086
50	 0.36800	0.70600

Suppose that I have a CN1 of 35, per your reasoning it's very simple, just use the 35 as a "pointer" and find the intersection of X,Y (your Y). I get 0.11249 and 0.34829. Great!. Then Thrust Factor for 35 CN1 are 0.11249 at Mach0 and 0.34829 at Mach0.9, because the table says so. Perfect!
Now I have a CN1 of 37.233 and a Mach of 0.672. So I go to the table but, hey, can't find a row (X) for 37.233 and also can't find a column (your Y) for 0.672, so how do I know which Thrust Factor corresponds to those values?
Just tell me, if you were the software programmer, what kind of calculation would you make to find that Thrust Factor?


Tom