Jump to content
Fumes

very high angles of attack

Recommended Posts

3 hours ago, BraveSirRobin said:

 

Yes, I think it would have been great if you could have figured it out on your own.  And yet, here we are...

Indeed it would have been great, because then I would not have had my time wasted by you.

Share this post


Link to post
Share on other sites
7 hours ago, jcomm said:

 

Thx, I had missed that one...

 

So TACVIEW takes geometric AoA, not aerodynamic…  I still remember when around 2006 "our" beloved "icidence" and "washout" records were "robbed" from MSFS flight dynamics between fs9 and fsx… They started to take geometic AoA instead. Washout went out too...

 

and… @Fumes, it was good for you to start the thread, but it would also be great to see you happy that it isn't actually - just - an IL-2 limitation...

 

My understanding of the thread post by Frederf is that there are three relevant angles.

 

1) That measured by a real instrument (modeled in DCS but we do not have one in any BoX plane?)  which takes into account the disturbed airflow.

2)  Actual angle of airflow around the airframe.

3)  Actual angle of motion relative to the airframe. This is what Tacview measures.

 

The point is that angle 1 will always be higher than angle 2 or 3, which will be very close together. So if Tacview is showing 30 degrees, this is underestimating what the DCS cockpit measures.  That is what the DCS thread was about: not saying that Tacview overestimates AoA. So this discrepancy cannot be anything to do with the OP's question which was why AoA well above stall angle appears sustainable in BoX.

 

Additionally, wing incidence is usually in the order of 3 degrees IIRC. So if Tacview is showing (3) as 30 degrees, the AoA of the wing would be ~33. 

 

So this linked thread does not seem to address the OP's question at all, except in the most general terms that you have to be very specific about what is being measured .

  • Thanks 1

Share this post


Link to post
Share on other sites

You're right, and ( I always come up with this one... if you can't beat them, confuse them... ) my age and the time of day I read the thread helped adding to the confusion ... 🙂

 

Before going to bed, while saying my prayers, it did come to my mind it wouldn't make much difference, even if in your last calculation regarding (3) in your post you add the washout, whose value I really don't know if it's that important on most BoX models ( ? ).

 

So indeed, @BraveSirRobin while he contributed with yet more food for our thoughts, isn't really targeting the true kernel of the problem, which can well lay in the Tacview software and how it aquires it's data from the sim or in IL-2's FDM....  I'd love it's on TacView's side ...

 

 

If it's on IL-2's side, I'd say it's a very rough kind of innacuracy, and should be really looked after by the Dev Team 😕

 

And, just out of curiosity, where does TACVIEW get this data out from IL2 ? Is there some way we can read it too ? Any "log" files or runtime command line options ( verbose mode 🙂 ) ?

Edited by jcomm
  • Upvote 1

Share this post


Link to post
Share on other sites
9 hours ago, unreasonable said:

 

My understanding of the thread post by Frederf is that there are three relevant angles.

 

1) That measured by a real instrument (modeled in DCS but we do not have one in any BoX plane?)  which takes into account the disturbed airflow.

2)  Actual angle of airflow around the airframe.

3)  Actual angle of motion relative to the airframe. This is what Tacview measures.

 

The point is that angle 1 will always be higher than angle 2 or 3, which will be very close together. So if Tacview is showing 30 degrees, this is underestimating what the DCS cockpit measures.  That is what the DCS thread was about: not saying that Tacview overestimates AoA. So this discrepancy cannot be anything to do with the OP's question which was why AoA well above stall angle appears sustainable in BoX.

 

Additionally, wing incidence is usually in the order of 3 degrees IIRC. So if Tacview is showing (3) as 30 degrees, the AoA of the wing would be ~33. 

 

So this linked thread does not seem to address the OP's question at all, except in the most general terms that you have to be very specific about what is being measured .

So if I understand right, this could still be in il2s court and not tacview?

Share this post


Link to post
Share on other sites
1 hour ago, Fumes said:

So if I understand right, this could still be in il2s court and not tacview?

 

Perhaps, but without an AoA indicator in the game itself we cannot be 100% sure, also we do not know exactly how far above stall AoA these planes could fly: some would depart controlled flight very sharply, others lose lift rather slowly. As usual, it seems to be complicated, but perhaps our resident engineers have a clearer view.

 

 

Share this post


Link to post
Share on other sites

