pbishop

@BIGNEWY Sorry I don't have a track. However, I can repeat it when I get some time in the next couple of weeks and post it.

Found this when I was playing around with the output through export.lua With the AI co-pilot holding level flight (AP on): arg(133) [slip indicator] value = average .0051 arg(142) [roll] value = -.0002 Doing some manual testing (AP on/off), .0051 for the gauge on the slip indicator value causes a lot of heading/track drift over 10 nm. With AP on, the co-pilot just holds a positive slip, there is drift in the value over long periods of time, but it is not what you would expect if you were modeling a human pilot. This seems to be a bug, it just doesn't reference 0 slip or ever get close enough to maintain track/ trim flight (min value observed: .0047)

Just to clarify, I did not post this to draw any conclusions as to the source of the problem. I am sure the devs have certain limitations as to how the aircraft is coded and did their best to get it as close as they could. In my opinion, there is a lot more they got right then wrong. Helicopters are inherently complicated and taking the rotor dynamics, aerodynamic effect, etc... into account is near impossible to model without the proper data and tools. Only they know what the issue might be or even if it is technically possible to get the sim to match closer with the data/mathematical models they have. There is a strong possibility that by starting to play with the controls they open a can of worms they wont get out of any time soon. I provided this just to show that there is a difference so people don't have to speculate about it and can at least accept it for what it is. Now, if this issue is caused by this or that, or if it needs more attention, not my call. I still enjoy the huey for what it is, a sim, and a good one.

So this conversation got me curious so I did some work..... I'll go through the process very briefly because I think the details are probably going to take a while to explain. The following data was exported from DCS using the export.lua into a log file: arg Value IAS 117 Rudder 184 Longitudinal Stick 186 Lateral Stick 187 Collective 200 The searchlight (arg value 410 on/off) was used to mark data when stable on a test point to find the data afterwards. Stable on point was trimmed at the desired airspeed in level flight for at least 1 min. After the minute in stable flight, the marker was turned on between 5 and 10 seconds long. The average position over the data with marker on was used to plot control position. The position values were converted from full range (+max/-min) to a percentage of the full travel. The flight test data from the UH-1H report was then also converted to percentage to allow it to be plotted on the same graph. Some notes: The following table provides the setup between the two tests. A difference between the two is there is no calibrated airspeed in DCS (not sure how you could correct for a simulated installation anyways) so indicated airspeed was used assuming no installation error. A different CG chart then the one posted before is used (see end of post), as theoretically it may be closer to the CG we can simulate in DCS, slightly more forward. No idea if long/lat CG data can be extracted, so it is N/A. UH-1H Flight Test Data UH-1H DCS Data Gross Weight (lb) 8740 8840 CG Long (in) 132.4 N/A CG Lat (in) 0 N/A OAT (C) 24 24 Density Alt (ft) 5220 5100 Now for the interesting bit:

How you interpret the discrepancy is up to you, but I have given you the answer twice..... Take care, and cheers!

Not sure what you mean then. There is no this or that if you could careless about the ground below you (which you mention in your question). Control position in mach 2 wind or 10 kts wind will be the same if you are travelling in trim flight with an indicated airspeed of lets say 80 kts (regardless of the direction of the wind).

It does not. The only way wind affects coordinated flight is if the air is unstable.

Lets use some flight test data to find the answer...... Let the data do the talking. Source:

I assume we are not talking about the actual/real Huey II with upgraded engine and avionics, but just an overhaul of the model. I would pay for an actual Huey II. https://www.helideal.fr/uk/bell-huey-ii.html

Just clarification on tail rotor design (for those who care) 1. Fwd blade is travelling with rotor downwash in first generation. (Decreased efficiency - Think reduced relative airspeed) 2. Fwd blade is travelling against rotor downwash in second generation. (Increased efficiency - Think increased relative airspeed) Hopefully makes sense. If not, stick your hand out the window of your car while it's moving and swing it with the direction of relative airflow, then try it the other way. Not sure about Mi-8 designer philosophy, but I know if I wanted a simple solution without having to redesign the gearbox.... turn it around and it spins the other way. Cheap and easy. Although a very simplified explanation given above, I thought I could add some additional in depth reading for anyone interested in the study conducted by Lt Col Ellin - Royal Navy, Defense Research Agency which is quoted in many helicopter dynamics textbooks. He describes the testing they conducted of Lynx tail rotor designs (in both the above configurations) and is written in such a way for a person to read without having to understand a complex series of equations. http://theses.gla.ac.uk/75364/1/13815547.pdf

