Su27 Wing Thing

[jackmckay]

@Tharos

 

1) true because plane was trimmed down

2) G's rising up fast and continued even stick was released (!) ..I didn't check FCS switch status under throttle (?)

 

and did you add 1G to actual limit because

 

[SinusoidDelta]

The airframe load factor [Nz] is with respect to the airframe.It doesn't change when inverted. It isn't the same as acceleration due to gravity [G]. [Nz] is the ratio of lift/weight, which in the academic sense makes it unitless. It's commonly expressed as [G] because it is the acceleration 'felt' by the aircraft or someone in the aircraft.

[GGTharos]

@Tharos

 

1) true because plane was trimmed down

2) G's rising up fast and continued even stick was released (!) ..I didn't check FCS switch status under throttle (?)

 

 

#2 was the only strange thing I noticed, but it could potentially (not sure how likely at all) be chalked up to some form of inertia ... a lot of inertia.

 

 

and did you add 1G to actual limit because

 

Nice try, meme fail :P

 

Because what SD said.

[Bushmanni]

In MP you occasionally have some 0.5-3 second freezes that the simulation engine extrapolates over and somehow it reads the stick inputs during the freeze. So you can unintentionally pull the stick past the G limit while the game is frozen and when the freeze is over you suddenly have a wingless plane.

[Pocket Sized]

The G continued to increase because yes, lots of inertia.

 

But also because the stabilators deflected down which, for a fraction of a second, actually INCREASED the planes coefficient of lift.

 

Sometimes you can see this if you watch the G meter carefully. Move the stick back and the needle will twitch downwards a bit, then swing upwards.

[kobeshow]

Lag spikes don't cause g-spikes to the ownship. There's nothing in the MP code that will cause your aircraft to experience forces, other than another aircraft warping into it.

 

The ONLY time something is affected like this by a lag-spike is multi-crew, which is N/A to Su-27.

 

of course the lag itsself does not cause this, that is why I said the lag spike needs to come at the right time (see Bushmanni's comment above).

[jackmckay]

The airframe load factor [Nz] is with respect to the airframe.It doesn't change when inverted. It isn't the same as acceleration due to gravity [G]. [Nz] is the ratio of lift/weight, which in the academic sense makes it unitless. It's commonly expressed as [G] because it is the acceleration 'felt' by the aircraft or someone in the aircraft.

 

[Nz] ... Weight in formula is product of acceleration (m*a) so there wouldn't be the same G readout if I pulled UP flying leveled or DOWN flying inverted (just because feed pumps will stop working and pilot can withstand more positive Gs than negative) relative to gravity vector(Z) prior entering maneuver and proceeding at constant corner velocity/AoA/turn rate, so this 1G (or g as acceleration) actually decreases weight. ..Lift is product of wingfoil shape (L/D design ratio), wing area, flow velocity(IAS) and air density/viscosity or in short Reynolds number product.. That's just physics..

 

but I'm more concerned about fact that I cannot recreate same condition and have same effect of broken wings.. so we all can learn something from this case. Now it looks like an anomaly in game.

[GGTharos]

You would get the same readout in your cockpit regardless, you would experience the same acceleration and force.

 

Your aircraft is the frame of reference.

[SinusoidDelta]

[Nz] ... Weight in formula is product of acceleration (m*a) so there wouldn't be the same G readout if I pulled UP flying leveled or DOWN flying inverted (just because feed pumps will stop working and pilot can withstand more positive Gs than negative) relative to gravity vector(Z) prior entering maneuver and proceeding at constant corner velocity/AoA/turn rate, so this 1G (or g as acceleration) actually decreases weight. ..Lift is product of wingfoil shape (L/D design ratio), wing area, flow velocity(IAS) and air density/viscosity or in short Reynolds number product.. That's just physics..

 

but I'm more concerned about fact that I cannot recreate same condition and have same effect of the wings.. so we all can learn something from this case. Now it looks like an anomaly in game.

 

Think of the load factor as the apparent weight. That is to say, the force exerted by whatever the body is resting on. When flying the force is being exerted on the 'wet' surfaces of the aircraft immersed in a fluid (air). Some of the other theories and terms you mentioned are only indirectly related.

Load factor is a broadly used concept/tool in, for example, structural and electrical engineering.

 

Nz=L/W

 

Nz= Lift Force [N] / Weight [N]

 

Weight is always *1 [G] and as you can see, the units cancel through division.

 

Sorry if I'm pulling the thread a bit off topic :D

Edited October 4, 2016 by SinusoidDelta

[jackmckay]

All objects with mass inside of gravity force are under the influence of the gravity force vector..

 

Edited October 4, 2016 by jackmckay

[SinusoidDelta]

It's a shame tacview doesn't accurately export the flight telemetry. I still don't know enough about lua scripting to create any kind of export. It'd be a really useful tool to have.

 

FWIW I was able to re-save the track you posted in ME with external views enabled. See the video of it below. The replay was running at 1/2 speed. It doesn't seem to reveal much other than Betty sounds downright hilarious in slow motion. Both wings rip off simultaneously at exactly 8.5G, bank angle is nearly perfectly inverted at 179deg. The jet is definitely armed to the teeth with missiles though.

 

Because the Su-27 FCS simulates the feel of a traditional statically stable aircraft, it's up to the pilot to monitor Nz. The max pitch rate inverted will always be higher than with the velocity vector above the horizon. So it's critical to apply some G limiting forward stick, especially if the G keeps rising with neutral controls.

 

 

Edit:

 

I watched it a few more times and there is definitely rolling G when aft stick is applied. It doesn't really look like coordinated flight with the nose slipping around, not sure if that's actually the case though.

 

All objects with mass inside of gravity force are under the influence of the gravity force vector..

 

Gravity.jpg

 

I don't want to beat a dead horse here, whatever you're trying to say about load factor and gravity is just wrong. I don't know what else to tell you.

https://en.wikipedia.org/wiki/Load_factor_(aeronautics)

https://en.wikipedia.org/wiki/Apparent_weight

Edited October 4, 2016 by SinusoidDelta

[jackmckay]

@Sinusoid

 

Thank you for cutting out the actual scene from external view.

 

Now:

 

1) Look at the elevator deflection angle progress(!)