I wasn't going to comment further in this thread, but out of consideration for people who might otherwise be misled, I can categorically state that the AoA figures given for IL-2 GB by the current version of Tacview are unreliable. It is a simple exercise to demonstrate this: set up a quick mission with a fighter, and with 10 M/s wind. Then record a tight 360 degree turn at about 1000m altitude (the wind at that height will be about 25 m/s or 90 km/h). Then look at the Tacview data. the 'AoA' will be nowhere near constant, and can easily vary between +35 to -5 degrees as the aircraft heading changes relative to the wind (I did this test with a U-2VS, and got even more extreme results: +65.9 to -18.9 degrees). The explanation is simple.  As Vyrtuoz, the developer of Tacview has made clear (both on this forum and on the Tacview one http://dogsofwarvu.com/forum/index.php/board,57.0.html) IL-2 GB only provides limited data to Tacview, and accordingly will not always give correct results. In particular, Tacview currently has no way of detecting wind, and accordingly can only  arrive at an 'AoA' figure in relation to motion over the ground. Which is clearly going to be wrong if there is any wind. I suspect from looking at other Tacview data that there may be reasons to question Tacview's AoA figures even without wind, though this is difficult to verify conclusively. Given the limited data Tacview is supplied with, I'm not even entirely sure how Tacview arrives at an 'AoA' figure at all.

 

Tacview is an interesting and useful application, but as Vyrtuoz has stated, it is limited by the data it receives. If people are to use its data as a basis for questioning IL-2 GB FMs, they need to understand this, and not jump to conclusions based on their own prior assumptions.

  • Thanks 3

Share this post


Link to post
Share on other sites

In my opinion, TacView calculates angle of attack from the known attitude of the aircraft and the known flight path over ground. Depending how 'current' is defined, say attitude right now and flight path calculated from the two last know coordinates over the last 10th of a second, errors are to be expected. However, from my limited testing (which I always do with wind off), it appeared quite reasonable.

 

Thanks for the info on the wind, never occurred to me because I never have wind on when I'm interested in what TacView has to say...

Share this post


Link to post
Share on other sites

As I said, there may be other reasons to question the Tacview AoA figures. Testing the Bf 109 F-4, I have Tacview data showing an 'AoA' of up to 30 degrees in a tight turn, even without wind. In level flight, the stall angle is around the 20 degrees or so quoted in the IL-2 GB description. Errors of a few degrees could be accounted for by the sampling errors, as you suggest, but something has to be seriously wrong somewhere for an error of this magnitude. And if the IL-2 GB FM actually permits the 109 to turn at a 30 degree AoA, we would need better evidence than the limited data provided by Tacview to prove it. Vyrtuoz has already acknowledged its limitations, and I very much doubt he'd want it being cited as evidence for a faulty FM. 

Edited by AndyJWest
  • Upvote 1

Share this post


Link to post
Share on other sites

Further to my above comment, if you look at the raw data that Tacview used for a IL-2 GB recording - the acmi file - you will see that it has no data for aircraft heading or yaw. It has pitch and roll angle data, but no means to determine the aircraft heading other than by interpolation from aircraft motion.  And if you are doing that, I can't see how you can use the same data to arrive at an 'AoA'. Maybe Vyrtuoz could shed some light on how he arrives at the figure, if someone wishes to ask on his forum, but otherwise I'm going to stick with the assumption that the AoA data isn't reliable.

 

EDIT: Please ignore above. Hadn't looked closely enough at the acmi file format. The heading data is there, just not always sampled.

Edited by AndyJWest

Share this post


Link to post
Share on other sites

Some further comments, just for closure. Having done some more experimenting, it is clear that even in level flight, the 'AoA' figure given in Tacview graphs doesn't necessarily correspond to the difference between the pitch angle reported by IL-2 GB and the direction of motion. This can be easily demonstrated by recording an aircraft being flown by the 'level autopilot' at different speeds. Set up a quick mission, (with no wind) with a fighter at 1500 m. Go full throttle, and dive to about 500 m or so, then engage level autopilot, and throttle right back. At high speeds, Tacview shows the AoA to be almost identical to the pitch angle, but as speed decays, they begin to diverge. With a Bf-109 F4, the autopilot disengages at about 180 km/h, with the Tacview graph showing an 'AoA' of about 34°, and a pitch angle of about 13°. Oddly though, if you display the Tacview 'AoA' in the label attached to the in-map aircraft at this point, it gives a figure of 14.4°, meaning that Tacview isn't even self-consistent. 

 

Viewing the IL-2 GB track of the  test will make it clear that the 34° 'AoA' reported by Tacview graphs at the slowest point is clearly wrong, or at least, not reporting what people think it is supposed to indicate. The aircraft is clearly not 34° nose up, or anywhere close. It is, as far as I can tell by measuring a screenshot (not very accurate, obviously), close to the pitch angle reported. Furthermore, any discrepancy can't be down to a correction for a possible difference between aircraft datum (used for pitch measurements) and wing incidence, since that difference would remain constant, rather than increasing as speed decays.  There is a slight error due to the fact that the level autopilot doesn't actually maintain altitude properly over the last few seconds, which may account for the difference between the 14.4° displayed in the map label and the 13° pitch angle, but the total loss of altitude is only about 10m, and the AoA/pitch discrepancy is evident long before any appreciable loss of height. 

 