I guess it all depends on what perspective we look at it from, and I apologize if my explanation is long. I also hope that you know I mean no disrespect in anything I say or have said. The first experimental 407 was built from a 206L4 which had few similarities to a OH-58 in airframe, power plant, external lines, and avionics at the time of its creation. The 206A/OH-58A started similar enough, and the 206B/OH-58B were also fairly similar enough to be considered the same at the core. However, the 206 progressed beyond this, into the 206B2/B3, then the 206L/L+/L2. By the time the rotor was to be redesigned, the 206L2 only resembled the original 206A/OH-58 in its looks (you could tell it started as the same aircraft). It had a new transmission, powerplant, avionics, extended fuselage, and many structural changes behind the nose back to the tail. The OH-58 got the new rotor in the early 80's, but before the 206 would ever see the upgrade, it would continue to develop and grow into the 206L3, the 206L4, and the 206LT twin. After the 206L4, the next logical growth path was to replace the rotor with a 4 blade design (~1995), more than 10 years after the OH-58. After 3 different iterations/models of the 206, 12 years, and the end of the OH-58 contract, they simply put the rotor on the 206L4. The similarity from their heritage made it easy enough and logical enough from a financial aspect that it simply made sense. I have to add that this happened after the development of the 412 from the 212, and the upgrade of the 2 blade bell 230 to the 4 blade 430 (1992). So I think it would be easier to say Bell was already moving all their rotors to 4 blades, and it makes more sense the 206 was next on the list to grow from this experience. In addition, all helicopter companies suffer from the costs of developing a rotor. The high development cost and time to produce it are what make it so difficult. So when a company has the developed technology, they will usually use it where they can. Bell is probably one the most significant examples of this. Here are a few examples of rotor derivatives/uses that just made sense, but the model did not grow from where the rotor design came from in all theses cases: Bell 505 has a 206 rotor installed. Bell 360 will use a derivative of the 525 rotor design Bell 407 uses the OH-58D rotor. Bell 429 uses a derivative of the 427 rotor design. So, I guess it depends on what you define as the seed something grows from. The first 407 that was once a 206L, and Bell made a decision that made financial sense at the time. I am still not convinced Bell had ever intended to make the 407, but instead create a new model from scratch to replace the 206. Probably a result of financial constraints, but that is only speculation though. What is not speculation is if they could grow the two front seats into something comfortable......., and that applies to OH-58, 206, and 407. Something odd though is your reference to the Bell 406. Knowing what that number means, I don't think its used in the right context here. The model number you refer to is not what you will find on the type certificate. The type certificate will say OH-58D, because that is the model. In the context of the internal bell number 406, the 407 internal number is not 407. Anyways, I am fairly tired so I hope some of this makes sense when reading it.

Not exactly..... The 407 was an upgrade/derivative to the 206L-4. Common mistake, but the OH-58 and 206/407 lines have not connected for a long time.

I must have missed this where you mentioned it before, important part of the puzzle that explains a lot as to the "why" and everything you have tried to explain so far. I looked it up as well in the F-16 flight manual and indeed this statement is correct for the real f-16, learn something new everyday. I suppose if they fix the pitot heat it would no longer be possible to enter this condition, and therefore it would be irrelevant if the oscillations are normal. I get what you are saying now. Cheers,

As I stated before, all my tests have been with anti-ice off and frozen on purpose (therefore not related to the bug you refer to). The goal is to know if the resulting pitch, when frozen, is a bug (not the anti-ice system). We already agreed there is another bug where the anti-ice does not work correctly, and if I recall, the specific bug you keep referring to has already been acknowledged by ED. It seems we are going in circles together, but for clarity, we are not talking about the same thing (not a bad thing, just a misunderstanding). You are not wrong and yes it is the reason more people are experiencing it, but is the pitching normal?

There is no doubt the FCS is dependent on air data. However, the FCS also has built in redundancies and safeties in place to avoid or mitigate this type of situation. Specifically for the F-16 : https://www.sto.nato.int/publications/AGARD/AGARD-AG-234/AGARD-AG-234.pdf (p.4-4) AGARD-AG-234 https://apps.dtic.mil/dtic/tr/fulltext/u2/746580.pdf (p.1-4) AGARD-CP-06 That being said, and regardless if its modelled to the real thing, I think the important thing to know is if this is intended before debating if it is realistic. I say this simply because they may have modelled it this way or this may be a bug. Without the answer, we can only speculate.

Repeated again today, this time I made a track file. File is just over 5MB, so had to throw it on the google drive: https://drive.google.com/file/d/1Z_c-flmTTHo6ie56Ck8TaWEoFk7ttMBZ/view?usp=sharing