2) consider that plane is in turn radius with center-point down towards earth

.. so G-force would be G=1-(velocity^2/circle radius*g).. velocity is TAS and circle radius could be found roughly with elevator deflection angle (versus center of mass) - which (elevator angle) changes a little(25-50% or 1/4 of stick aft pull) but Gs are constantly rising(!).

Edited October 4, 2016 by jackmckay

[lunaticfringe]

No, it's not.

 

God's G is 1G. The most God's G ever effects your aircraft is 1G. Doesn't matter how much you pull, how little you pull, where your nose is pointed, where your center of gravity is- it is *always* 1G.

 

What destroys your aircraft is radial acceleration- how much you put on the stick.

 

When you turn with gravity, the radial rate of your turn is increased by up to 1G. But purely the *rate of turn*. The actual load on the aircraft is the G you invoke with the stick.

 

Ergo, if you are inverted- with your lift vector pointed straight down, and you pull a 5G 90 degree turn to nose straight down, your nose will rate as though accelerated by 6G as it is assisted by gravity, but the actual load on the airframe remains 5G.

 

Conversely, in a 5G 90 degree pull up from level flight, your nose will rate as though accelerated by 4G as it is degraded by gravity, but the actual load on the airframe remains 5G.

 

Every manual on air combat for the last 70 years has shown the energy egg. If you don't believe the laws of physics, there is nothing else anyone can tell you that will make a difference.

[Frostie]

The question i'm interested in is just how hard would it be for a real pilot to pull so hard against the FBW and G to break his wings. I'm guessing pretty damn ridiculously hard, something ED can't simulate, which is where this wing breaking simulation nonsense fails. It's like making a plate spinning simulator where you can't see the plate, only the stick, what a crap shoot that would be.

[apocom]

The question i'm interested in is just how hard would it be for a real pilot to pull so hard against the FBW and G to break his wings. I'm guessing pretty damn ridiculously hard, something ED can't simulate, which is where this wing breaking simulation nonsense fails. It's like making a plate spinning simulator where you can't see the plate, only the stick, what a crap shoot that would be.

 

This is basicly the only complaint I have about that implementation. A small pull on my stick destroys the aircraft and if I don't watch my G meter than I have zero indication. Nobody would construct such an aircraft where you have to watch a gauge infight so your plane doesn't self-destruct.

[Bushmanni]

It's a shame tacview doesn't accurately export the flight telemetry. I still don't know enough about lua scripting to create any kind of export. It'd be a really useful tool to have.

 

You can't get much better export data out of the sim than what Tacview already gives you. The basic problem lies in the time code that you get from the sim that isn't accurate but jitters around the real value by some 0.1 seconds. So while you can get accurate data on the plane position and speed vector, you can't accurately measure the time between samples and hence you can't get accurate rate of change for anything that must be calculated by comparing datapoints measured in different times. I don't know if it's a bug or just intentional measure taken to prevent reverse engineering but it does prevent you from getting absolutely accurate information from the sim.

 