As I said earlier, Vyrtuoz is working with limited data, and as far as IL-2 GB is concerned, Tacview needs to be seen as a work in progress. 

 

Edit: Struck out, see next post.

 

Edited by AndyJWest
  • Upvote 1

Share this post


Link to post
Share on other sites

Correction to the above, I was misreading the Tacview chart, which used two different scales for Pitch and AoA data.  The Tacview AoA does seem to more or less correspond to pitch angle in level flight, under the conditions I tested. I need to investigate further though, as there still seem to be unexplained discrepancies when turning. I should probably try and get a decent night's sleep before doing so though, as insomnia clearly doesn't help with my thinking...

Edited by AndyJWest

Share this post


Link to post
Share on other sites

After a couple of red herrings and a decent night's sleep, I think I've now figured out at least one more reason why Tacview can report excessive AoA angles. As JtD suggested earlier, Tacview interpolates flight path from positional coordinates (it doesn't have anything else to go on). But rather then using the last two, as JtD suggested, it is using more (possibly to smooth out the data), and accordingly the estimated direction of flight lags quite a bit behind the aircraft orientation data, which doesn't require interpolation and is immediate. Inspecting the data raw data and how Tacview interprets it suggests to me that the lag is somewhere around half a second. Which doesn't sound much, until you consider that a fighter aircraft pulling hard may easily achieve a turn rate of 20 degrees a second or more. A half-second directional data lag alone could thus result in a ten degree overestimate of AoA at that turn rate.

 

As evidence for this, take a look at these Tacview graphs, from a recording of a Bf-109 F4 pulling up steeply into a climb (and subsequent loop) from a dive. In the first graph the upper (red) line indicates altitude above sea level, and the lower (blue) shows vertical speed. The second shows AoA (blue) and pitch angle (red). There are two things to note here. Firstly, the altitude and vertical speed values cannot possibly both be correct at some points. The aircraft is shown as reaching its lowest point about half a second before the vertical speed is shown as zero. Secondly, at the point where the aircraft is at its lowest (11:00:30 on the time scale) the AoA (blue, read from the left scale) is shown as about 17°, while the pitch angle (red, read on the right scale) is shown as around 7°. 

 

VS-ASL.png

 

Ao-A-Pitch.png

 

 

Inspection of the raw data confirms this. Take a look at this short excerpt:

--------------------------------------------------------------------------------------------------------------

#12
173ff,T=5.1856489|4.8872364|1158.88|0.3|-10.4|,AGL=1158.88
#12.2
173ff,T=5.1853949|4.8874448|1151.36|0.5|-7.6|321.3,AGL=1151.36
#12.4
173ff,T=5.1851388|4.8876553|1145.03|0.6|-4.2|321.4,AGL=1145.03
#12.6
173ff,T=5.1848813|4.8878677|1140.09|0.8|-0.3|321.6,AGL=1140.09
#12.8
173ff,T=5.184623|4.8880813|1136.79|1.1|4.1|321.8,AGL=1136.79
#13
173ff,T=5.1843655|4.8882955|1135.35|1.4|8.5|322,AGL=1135.35
#13.2
173ff,T=5.18411|4.888509|1135.92|1.8|12.7|322.2,AGL=1135.92
#13.4
173ff,T=5.1838582|4.8887207|1138.53|2|16.8|322.5,AGL=1138.53
#13.6
173ff,T=5.1836115|4.8889296|1143.16|0.9|20.8|322.7,AGL=1143.16
#13.8
173ff,T=5.1833709|4.8891342|1149.75|-0.9|24.7|322.6,AGL=1149.74
#14
173ff,T=5.183137|4.8893332|1158.19|-2.2|28.9|322.2,AGL=1158.19

--------------------------------------------------------------------------------------------------------------

The aircraft is at its lowest (1135.35m ASL) at data point #13. At that point, the pitch angle is shown as +8.5°. The pitch angle rate of change (i.e. the rate of turn, since we are turning vertically) is about 20 degrees a second, and the data points are 0.2 seconds apart, meaning that the pitch at the actual lowest point may potentially be off by a couple of degrees from the 8.5 degrees shown, but this cannot account for the supposed 17° AoA that Tacview indicates. The AoA value shown (on the graph, and on the aircraft label at the same time) simply cannot be correct, based on the raw data. It overestimates by about 10 degrees in the example I give, due to the lag in directional data interpolation.

 

If anyone wants to confirm this, I can provide the track recording, though it might be better to repeat the test and verify it with independent data. It would be nice to check the values for horizontal turns too, but I've not yet figured out a way to do this accurately, since one needs then to account for the bank angle when calculating the true angle of attack. Working with data from turns in the vertical axis reduces the problem from three dimensions to two.
 

Edited by AndyJWest
  • Like 1
  • Thanks 2

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...