To separate the known from the unknown, ED would need to answer if it is normal the aircraft starts pitching when pitot static icing is present. I did a few tests and posted a while back about this where I performed tests with pitot heat "OFF" on purpose to see the results. I found that once the pitot system ices over, descending in altitude causes the airspeed to cross 0 kts into what seemed like negative values which therefore causes the pitch oscillations. Increasing the altitude caused the airspeed to increase and re-cross the 0 kts and stop oscillations. There may be an issue as Deano states with the pitot heat system that would inadvertently cause icing, but the question remains that if the pitot system is subject to icing, is the behavior normal. If it is normal behavior for the aircraft to pitch when frozen and airspeed crosses 0, then the flight manual may need to state this or it be communicated. For those experiencing it with pitot heat on, the resulting pitching would be a result to the fact the system has icing due to the heating system not working correctly. However, these are two uniquely different issues only tied by the fact one bug may be leading to the discovery of the second (which still has not been confirmed as being normal or a bug). 1. Pitot heat system bug (which is a cause) Which would inadvertently lead to the second issue: 2. Pitching as a result of negative airspeed/icing.

I can't upload the originals, but someone already did the work for me: CONTROL, INTERCOMMUNICATION SET C–1611D/AIC: https://radionerds.com/images/b/b1/TM_11-5831-201-20.PDF UH-1H OPERATOR'S MANUAL (communications can be found starting on page 3-1): https://milviz.com/Online_products/Manuals/UH-1H_Flight_Manual.pdf

I can't speak for anyone else here, but this is a different / unrelated issue to what I was referring to. Cheers

Again, would not argue with you there and is exactly what I said (how it got departed is semantics and not all that important). However, the point I was making is that the issue is with the aircraft not in a departed state where the pitch oscillations are present.

Ok so I didn't manage to get a track, but here is how I managed to reproduce the behavior twice today (some may not be necessary, but this is my setup) 1. Caucasus winter with clouds/snow 2. Fly at 25000 ft with pitot heat off 3. Every 10 minutes start a gradual descent (~2 deg down) 4. If the airspeed is going down, then usually the indication the icing is present. 5. Verify altitude is stuck and not updating 6. Once confirmed icing, descend altitude. The result will be airspeed crossing the 0 kts mark and cause induced pitching in the aircraft. It should be noted that the airspeed will once again increase after crossing 0 as if entering negative values, and the pitching does require a light pitch input from the stick to notice. Notes: 1. The slower you travel at higher altitude, the higher the altitude you will notice this behavior as it will take less altitude to cross the 0kts mark when iced over. 2. Descending to low altitude will cause the system to unfreeze (it seems) so recommended controlled altitude decrease when icing is observed. This was noted the other day with the two ship on the first occurrence (not in these two tests) 3. Both attempts took me about 30 min to achieve, but results were identical. 4. To stop oscillations I tested two recoveries: 1. pitot heat (A/C returned to normal) / 2. Cross back over the 0 kts mark (by increasing altitude - A/C returned to normal, pitot still frozen) Let me know if you need any more info, sorry I didn't notice I was not recording the tracks otherwise I would have posted them (the whole point of my experiment today was to produce the tracks on top of it - just a bit frustrating) As a side note, Deano87 seems to have put the aircraft in a departed state and is not what I believe the rest of the thread is referring to. The above test is pitch induced oscillations with the aircraft in a steady (not departed or stalled) state. Although I would not argue that it may have been a result of the same situation/event. Cheers,

Turn on pitot heat, check your airspeed went to zero. I am not sure if this is a "feature" of the flight control system with invalid airspeed. Happened to two of us yesterday as well, we controlled both aircraft long enough to regain airspeed indication and it stopped.

Hi Ziptie, yep pressed it with SOI on TGP then HSI then HUD etc.... In addition to that, we were two people in the same mission and did the exact same steps to create the waypoint and designate, but this only happened on my end. Only difference I can see is that I was the one to communicate with the JTAC and this happened after that. I don't know if it is related, but I have not had time to test it further yet.

Same thing happened to me the other day. Not sure why. Tried removing the box on the HSI from TGT Tried undesignate - HSI, TGP, HUD, RDR all as SOI Tried changing waypoint (SA page, HSI page, HSI data page) Tried turning off TGP Tried entering new coordinates in the HSI data page Tried re-designate Nothing worked, it was stuck on target designate and would not switch waypoints. It was very odd because this had never happened before. I must add that the waypoint was added manually using grid coordinates, not sure if that has something to do with it. Anyways, you are not alone.