I bet it's pretty easy to tell difference between 5 and 6 G pull in a real aircraft just by feel, although I don't have any experience to back up this claim. What we would need is some artificial way to let the virtual pilot to know how much G he's feeling. FPS games have icons on the screen to tell if you are crouching or standing, exhausted or not, etc. to let you know this kind of things. Why not have something like this in DCS also. Or make the cues a bit more discrete like making the G breath change a bit but noticeably as the G load increases so you can hear the difference. Or put in an effect similar to G-LOC that darkens the edges of the screen in accordance with G-load but only the edges. The G-LOC simulation would still be applied on top of this G load indication. Or maybe you could have both aural and visual cues.

[Pocket Sized]

Nobody would construct such an aircraft where you have to watch a gauge infight so your plane doesn't self-destruct.

 

They didn't. IRL if you go from 0 to 8 G immediately you're out cold. End of story.

 

The Sim has a stick pusher implemented, just look at the virtual stick during high AoA/G maneuvers. If you yank the stick back immediately the stick pusher doesn't have time to react and you Over G. If you apply G SLOWLY as you would have to in real life, the plane will keep its wings on just fine.

[lunaticfringe]

The question i'm interested in is just how hard would it be for a real pilot to pull so hard against the FBW and G to break his wings. I'm guessing pretty damn ridiculously hard

 

Not so, because not all FBW systems are created equal. They can be constructed with AoA limitation, G limitation, stability augmentation in one, two, or three channels, all of these aspects, or one of these aspects.

 

With the publicly released documentation that I can find, the Su-27's FBW exists to provide stability augmentation in the pitch and roll channels, and under certain circumstances, an AoA limiter. As you know, AoA isn't G. And the system isn't noted from sources (Gordon, manual translations, further Soviet/Russian translated materials) to involve an inhibitor for raw G load.

 

Subsequently, as far as what the material I can find shows, the Su-27's FBW functions in similar to that of the F-15 CAS or the F-14's DFCS- essentially trim functionality in two channels, with the addition of a soft limit that can be turned off by the pilot. Such as it is, one would need more information on hand to determine if it involves any sort of speed, G, or load biasing to aid in pitch onset reduction when heavy. Given that there's a chart running around showing the pilot the airframe prohibition limits when substantially laden, I'm of the mind it's not actually built to limit.

 

Nobody would construct such an aircraft where you have to watch a gauge infight so your plane doesn't self-destruct.

 

Engineers have been creating aircraft able to be catastrophically destroyed through pilot input since the Wright Brothers. FBW is only a salve, not an ultimate solution- especially if performance is intended to be left available to the pilot.

[SinusoidDelta]

You can't get much better export data out of the sim than what Tacview already gives you. The basic problem lies in the time code that you get from the sim that isn't accurate but jitters around the real value by some 0.1 seconds. So while you can get accurate data on the plane position and speed vector, you can't accurately measure the time between samples and hence you can't get accurate rate of change for anything that must be calculated by comparing datapoints measured in different times. I don't know if it's a bug or just intentional measure taken to prevent reverse engineering but it does prevent you from getting absolutely accurate information from the sim.

 

The tacview telemetry for this .trk reports [G] as being less than half of whats indicated in game. Tacview's telemetry sample rate is .25 seconds, it could be missing the peak values, but I've seen the same inaccuracies in other Su-27 .acmi's.

 

Do you mean the time code when using LoGet() functions jitters around? As long as you know the time at which the point was taken I don't see why you couldn't compare data. Even without time codes a curve could be estimated by linear approximation. The problem for me is I don't understand how to write such script :( I can process and analyze exported data but I suppose thats the easy part.

 

There hasn't been much discussion recently on the russian side of the forum. When the eagle and flanker PFM's were released there were some very good threads analyzing their performance through exported flight data. Until a few moths ago, exporting the F-15 data was accessible through mods/aircraft/FC3/F15/FM/config.lug, changing line 98 to record_enable=true, and simply pressing rshift+C in game to start logging telemetry to a .csv. (See the image below for an example I plotted for the F-15)

 

For whatever reason, that export method is no longer working for the eagle. The flanker FM was created by another developer and never have that export method so I'm curious how you would go about exporting it.

[DarkFire]

Engineers have been creating aircraft able to be catastrophically destroyed through pilot input since the Wright Brothers. FBW is only a salve, not an ultimate solution- especially if performance is intended to be left available to the pilot.

 

