Post by volkerboehme on Feb 2, 2009 12:17:52 GMT -5
I think it is well worth moving on to examine the consequence of outside air temperature (OAT) variation, but it wasn't the original question and doing so will turn this into a very long multi part post. The temperature reported in the original post was neither a data error nor a problem (outside of engine cooling).
First some further examination of the consequences of currents and waves, (wind vectors and gusts) in MSFS seems appropriate. Every equation has two sides. Input and output. In MSFS the amplitude and wavelength of gusts is calculated and input by the hard coded weather model. If the data supplied to the equations of the weather model are false then input made by the weather model to MSFS is false.
A rate of change of wind velocity (current) alone may cause a gust / wave. The merging of two opposed currents may cause a gust / wave. A gust / wave is just a variation of amplitude which also has has a defined wavelength. It is not a speed. It is a transient amplitude variation event. The gust / wave is not the current. The current influences vessel speed (KTS). The gust / wave influences vessel drag (KIAS) and will always also influence vessel pitch in a transient way which depends on the amplitude and wavelength of the gust / wave.
With real weather in use over an ocean in MSFS we will suddenly move from the real weather at one weather ship to the weather at a different weather ship maybe a thousand miles away. The current will be different, the temperatures will be different, the pressure will be different. The 'boundary event' is sudden in MSFS, but takes 1000 miles in real life. We encounter a fake wave / gust event at the sudden boundary.
Over land if two nearby weather stations have very different currents due to the topography of the terrain channeling the currents we will encounter a calculated gust event due to current mixing which is real. With real weather in use the weather model also calculates gusts as wind shear at vertical boundaries. It has both currents on either side of the shear and the transient gust consequences at the turbulent mixing boundary. We will encounter a (series of) gust(s) that are more or less realistic.
This is the problem for Microsoft. Too much smoothing eliminates real gusts. Payware FSUIPC eliminates some real gusts via its smoothing algorithms in order to eliminate fake gusts.
The underlying problem is that data entry clerks at real METAR stations do not pay sufficient attention to their work. Real pilots and controllers know the QNH is not 19.92. Our computer does not. If the real approach radar controller drove to work in a blizzard he knows the OAT must be -10 not +10 even if his screen says +10 so he broadcasts minus ten / blizzard not plus ten / blizzard whatever the screen says. Our computer just accepts +10C and falling snow. This cannot be error trapped. Neither FSUIPC nor any other program can tell whether -10 or + 10 is logical for London today. The weather in the UK is so variable that it could be either.
Smoothing causes loss of real data and full error trapping is not possible. Payware FSUIPC does a good job of protecting us from huge fake transient gusts but we lose some real ones. Its our choice.
However what happens is not a mystery. With real weather in use MSFS calculates the gust that should be created by rate of change of current or mixing of two currents at their boundary and imposes that wave / gust, whether real or bogus. That wave / gust is a transient event. We hit the wave, it adds profile drag, flow becomes turbulent, (spray is generated), and we also pitch up losing profile drag (IAS), and may stall, or we may pitch down, and may suffer structural failure.
If the IAS falls below Vbg <> Vx (the aeroplane is perturbed onto the wrong side of the drag curve), the wing continues to pitch up if no action is taken via power or elevator to prevent the imminent stall.
As far as Microsoft are concerned there is no bug in the real weather engine. The code is real. The events are real. The inputs it makes to MSFS are real. It is the data provided by real world METAR data clerks that is bugged. If we use real weather we live with it or we buy payware FSUIPC to smooth bogus gusts and suffer some loss of realism when the gust is real due to real wind shear or real topographical channeling.
A gust / wave is anyway not a current / tailwind or a headwind. Wind vectors cannot alter IAS. They can only alter KTS. Opposed wind vectors can cause a transient gust. It does not endure. It has a short wavelength. It is our job to cope with the gust event. It is our job to avoid stall and it is our job to avoid structural failure. Nobody can see huge waves coming at night in a boat either.
This is why we must not allow our profile drag (IAS) to exceed either Vno or Mno. If we do we must expect structural failure when we encounter a significant gust. Big unseen waves have been causing structural failure of vessels underway with excessive power applied causing excessive IAS for hundreds of years. In an aeroplane as we pitch up the wave we may also stall. The maritime equivalent would be capsize, but it is not an exact parallel.
None of this is a bug. It is the sudden data difference used to calculate the gust (wave amplitude) that may be false.
From time to time I try to illuminate the difference between the Flight Model (FM coded by Microsoft) and the aircraft specific Flight Dynamics (FD coded by third parties). The FM calculates all this stuff (more or less) correctly. The weather model also calculates (more or less) correctly. The problem is that fake data may be fed into the accurate Microsoft code. The FD author must research and encode realistic gust response for the specific aeroplane. Most simply don't bother or maybe they just think they should emulate the code in default Microsoft contractor FD.
Every equation has two sides. Input and output.
For years a series of third party FD authors have done their best to explain to the FS community that various parts of the aircraft specific code retailed by MS are broken. Everything from the scenery projection code in '2D panels' to more obscure things like gust response. Third party developers do not avoid creation of the exact same aircraft as Microsoft released. They know they can do better. One way that they can do better is to improve the output in MSFS. The other side of the equation.
Those who have flown a real C172/182 will know that the real thing does not behave like a leaf tossed around on the breeze in light turbulence, let alone in still air. The real thing is not unstable and undamped in still air. According to Microsoft and their 'expert contractors' Cessnas have little inertia, little stability, and little damping. In MSFS the default Cessnas are hard to move from one energy state to another in still air without bucking and yawing like a bronco. Amusing consumers with bogus 'head bobbing' in relation to tiny G forces that would not cause anyone to lose control of head position has replaced any attempt to release realistic default dynamics (or their physiological consequence).
Errors in the output side of MSFS equations are just as important as errors on the input side. They are less discussed and less understood, yet in some aircraft the output data is most of the problem. When the weather engine creates a realistic gust the specific aeroplane gust response is wildly wrong. Its FD have too little encoded inertia, stability and damping.
I think I can deduce why, but first an analogy which has some scientific inaccuracies, but may aid understanding. Imagine an Army truck is parked on a flat hard surface with the engine off, gear box in neutral, and the hand brake off. A child rides a bicycle into the rear steel fender at modest velocity. A force is briefly applied to the truck. The structure of the truck is not deformed and nor does it move. The truck is massive and has huge inertia. It also has high stability. It does not topple over.
Now imagine the truck is highly instrumented and the data is recorded by a black box. The needle on the relevant gauge (dynamometer =G meter) flicks up to record the impact. The data is recorded in the black box. The truck velocity is zero throughout. The speedometer needle never moves. An accident investigator is called in and he demands the black box data. He needs to know whether the truck was moving or stationary. He needs to know whether something impacted the vehicle. The black box data is used to produce time traces and discloses that the truck never moved, but that a G force was applied. The transient force failed to overcome the inertia of the massive vehicle which never moved. If the investigator knows the mass of the bicycle and its crew he can calculate its velocity at impact. The investigator does not confuse the trace which records the velocity of things that collided with the truck with the velocity they induced in the truck.
Each version of MSFS has introduced a different variety of bucking bronco called a Cessna 182, each said to be 'as real as it gets'. I deduce that somewhere in the mists of history either BAO or Microsoft obtained black box data for the Cessna 182 'gust response' and confused the trace of what happened to the needles on the gauges with the trace of what happened to the whole aeroplane.
When a real Cessna 182 departs into slight turbulence the pitot and static tubes detect rapid pressure fluctuations as gusts pass the pitot tube and static port. The mechanical parts of the gauges they drive have low mass and low inertia. they are usually poorly damped too. The ASI and the VSI may fluctuate rapidly. They are 'recording' air impacting the aeroplane faithfully. The stall warning horn sounds then stops, over and over again, as every gust impacts its reed. The passengers think the Cessna might stall, but the pilot knows that if he maintains the correct attitude = pitch = angle of attack the wing will not stall. He ignores the wildly fluctuation ASI and the VSI and targets the correct pitch. In light turbulence the aeroplane does not bounce around like the needles on those gauges. It is an army truck being impacted by a kid on a bicycle. Its inertia is not overcome. The acceleration induced in the entire high inertia vehicle in the x,y,z axes must be measured with a dynamometer (G meter) which creates a different set of traces to the traces which record the impacts.
Of course as the turbulence gets worse it will manage to 'move' (actually accelerate / decelerate) the entire aeroplane in space, but the needles that are showing how the air is impacting the massive aeroplane will move much faster and will fluctuate much more. The two things must not be confused. I believe that they were confused in the default FD a long time ago. Ever since slow but inadequate adjustments have been made to the default Cessna inertia and stability, but it still lacks realistic inertia and stability. This matters because third party FD authors plagiarise and extrapolate from what MS release, however broken it may be.
There is another FD content problem. CFS versus FS. Fighters are carefully designed to have low inertia and low stability in order to make them responsive. Transport aircraft are designed to have high inertia and high stability with excellent gust response, but they are less responsive. It is not just a question of relative mass and size. The design time intention is different. Third party air file compilers, and the help files of third party air file editors, often make false assumptions about the role of the aeroplane being encoded. A naval destroyer and a cargo boat do not share the same inertia, stability, damping, structural integrity, capsize probability, wave response, or handling even if they are the same length, and have the same mass.
The result is a huge number of FD released with inadequate inertia and stability. Their gust response is like a leaf in a breeze. They accelerate and decelerate too easily in gusts and are also toppled too easily by a realistic gust. A massive aeroplane with high inertia does not accelerate / decelerate in an instant to the velocity of the air impacting it. The VSI measures vertical SPEED increment. *Speed is relative*. In still air it is the aeroplane that is moving up through the air in the z axis. The VSI records aeroplane speed upwards. But when the air is moving downwards as we cruise the gauge cannot tell the difference. It quickly depicts the aeroplane as climbing when it is actually unmoved in sinking air. The gust ends almost as soon as it began and the aeroplane never accelerates to minus 300 VSI in the z axis. It may not sink at all or it may sink a little. It may acquire a z axis acceleration of -10 due to transient impact at -300. Nor is the aeroplane significantly toppled. It is stable. The real aeroplane does not pitch, topple and accelerate like a leaf when subjected to a breeze. Nor does it 'topple' when the pilot makes small control inputs to vary direction in any axis. It has been shaped so that it does not. It is stable as well as inert.
In a real Cessna the gauge needles react quickly because the inertia of the gauge mechanism is very low. They move all over the place recording air impacts correctly, the stall warning horn goes on and off, but if we target the correct pitch the massive aeroplane deviates up and down far less; and is not significantly toppled in the x or y or z axes either. In MSFS bad Flight Dynamics code (not Flight Model code, not Weather Model code), with inadequate inertia and stability encoded allows aeroplanes to be tossed around like leaves and the weather model is blamed.
There is another problem. All systems are damped. The long case clockmaker must control the inertia and stability of the pendulum, but he must also damp it so that the tick and the tock are exactly one second apart. Having been perturbed from rest by a transient force the pendulum returns to its prior status after a *designed* time constant. Remove the 'gusts' generated by the clockwork spring and it will soon be damped to rest. That will also take a very specific, but different, time interval.
Real FD authors design the damping of the aeroplane in all axes and it reverts to its prior equilibrium after the transient force is removed. Damping is the other principle component of responsiveness. 'Fighters' must have low inertia and be very unstable but superbly damped. When the pilot adds or removes an input force the motion must start / stop fast. Propliners are less responsive, but they are designed with adequate damping.
Like a pendulum (they are a pendulum) they revert to their prior equilibrium state without pilot input.....unless the aeroplane has been forced from the right side of the drag curve to the wrong side (is already so far perturbed that it continues to capsize). Well designed aeroplanes will stall at a much lower angle of upset than is required to capsize a well designed boat. This is another reason we always cruise close to zero pitch. We must make it difficult for the next big wave to pitch us up to stall pitch (capsize). If we cruise with substantial pitch we are vulnerable to stall in gusts. If we cruise nose down we are vulnerable to structural failure in gusts. On approach we must deploy flap to sustain low pitch (actually low angle of attack). If we don't have flap, or we fail to use flap to control pitch independently from flight path vector (glideslope), we are much more vulnerable to gusts on approach because we will already have invoked high pitch (actually angle of attack). If we fail to restrain pitch in descent, to restrain IAS in descent, we are vulnerable to structural failure during descents.
Many MSFS FD also have inadequate or excessive damping in relation to the designed role of the aeroplane. Many MSFS FD fail to associate design cruise power with zero pitch at design cruise altitude at design cruise weight. This makes the aeroplane more prone to stall in any gust during cruise. Many more FD fail to associate zero trim drag ('flippers neutral') with the same design condition. This leaves the human pilot and the AP without full elevator authority and without full trim authority, in one direction or the other, during recovery from gusts, (and all of the time).
So we suffer hundreds of excessively gust perturbed aircraft releases, which cruise at excessive pitch, even before they are excessively perturbed. Then most are too slow to recover prior equilibrium and require more rapid and more aggressive pilot intervention with power and stick than in real life. The need for 'realistic' FD does not just relate to realistic cruising velocities, realistic operational ceilings, realistic range versus fuel loaded etc, it also relates to handling and gust response, both of which depend on 'realistic' inertia, stability, damping, CL associated with zero pitch cruise, and trim authority (as well as other things).
Now please note that I am not claiming those values are correct in my FD. There is too little data in the public domain to know. Manufactures keep data for things like stability and damping secret. It has to be estimated and it is very difficult to estimate. For instance I never claim to estimate inertia to better than two significant figures, but most FD authors claim to have estimated it to eight. In many cases the encoded value is very precisely wrong, by more than 100%.
If the role of the aeroplane is transport then it is a good idea to simply encode values that err on the high side for inertia, stability and damping in each axis. The code in many FS releases has been very heavily influenced by code in CFS combat aircraft and is often wrongly extrapolated from 'fighter' values.
So, yes the MSFS weather model sometimes generates gusts of bogus amplitude due to data error, or bogus sudden boundaries between distant oceanic weather stations, but much of the problem is in the FD. And yes, currents can produce gusts (or not), but a wave / gust is not a current and in most cases a wave should only impose modest pitch up, (from near zero), causing modest IAS decay which should self restore. The bogus sudden boundary events should not invoke stall or structural failure from near zero pitch cruising. Even with most human data errors we should have time to avoid stall by addition of power and by pitching down. Save in some non propliner aircraft it should be possible to recover from stall, after stall.
We should never expect an AP to recover from stall and most may have maximum pitch rates that will not recover from the wrong side of the drag curve (IAS < Vbg <> Vx) without manual throttle addition. Using 'accelerated time' with AP ON does not manipulate all the pendulum time constants correctly within MSFS. We have all seen auto pilot induced oscillations (APIO) induced in still air as the AP servo control rates fail to cope with accelerated time and accelerated vehicle motion. When a gust is imposed in accelerated time an AP that would cope at 1x will not cope at 4x or maybe 16x. Nor in all probability would a human pilot. Yet for some reason there is an expectation that accelerated time should not impose additional stall / structural failure risk during gusts. It does and whether we add that extra risk is our choice.
If we use real weather we must accept that there will be data errors. They may cause departure from controlled flight. We can treat that as an emergency or we can just slew a few miles further on (not back!) and resume cruise knowing that what happened was a real world data error or a video game accelerated time error. Some of the human data errors will be so large that they will create gusts which even 'over realistic' inertia, stability and damping will not resist. Remember you cannot just increase those variables on their own after download without screwing up the flight dynamics in other ways at the same time. Lots of variables which do not appear to be involved in this stuff must move in concert with variables mentioned.
You may wish to take a break before reading Part 2 which deals with the outside air temperature (OAT) issues.
Continued in next post...
First some further examination of the consequences of currents and waves, (wind vectors and gusts) in MSFS seems appropriate. Every equation has two sides. Input and output. In MSFS the amplitude and wavelength of gusts is calculated and input by the hard coded weather model. If the data supplied to the equations of the weather model are false then input made by the weather model to MSFS is false.
A rate of change of wind velocity (current) alone may cause a gust / wave. The merging of two opposed currents may cause a gust / wave. A gust / wave is just a variation of amplitude which also has has a defined wavelength. It is not a speed. It is a transient amplitude variation event. The gust / wave is not the current. The current influences vessel speed (KTS). The gust / wave influences vessel drag (KIAS) and will always also influence vessel pitch in a transient way which depends on the amplitude and wavelength of the gust / wave.
With real weather in use over an ocean in MSFS we will suddenly move from the real weather at one weather ship to the weather at a different weather ship maybe a thousand miles away. The current will be different, the temperatures will be different, the pressure will be different. The 'boundary event' is sudden in MSFS, but takes 1000 miles in real life. We encounter a fake wave / gust event at the sudden boundary.
Over land if two nearby weather stations have very different currents due to the topography of the terrain channeling the currents we will encounter a calculated gust event due to current mixing which is real. With real weather in use the weather model also calculates gusts as wind shear at vertical boundaries. It has both currents on either side of the shear and the transient gust consequences at the turbulent mixing boundary. We will encounter a (series of) gust(s) that are more or less realistic.
This is the problem for Microsoft. Too much smoothing eliminates real gusts. Payware FSUIPC eliminates some real gusts via its smoothing algorithms in order to eliminate fake gusts.
The underlying problem is that data entry clerks at real METAR stations do not pay sufficient attention to their work. Real pilots and controllers know the QNH is not 19.92. Our computer does not. If the real approach radar controller drove to work in a blizzard he knows the OAT must be -10 not +10 even if his screen says +10 so he broadcasts minus ten / blizzard not plus ten / blizzard whatever the screen says. Our computer just accepts +10C and falling snow. This cannot be error trapped. Neither FSUIPC nor any other program can tell whether -10 or + 10 is logical for London today. The weather in the UK is so variable that it could be either.
Smoothing causes loss of real data and full error trapping is not possible. Payware FSUIPC does a good job of protecting us from huge fake transient gusts but we lose some real ones. Its our choice.
However what happens is not a mystery. With real weather in use MSFS calculates the gust that should be created by rate of change of current or mixing of two currents at their boundary and imposes that wave / gust, whether real or bogus. That wave / gust is a transient event. We hit the wave, it adds profile drag, flow becomes turbulent, (spray is generated), and we also pitch up losing profile drag (IAS), and may stall, or we may pitch down, and may suffer structural failure.
If the IAS falls below Vbg <> Vx (the aeroplane is perturbed onto the wrong side of the drag curve), the wing continues to pitch up if no action is taken via power or elevator to prevent the imminent stall.
As far as Microsoft are concerned there is no bug in the real weather engine. The code is real. The events are real. The inputs it makes to MSFS are real. It is the data provided by real world METAR data clerks that is bugged. If we use real weather we live with it or we buy payware FSUIPC to smooth bogus gusts and suffer some loss of realism when the gust is real due to real wind shear or real topographical channeling.
A gust / wave is anyway not a current / tailwind or a headwind. Wind vectors cannot alter IAS. They can only alter KTS. Opposed wind vectors can cause a transient gust. It does not endure. It has a short wavelength. It is our job to cope with the gust event. It is our job to avoid stall and it is our job to avoid structural failure. Nobody can see huge waves coming at night in a boat either.
This is why we must not allow our profile drag (IAS) to exceed either Vno or Mno. If we do we must expect structural failure when we encounter a significant gust. Big unseen waves have been causing structural failure of vessels underway with excessive power applied causing excessive IAS for hundreds of years. In an aeroplane as we pitch up the wave we may also stall. The maritime equivalent would be capsize, but it is not an exact parallel.
None of this is a bug. It is the sudden data difference used to calculate the gust (wave amplitude) that may be false.
From time to time I try to illuminate the difference between the Flight Model (FM coded by Microsoft) and the aircraft specific Flight Dynamics (FD coded by third parties). The FM calculates all this stuff (more or less) correctly. The weather model also calculates (more or less) correctly. The problem is that fake data may be fed into the accurate Microsoft code. The FD author must research and encode realistic gust response for the specific aeroplane. Most simply don't bother or maybe they just think they should emulate the code in default Microsoft contractor FD.
Every equation has two sides. Input and output.
For years a series of third party FD authors have done their best to explain to the FS community that various parts of the aircraft specific code retailed by MS are broken. Everything from the scenery projection code in '2D panels' to more obscure things like gust response. Third party developers do not avoid creation of the exact same aircraft as Microsoft released. They know they can do better. One way that they can do better is to improve the output in MSFS. The other side of the equation.
Those who have flown a real C172/182 will know that the real thing does not behave like a leaf tossed around on the breeze in light turbulence, let alone in still air. The real thing is not unstable and undamped in still air. According to Microsoft and their 'expert contractors' Cessnas have little inertia, little stability, and little damping. In MSFS the default Cessnas are hard to move from one energy state to another in still air without bucking and yawing like a bronco. Amusing consumers with bogus 'head bobbing' in relation to tiny G forces that would not cause anyone to lose control of head position has replaced any attempt to release realistic default dynamics (or their physiological consequence).
Errors in the output side of MSFS equations are just as important as errors on the input side. They are less discussed and less understood, yet in some aircraft the output data is most of the problem. When the weather engine creates a realistic gust the specific aeroplane gust response is wildly wrong. Its FD have too little encoded inertia, stability and damping.
I think I can deduce why, but first an analogy which has some scientific inaccuracies, but may aid understanding. Imagine an Army truck is parked on a flat hard surface with the engine off, gear box in neutral, and the hand brake off. A child rides a bicycle into the rear steel fender at modest velocity. A force is briefly applied to the truck. The structure of the truck is not deformed and nor does it move. The truck is massive and has huge inertia. It also has high stability. It does not topple over.
Now imagine the truck is highly instrumented and the data is recorded by a black box. The needle on the relevant gauge (dynamometer =G meter) flicks up to record the impact. The data is recorded in the black box. The truck velocity is zero throughout. The speedometer needle never moves. An accident investigator is called in and he demands the black box data. He needs to know whether the truck was moving or stationary. He needs to know whether something impacted the vehicle. The black box data is used to produce time traces and discloses that the truck never moved, but that a G force was applied. The transient force failed to overcome the inertia of the massive vehicle which never moved. If the investigator knows the mass of the bicycle and its crew he can calculate its velocity at impact. The investigator does not confuse the trace which records the velocity of things that collided with the truck with the velocity they induced in the truck.
Each version of MSFS has introduced a different variety of bucking bronco called a Cessna 182, each said to be 'as real as it gets'. I deduce that somewhere in the mists of history either BAO or Microsoft obtained black box data for the Cessna 182 'gust response' and confused the trace of what happened to the needles on the gauges with the trace of what happened to the whole aeroplane.
When a real Cessna 182 departs into slight turbulence the pitot and static tubes detect rapid pressure fluctuations as gusts pass the pitot tube and static port. The mechanical parts of the gauges they drive have low mass and low inertia. they are usually poorly damped too. The ASI and the VSI may fluctuate rapidly. They are 'recording' air impacting the aeroplane faithfully. The stall warning horn sounds then stops, over and over again, as every gust impacts its reed. The passengers think the Cessna might stall, but the pilot knows that if he maintains the correct attitude = pitch = angle of attack the wing will not stall. He ignores the wildly fluctuation ASI and the VSI and targets the correct pitch. In light turbulence the aeroplane does not bounce around like the needles on those gauges. It is an army truck being impacted by a kid on a bicycle. Its inertia is not overcome. The acceleration induced in the entire high inertia vehicle in the x,y,z axes must be measured with a dynamometer (G meter) which creates a different set of traces to the traces which record the impacts.
Of course as the turbulence gets worse it will manage to 'move' (actually accelerate / decelerate) the entire aeroplane in space, but the needles that are showing how the air is impacting the massive aeroplane will move much faster and will fluctuate much more. The two things must not be confused. I believe that they were confused in the default FD a long time ago. Ever since slow but inadequate adjustments have been made to the default Cessna inertia and stability, but it still lacks realistic inertia and stability. This matters because third party FD authors plagiarise and extrapolate from what MS release, however broken it may be.
There is another FD content problem. CFS versus FS. Fighters are carefully designed to have low inertia and low stability in order to make them responsive. Transport aircraft are designed to have high inertia and high stability with excellent gust response, but they are less responsive. It is not just a question of relative mass and size. The design time intention is different. Third party air file compilers, and the help files of third party air file editors, often make false assumptions about the role of the aeroplane being encoded. A naval destroyer and a cargo boat do not share the same inertia, stability, damping, structural integrity, capsize probability, wave response, or handling even if they are the same length, and have the same mass.
The result is a huge number of FD released with inadequate inertia and stability. Their gust response is like a leaf in a breeze. They accelerate and decelerate too easily in gusts and are also toppled too easily by a realistic gust. A massive aeroplane with high inertia does not accelerate / decelerate in an instant to the velocity of the air impacting it. The VSI measures vertical SPEED increment. *Speed is relative*. In still air it is the aeroplane that is moving up through the air in the z axis. The VSI records aeroplane speed upwards. But when the air is moving downwards as we cruise the gauge cannot tell the difference. It quickly depicts the aeroplane as climbing when it is actually unmoved in sinking air. The gust ends almost as soon as it began and the aeroplane never accelerates to minus 300 VSI in the z axis. It may not sink at all or it may sink a little. It may acquire a z axis acceleration of -10 due to transient impact at -300. Nor is the aeroplane significantly toppled. It is stable. The real aeroplane does not pitch, topple and accelerate like a leaf when subjected to a breeze. Nor does it 'topple' when the pilot makes small control inputs to vary direction in any axis. It has been shaped so that it does not. It is stable as well as inert.
In a real Cessna the gauge needles react quickly because the inertia of the gauge mechanism is very low. They move all over the place recording air impacts correctly, the stall warning horn goes on and off, but if we target the correct pitch the massive aeroplane deviates up and down far less; and is not significantly toppled in the x or y or z axes either. In MSFS bad Flight Dynamics code (not Flight Model code, not Weather Model code), with inadequate inertia and stability encoded allows aeroplanes to be tossed around like leaves and the weather model is blamed.
There is another problem. All systems are damped. The long case clockmaker must control the inertia and stability of the pendulum, but he must also damp it so that the tick and the tock are exactly one second apart. Having been perturbed from rest by a transient force the pendulum returns to its prior status after a *designed* time constant. Remove the 'gusts' generated by the clockwork spring and it will soon be damped to rest. That will also take a very specific, but different, time interval.
Real FD authors design the damping of the aeroplane in all axes and it reverts to its prior equilibrium after the transient force is removed. Damping is the other principle component of responsiveness. 'Fighters' must have low inertia and be very unstable but superbly damped. When the pilot adds or removes an input force the motion must start / stop fast. Propliners are less responsive, but they are designed with adequate damping.
Like a pendulum (they are a pendulum) they revert to their prior equilibrium state without pilot input.....unless the aeroplane has been forced from the right side of the drag curve to the wrong side (is already so far perturbed that it continues to capsize). Well designed aeroplanes will stall at a much lower angle of upset than is required to capsize a well designed boat. This is another reason we always cruise close to zero pitch. We must make it difficult for the next big wave to pitch us up to stall pitch (capsize). If we cruise with substantial pitch we are vulnerable to stall in gusts. If we cruise nose down we are vulnerable to structural failure in gusts. On approach we must deploy flap to sustain low pitch (actually low angle of attack). If we don't have flap, or we fail to use flap to control pitch independently from flight path vector (glideslope), we are much more vulnerable to gusts on approach because we will already have invoked high pitch (actually angle of attack). If we fail to restrain pitch in descent, to restrain IAS in descent, we are vulnerable to structural failure during descents.
Many MSFS FD also have inadequate or excessive damping in relation to the designed role of the aeroplane. Many MSFS FD fail to associate design cruise power with zero pitch at design cruise altitude at design cruise weight. This makes the aeroplane more prone to stall in any gust during cruise. Many more FD fail to associate zero trim drag ('flippers neutral') with the same design condition. This leaves the human pilot and the AP without full elevator authority and without full trim authority, in one direction or the other, during recovery from gusts, (and all of the time).
So we suffer hundreds of excessively gust perturbed aircraft releases, which cruise at excessive pitch, even before they are excessively perturbed. Then most are too slow to recover prior equilibrium and require more rapid and more aggressive pilot intervention with power and stick than in real life. The need for 'realistic' FD does not just relate to realistic cruising velocities, realistic operational ceilings, realistic range versus fuel loaded etc, it also relates to handling and gust response, both of which depend on 'realistic' inertia, stability, damping, CL associated with zero pitch cruise, and trim authority (as well as other things).
Now please note that I am not claiming those values are correct in my FD. There is too little data in the public domain to know. Manufactures keep data for things like stability and damping secret. It has to be estimated and it is very difficult to estimate. For instance I never claim to estimate inertia to better than two significant figures, but most FD authors claim to have estimated it to eight. In many cases the encoded value is very precisely wrong, by more than 100%.
If the role of the aeroplane is transport then it is a good idea to simply encode values that err on the high side for inertia, stability and damping in each axis. The code in many FS releases has been very heavily influenced by code in CFS combat aircraft and is often wrongly extrapolated from 'fighter' values.
So, yes the MSFS weather model sometimes generates gusts of bogus amplitude due to data error, or bogus sudden boundaries between distant oceanic weather stations, but much of the problem is in the FD. And yes, currents can produce gusts (or not), but a wave / gust is not a current and in most cases a wave should only impose modest pitch up, (from near zero), causing modest IAS decay which should self restore. The bogus sudden boundary events should not invoke stall or structural failure from near zero pitch cruising. Even with most human data errors we should have time to avoid stall by addition of power and by pitching down. Save in some non propliner aircraft it should be possible to recover from stall, after stall.
We should never expect an AP to recover from stall and most may have maximum pitch rates that will not recover from the wrong side of the drag curve (IAS < Vbg <> Vx) without manual throttle addition. Using 'accelerated time' with AP ON does not manipulate all the pendulum time constants correctly within MSFS. We have all seen auto pilot induced oscillations (APIO) induced in still air as the AP servo control rates fail to cope with accelerated time and accelerated vehicle motion. When a gust is imposed in accelerated time an AP that would cope at 1x will not cope at 4x or maybe 16x. Nor in all probability would a human pilot. Yet for some reason there is an expectation that accelerated time should not impose additional stall / structural failure risk during gusts. It does and whether we add that extra risk is our choice.
If we use real weather we must accept that there will be data errors. They may cause departure from controlled flight. We can treat that as an emergency or we can just slew a few miles further on (not back!) and resume cruise knowing that what happened was a real world data error or a video game accelerated time error. Some of the human data errors will be so large that they will create gusts which even 'over realistic' inertia, stability and damping will not resist. Remember you cannot just increase those variables on their own after download without screwing up the flight dynamics in other ways at the same time. Lots of variables which do not appear to be involved in this stuff must move in concert with variables mentioned.
You may wish to take a break before reading Part 2 which deals with the outside air temperature (OAT) issues.
Continued in next post...