• 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.

Any variable or similar for turbulence

Messages
407
Country
ca-britishcolumbia
Is there anyway for a gauge to know if the aircraft is in turbulence? I am thinking of modelling random engine flameouts in certain conditions if the user forgets to turn on continuous ignition when appropriate.
 
Not that I know of, but you could use a delayed timer to track wind direction and wind speed and then compare it to the current direction and speed. Any large deviation would then indicate turbulence and provoke a flameout.
The disadvantage, however, is that people not using any weather tools or FSUIPC providing a wind smoothing algorithm will probably always experience flameouts while people using said tools will proabably never experience flameouts. Makes a bit unfair in my book.
 
I think you could check abrupt fluctuations in (G Force) Avar, or abrupt changes in Roll and Pitch variables. All of those are actually taken into account to detect level of turbulence in real FDR analysis.
I never tested that condition in FS, would be great to know if it can be measured with a reasonable precision.
 
Just because it is considered possible though improbable that turbulence might cause a flame out, some aircraft manufacturers have recommended switching on continuous ignition if turbulence is expected. IMO this ranks right up there with the warnings in every user manual for domestic appliances. Such as "never place your phone in a microwave oven as it will cause the battery to explode" or "do not use this snow thrower to remove snow from your roof"

I got fed up with turbulence causing aircraft in FSX to flip over and crash when flying on autopilot at low altitude. I even witnessed an AI aircraft do it on the approach, so I always turn it off now. But I did have a check on what level of force was used or just how is it done. Seems there are violent inputs of accelerations whose values are easily recorded. Enough to oppose full manual aileron and completely overcome the standard autopilot.

So why seek to punish someone for not doing something completely unnecessary. How may instances have been recorded of engines flaming out in turbulence?
Roy
 
The aircraft manual requires continuous ignition for take off and then whenever the crew deems it advisable such as during "moderate to heavy turbulence". It is also recommended when engine de-icing is on to reduce the risk of flameout due to ice ingestion by the engines. Wikipedia describes a risk of flameout occurring typically at idle power due to moderate to heavy turbulence, rain or hail. Some examples are given, one involving hail and another with rain, hail and turbulence, but I haven't seen any discussion of a statistical nature.

I thinks Tom's idea of measuring rapid changes in g-forces, or Bjoern's idea could work but sounds complicated and I am trying to keep things not too difficult at this point to get the project finished. I think I will go with a low random possibility of flameout at or near idle with precipitation or with ice present and engine de-icing turned on. The probability of a flameout will be very low. Not really necessary, but one doesn't like to have an operable switch in the aircraft that is completely pointless.

Generally, I am not modelling any failures on the grounds they so rarely happen and also because it would greatly increase the time needed for coding. So I could easily exclude flameouts on the same basis, yet for some reason I would like to have a go at it.
 
I use (A:AMBIENT PRECIP STATE, enum) as part of an algorithm to determine runway braking in poor weather. i.e. heavy rain or slush. Also (A:SURFACE CONDITION,enum).
(A:AMBIENT PRECIP STATE, enum)
has 3 determiners
Precip state (bit field)
2 = None
4 = Rain
8 = Snow

(A:SURFACE CONDITION,enum) has 4
One of:
0: Normal
1: Wet
2: Icy
3: Snow
From the point of view of using igniters, anything below +10c in conjunction with
Precip state (bit field)
4 = Rain
8 = Snow
and/or
1: Wet
2: Icy
3: Snow
will require igniters. So failure to switch them on could precipitate (pun) a flame out. That you can do with a timer.
 
Last edited:
Just a note... Carenado added some engine failures to their King Airs... and it didn't go over too well. The ability to disable this would probably be a really good idea.
 
"Too complicated" and "random possibility" in the same sentence doesn't really work as the latter is much harder to implement than the former. ;)


To drive my point home how comparatively easy it is to detect rapid changes in wind paramters, here's a setup I'd use for detecting wind shear. The detection criteria are according to the FAA, i.e. a rapid air speed change of 15 knots (absolute) or 500 fpm (absolute).

Code:
(E:Absolute Time, seconds) (L:Wind Change Start Time, seconds) - 1 >
if{ (E:Absolute Time, seconds) (>L:Wind Change Start Time, seconds)
(A:AIRSPEED INDICATED, knots) (>L:Airspeed Delayed, number)
(A:VERTICAL SPEED, feet per minute) (>L:Vertical Speed Delayed, number)
}

(A:AIRSPEED INDICATED, knots) (L:Airspeed Delayed, number) - abs 15 >
(A:VERTICAL SPEED, feet per minute) (L:Vertical Speed Delayed, number) - abs 500 > or
(L:GPWS Wind Shear Alert, number) 1 < and
if{ 1 (>L:GPWS Wind Shear Alert, number) }

(A:AIRSPEED INDICATED, knots) (L:Airspeed Delayed, number) - abs 15 <
(A:VERTICAL SPEED, feet per minute) (L:Vertical Speed Delayed, number) - abs 500 < and
(L:GPWS Wind Shear Alert, number) 0 > and
if{ 0 (>L:GPWS Wind Shear Alert, number) }

The key here is the timer which updates the delayed AS and VS values every second. These are then compared to the current values and if a deviation larger than 15 knots or 500 fpm is detected, the XML variable for the wind shear sound (and warning light) will be triggered.

I'm using a similar method to simulate compressor stalls on the #2 engine /the one with the duct) of a 727 during certain cross wind conditions. In that case, I'm using the delay timer to track N1 increase and, once the limit for normal operation is exceeded, I'm using XMLTools to artificially induce a RPM fluctuation and play an appropriate sound file.
 
Lots of good ideas here.

WarpD: You think it would be frustrating? All I am considering is something like a 1 in 100 chance over the time of a descent in precipitation of a flameout if continuous ignition is not on and something similar if de-icing. So it would be a very rare occurrence.
 
Back
Top