This is particularly relevant to 4th generation Russian fighter design: the early Su-27 and MiG-29 families of aircraft were never designed to have care free handling in the same way that contemporary western aircraft like the teen series fighters were. The design philosophy behind the Russian control systems is that responsibility for not doing something that leads to the destruction of the aircraft is entirely the responsibility of the pilot.

 

The early Russian FBW will not hold your hand in any way, and doing fatal things is absolutely possible. The idea is that with sufficient training, practice and ability, having more freedom to explore the more unusual areas of the flight envelope can lead to greater performance that wouldn't be allowed by a 'carefree handling' FBW system.

[lunaticfringe]

This is particularly relevant to 4th generation Russian fighter design: the early Su-27 and MiG-29 families of aircraft were never designed to have care free handling in the same way that contemporary western aircraft like the teen series fighters were.

 

The first two teen series aircraft have no actual restrictions; the F-14, even with DFCS, has no limitations (with one particular victor employing 10.2G to avoid target debris without popping even a rivet), and the F-15's CAS/OWS combination amount to polite suggestions. Out of the box the F/A-18 has less AoA restrictions than the Su-27. And the Viper, way back when, was originally operation with full air to ground loadouts in what would now be considered CAT I, because the FLCS category system didn't exist at that point- without structural issue. But if you can't have 9.0G available all the time and figure out how to use the laws of physics to beat an opponent, you need to go back to school.

[Bushmanni]

Do you mean the time code when using LoGet() functions jitters around? As long as you know the time at which the point was taken I don't see why you couldn't compare data. Even without time codes a curve could be estimated by linear approximation. The problem for me is I don't understand how to write such script :( I can process and analyze exported data but I suppose thats the easy part.

 

The problem is that you can't get exact time out of DCS scripting engine (and it seems export scripts suffer the same problem although I don't have personal experience about that). If you fly in a steady level flight and export position data with steady sample rate and then analyze it, you will see that the distance between each position varies slightly and hence speed that you calculate using position data. If you measure the time at each data point and use that to correlate the positions to get correct speed, you can reduce the error but you still can't get rid of it completely. This problem exists with all the calculated variables that rely on knowing the time between datapoints. The longer the interval, the less effect the time error has so you can average the error out with long enough measuring interval.

 

Here's an example mission using mission scripting to export data.

https://forums.eagle.ru/showpost.php?p=2692721&postcount=15

[DarkFire]

The first two teen series aircraft have no actual restrictions; the F-14, even with DFCS, has no limitations (with one particular victor employing 10.2G to avoid target debris without popping even a rivet), and the F-15's CAS/OWS combination amount to polite suggestions. Out of the box the F/A-18 has less AoA restrictions than the Su-27. And the Viper, way back when, was originally operation with full air to ground loadouts in what would now be considered CAT I, because the FLCS category system didn't exist at that point- without structural issue. But if you can't have 9.0G available all the time and figure out how to use the laws of physics to beat an opponent, you need to go back to school.

 

Agreed, the point being though that most new Su-27 pilots expect to be able to bank & yank to their hearts content, and are then awfully surprised when their wings fall off. No criticism of teen series fighters intended. :)

[Frostie]

Agreed, the point being though that most new Su-27 pilots expect to be able to bank & yank to their hearts content, and are then awfully surprised when their wings fall off. No criticism of teen series fighters intended. :)

This is all well and good and obviously pretty much in tune with having basic understanding of the platforms limits.

But a real pilot knows how much G he is experiencing and will be able to associate the G-meter reading with his initial pull and translate that physically when not reading the meter in a merge or defensive position for example. This level of interpretation just doesn't exist in the sim meaning what is a perfectly safe stick application becomes disastrous after the apex of a loop or applying roll after a circle etc. The notion that you have to constantly watch your G-meter as the only way of understanding your aircrafts load is counterproductive to combat efficiency.

Edited October 6, 2016 by Frostie

[lunaticfringe]

The notion that you have to constantly watch your G-meter as the only way of understanding your aircrafts load is counterproductive to combat efficiency.

 

Running around overladen for transonic/supersonic turn performance is counterproductive to combat efficiency.

 

Being overspeed for safe combat G limits based on one's given weight is counterproductive to combat efficiency.

 

Every simulated aircraft here deals with the translation error stemming from stick feel versus reproduction of aircraft performance. Some have systemic aids based around actual systems found in their real-life counterparts. Others do not have such aids, and require their pilots to monitor conditions to a higher level.

 

I mean, are we to say that a Russian pilot sitting in a Su-27 simulator at Maryy needs something extra that's not there in the actual jet not to overstress or destroy his virtual aircraft when he's flying around heavy, or does he work through the problem by developing good habits that will actually translate over?