Rav3nX

Oh my god guys! I have been struggling with this for over a year; I have built a pit, played for years, and this stuttering has been driving me nuts; I'd spent 3k on new hardware; done everything and one of those settings (think the DPI override one) just fixed it! I had given up on this hobby completely because of this crap but now it's all cranked back up and looks beautiful and runs perfectly smooth! Dude; thankyou. You have no idea how much I mean that. I have just spent 10 minutes running around the house like a little girl screaming with excitement. Thankyou

Retreating blade stall is purely a function of airspeed; it will happen 130kts+ (depending on aircraft etc) although absolutely wont happen in a high hover nose over or low airspeeds. (Without going into the 'oh but what if I.....complicated fringe cases.)

Close lol; a bit of a medical issue prevented an even worse condition; I can say proudly I'm not the holder of a H-CPL; So I get to enjoy the life with normal benefits such as a fixed abode and a wife and kids that reside with me; a functioning liver too! (Said in jest). I did most of my license before this issue pulled up my medical; and in a almost 20 year career since in a large family business (helicopter training which became aerial fire-suppression) has afforded me much more flying experience than a normal engineer. I'm mainly an avionics tech, that flies at any and every excuse. However; possibly close to 200 hours in 412's, probably 10-20 in BK117's, S76's and 206L and maintaining AS332L1's and UH-60s has given me over the years a good exposure to all the bits and pieces. I'm routinely board-level repair of AFCS helipilots and couplers etc; so, these are systems I know backwards (born of sadness-level fascination) I don't say this as a grandstanding; it’s just my career; I do just so that hopefully my input can be distinguished from the noise because...I really want this Ah-64 to be all it can be. It is sooo close, functionally in assessed in individual components the functionality is all there, the bits work the way they should its just the engagement level logic has become confused I think; and that's totally understandable; these are complicated systems. Unfortunately, too many times I have heard pilots on here and around the net explain them, although usually what they say is true; its often-missing fundamentals that if the receiving dev or individual was missing or had a misconception about a particular function its easy to confuse the picture. That’s not meant as a slight; there is a ceiling to expected understanding of these systems for the average Joe, and a lot of real basic concepts are usually missed or assumed and the misconceptions compounded. I have wanted to put the hydraulic rig on one of our 412’s many times to make the ‘helicopter autopilots 101’ video and I still might. Obviously, I too am limited in real world Ah-64D experience (until I find one! -jk), however having flown enough different types and read the real dash one to know that; functionally a lot of these modes are very similar to everything else; some things work the way they work because that’s just how they all work. Same as right pedal for right turn; its that way because that’s how it is. The flapping you describe is true; and that’s a function of the RC circuits rate limiting function of the helipilot; fringe cases that at this point I think would only confuse the issue and I suspect the description of cases like these is what’s lead to the confusion at times. I really think that there has been confusion of modes, and possibly a background in non-western aircraft systems from the devs has resulted in what is currently the case; and obviously the lack of public extensive data and detailed functional descriptions isn’t helping. It seems that the focus has been shifted to the high-level modes which has left the confusion with SAS to sneak through; and currently I feel that the basics need to be given the highest priority and the rest can follow; otherwise, there is just function adding to an unworkable system, and its unfortunately really destructive to the experience as is. Flying straight and level shouldn’t be the task it currently is. To the Devs; I do have good non-classified data and plenty of very-high level experience with these systems and I am more than happy to volunteer my time to assist in the understanding and improve this; if the assistance is wanted; and I would caution against taking advise on engagement logic from Pilots, with respect I know that the many that I deal with have ‘enough’ understanding but much of the functionality is transparent to the operator. I do stress though you guys have absolutely nailed the ‘how’ for the individual components given its current level of development; just not quite the ‘when’, and I offer my assistance if wanted. I’m sure many of the issues I describe are known. Cheers

Hi, Easily reproducible by moving the cyclic in the hover while watching the controls indicator; it seems that the AH-64s SAS/SCAS is correcting attitude in response to pilot cyclic input. For example a sudden movement to the left will produce a right AFCS input to counteract an input. This would not occur in an aircraft, (with or without force trim held) without complicating it by talking about attitude modes and force gradients; in normal hands on flying if a cyclic input is made position sensors on the cyclic system (LVDTs/transducers) indicate to the AFCS that the pilot has made the input and not an external disturbance therefore the AFCS should not produce an error and correct the attitude/control displacement. I understand this may be a desired function of producing a more stable flight model, although the effect results in a less than predictable 'feel' and the aircraft trying to return to the original attitude. Additionally and possibly related pressing the force trip completely disables the SAS. While depressed the SAS should be correcting for external disturbance and secondary effects of controls, (yaw etc) but not pilot input. It seems while depressed the AFCS is completely disabled. The force trim implementation on springed joysticks is a tricky issue to deal with, but normally forcing a control even without force trim held (whine NOT in attitude hold anyway) should not result in a SAS correction regardless of force trim release position. (Forcing a cyclic against a mag brake will have the same result as holding force trim; though only while not in attitude hold) Anytime the joystick is moved (or forced) from the trimmed position should cause the trimmed position to follow. The current behaviour with Attitude hold off is more like what I would expect with attitude hold on. Additionally turning the mag brake off will not disable SAS. Not in any helicopter. (So long as the cyclic is held, it should be modelled as if this is the case) (B1/B2 Avionics/Airframe Part 66 maintenance licence and several hundred hours of twin turbine helicopter experience -B212/B412 (functionally similar AFCS system)) Offered as assistance as it appears some mode/functional confusion has occured. (Understandable). Sorry for the dot pointing breif summary; writing on a phone.

We (I anyway) understand it's currently w.i.p; and it's excellent so far, the feedback is given as assistance; not criticism. You guys have done a damb fine job to get here.

I haven't done many autos in the Ah-64; mostly because there's pre-trained lizard brain that just panics when the cyclic position weirdness happens; but obviously the flight models autorotation stuff is miles off right now; The whole aft cyclic thing......when you dump the collective in a helicopter to enter autorotation; the cyclic doesn't....move? you need to obviously adjust where your cyclic is but there's none of this riding the back stop rubbish or substantial uncommand roll; it just flat out doesn't happen, the cyclic just does what cyclic's normally do. Not sure how best to explain it. I have also noticed the cyclic becomes very 'spongey' at low collective positions, this again doesn't happen. The blades pitch changes with the cyclic the same amount regardless of the collective position, its as sensitive at high power settings as it is at very low collective pitch angles. I have never noticed a difference in cyclic 'feel' in all the many autos I have done in my life. And defiantly no being in the back left corner of the cyclic travel turning right and pitching down like that; I'd probably jump out the door if I ever felt that That's nightmare fuel.

Hey all; (And Devs) For what it helps; I too came on here to post about this; I do fly twin engine helicopters with all the SAS goodies (irl) and this roll with forward cyclic is defiantly attention getting as not normal behavior. It does seem to sometimes also roll right, though not as often; although I cant seem to put my finger on what makes the difference; flying out of trim or pre-rolling doesn't seem to make a difference as to which way the aircraft rolls. (Although mostly left) I can put my two cents as someone who flies; currently with the ATT Hold/SAS collective issues aside the flight model feels...mostly fantastic; however in the cruise it seems; not just in the last 10% of forward cyclic; in the cruise in a normal forward cyclic position (3/4 fwd?) the roll does become more sensitive; the net result is in the cruise its very difficult to hold a roll attitude. I cant remember the last time flying a 412 level I had to think about the cyclic; but cruising around at this just holding a level attitude at ~100kts + is ALOT more work than it should be. Pitch seems totally fine. A lot of these things are very subtle but to the practiced hand it has a devastating effect on the enjoyability of the product I am sorry to say. I'm sure we will get there

Thought I would share this; its a script to identify input pin numbers for helping setup DCS BIOS etc; Lots of times I have pined through a giant connector; and rather than heaps of work keeping track of it all, its easier to work it out at the end. So here you go; just upload this to the board then open the serial monitor in arduino IDE. Press your buttons and you will get the pin number. EDIT: Obviously this is built for the MEGA, change loop numbers to suit your pin count. //Pin state change serial printer int PinStates[54]; int A_PinStates[16]; int APinVals[16]; //char aPins[16] = {'A0', 'A1', 'A2', 'A3', 'A4', 'A5', 'A6', 'A7', 'A8', 'A9', 'A10', 'A11','A12', 'A13', 'A14', 'A15',}; static const uint8_t analog_pins[] = {A0,A1,A2,A3,A4,A5,A6,A7,A8,A9,A10,A11,A12,A13,A14,A15}; void setup() { Serial.begin(9600); for(int i = 3; i <= 53; i++) { pinMode(i, INPUT_PULLUP); } for (int i = 0; i < 16; i++) { pinMode(analog_pins[i], INPUT_PULLUP); } } void loop() { for (int i = 3; i <= 53; i++) { int PinNumber = i; //i + 4; int CurrentState = digitalRead(PinNumber); if(CurrentState != PinStates[i]) { Serial.print(PinNumber); Serial.print(" D"); Serial.print(i); Serial.print(" [ ");Serial.print(CurrentState); Serial.println(" ]"); } PinStates[i] = CurrentState; } for (int y = 0; y <= 16; y++) { int PinNumber = y; //i + 4; int CurrentState = digitalRead(analog_pins[y]); if(CurrentState != A_PinStates[y]) { Serial.print(analog_pins[y]); Serial.print(" A"); Serial.print(y); Serial.print(" [ "); Serial.print(CurrentState); Serial.println(" ]"); } A_PinStates[y] = CurrentState; } delay(10); } }