RealAir Turbine Duke control problems

[Kyprianos Biris 12]

Yes Flight1 GTN.

OK noted.

[Kyprianos Biris 12]

Another weird phenomenon I experience during this problem and I found out during the closure of the flight once landed (with the help of keypad for the lost ailerons control).

After the problem occurs, when I lower the landing gear the fuel on board is automatically maxed out !

I detect this by the software that tracks my flight for the PIREP that will be sent to the VA I fly for.

Not that is really weird !

P3D fuel display up on landing vs fuel display in my PIREP software.

 

Aircraft status upon engine shut down at apron.

The yoke seen turned right is where it was (visually) stuck after the problem. Using keypad the ailerons would turn but not the yoke. Using joystick would not affect them.

[Gregg_Seipp 565]

4 hours ago, Kyprianos Biris said:

Another weird phenomenon I experience during this problem and I found out during the closure of the flight once landed (with the help of keypad for the lost ailerons control).

After the problem occurs, when I lower the landing gear the fuel on board is automatically maxed out !

I detect this by the software that tracks my flight for the PIREP that will be sent to the VA I fly for.

Not that is really weird !

P3D fuel display up on landing vs fuel display in my PIREP software.

 

Aircraft status upon engine shut down at apron.

The yoke seen turned right is where it was (visually) stuck after the problem. Using keypad the ailerons would turn but not the yoke. Using joystick would not affect them.

Gosh, this is fascinating.  So, did you fly this last flight with heading mode?  My theory was that it was either the GTN (possibly corrupting something or sending the command due to a glitch) or the NAV mode on the autopilot being wonky.  Looking at the fuel in your last picture, fuel looks to be about half load.  Also, your fuel in the ACARS looks to be about the same?...330 on board vs. 777 full load?  Maybe I'm missing something there.

[Kyprianos Biris 12]

3 hours ago, Gregg_Seipp said:

So, did you fly this last flight with heading mode?  My theory was that it was either the GTN (possibly corrupting something or sending the command due to a glitch) or the NAV mode on the autopilot being wonky.  Looking at the fuel in your last picture, fuel looks to be about half load.  Also, your fuel in the ACARS looks to be about the same?...330 on board vs. 777 full load?  Maybe I'm missing something there.

No I flew it in NAV mode guided by the GTN750.

 

Ignore my fuel comment. My bad.

I now find out I simply landed overweight and it was not a glitch due to the Ailerons problem.

Just setting up same (arrival) fuel and payload before departure just gives me the same weights.

It was just my bad calculation and ACARS just warns on this. Before departure it does not warn on overweight in regards to MLW since I have not landed yet.

 

 

Next flight will be a test with same set up but instead of NAV mode I will use just HDG mode to get there.

Thanks for the follow up.

[Kyprianos Biris 12]

Next test flight: Heading mode only. No problem. All went OK.

[Gregg_Seipp 565]

10 minutes ago, Kyprianos Biris said:

Next test flight: Heading mode only. No problem. All went OK

Hmmm...a clue? 

So, in NAV mode, sometime after you leave ELVAS, you're still on autopilot...everything seems fine but, if you disengage the autopilot, the airplane leans to the right and you have to use keyboard commands to get it back under control.  Or does it do it while on autopilot?  I do still have my P3D3 set up with the TDuke and Flight1 GTN so I could try to duplicate the exact problem.  I also have the TDuke in P3D4 with the RXP GTN so I could test that as well.

Did you add a SID and/or STAR to this flightplan?

[Kyprianos Biris 12]

You describe it correctly.

My next test will be by reconfiguring GTN750 (from F1 Config) to command in HDG HOLD mode and not NAV mode and fly again same route.

Last flight was with autopilot HDG mode using external (FSCommander) command and GTN750 active for waypoint sequencing on map only (GTN configuration was for NAV mode).

For departure (for my tests) after take off after 4.000ft I just turn DCT PIKAD.

For arrivals I load VOR W 35 procedure from KRK VOR and I activate it once inbound KRK.

[Kyprianos Biris 12]

No need for GTN changes and more tests.

The problem occurs even on ground at Cold and Dark.

Once I opened the P3D menu from top to change my start up fuel and pressed OK I saw at an instant the Duke's yokes move far right instantly.

The aileron axis was disabled even though Joystick was sending data to FSUIPC so this is a RealAir Duke specific issue.

I changed to another aircraft and the aileron axis was still dead.

Back to the Duke, still dead.

Shutting down and reloading P3D only brings back the aileron axis.

[Gregg_Seipp 565]

2 minutes ago, Kyprianos Biris said:

No need for GTN changes and more tests.

The problem occurs even on ground at Cold and Dark.

Once I opened the P3D menu from top to change my start up fuel and pressed OK I saw at an instant the Duke's yokes move far right instantly.

The aileron axis was disabled even though Joystick was sending data to FSUIPC so this is a RealAir Duke specific issue.

I changed to another aircraft and the aileron axis was still dead.

Back to the Duke, still dead.

Shutting down and reloading P3D only brings back the aileron axis.

A couple of things:

• Open your options, go to weather and set the thermal view to "Schematic".  Go outside the airplane and see if you're in a thermal.  It's a weird request but, I've seen this.
• Probably a better idea, go into FSUIPC and change the axis setting to "Send Direct to Prepar3D". 
• Also, you do have axis turned off in P3D control settings, correct?

Gregg

[Kyprianos Biris 12]

1. OK I changed to schematic for next test flight.

2. This is how I have them, Direct and Calibrated through FSUIPC

3. You mean controllers ? Yes all Disabled and controlled via FSUIPC.

Since my last post I tried another 3 flights. Same route outbound and return.

The problem occurs each time whatever I do.

Sometimes I noted that it occurs when the P3D window is not the windows on Focus i.e. when I open/raise other windows on my extended desktop to see things.

For example this happened and in one case I lost the Duke's POWER lever axis and on another case the rudder axis!

So its not aileron specific but this is where it happens most often.

Then on next flight I tried again and again with (P3D) Window change of focus by opening and manipulating other windows all the time while the Duke was operating in P3D.

Nothing happened in that session (beginning) but the problem of lost ailerons happened again in flight.

It occurs after 30~32 minutes of flying on autopilot at cruise altitude and GTN750 feeding the NAV mode of autopilot.

I tried HDG mode only.

I actually you can "feel" when the problem has occurred by the following. You let the Duke yokes to remain in sight so you can see when they roll or not.

If you gently push joystick on one side the action gets a reaction by the autopilot which counteracts the move the opposite way and so you see the Duke's yokes move (roll) left right.

If the problem has occurred then you do not see this happening since the joystick has no effect and then you know what will happen next time you disengage the autopilot.

The joystick test is just to provoke the move of yokes. They still will not move any more if the problem has occurred anyway its just that autopilot moves are minor so you do not spot this.

If the Duke yokes roll left-right then the problem has not yet occurred.

 

If you are waiting for the problem to occur its easier to handle it (A/P OFF, immediate keypad 5 press to center aileron and immediate keypad 4 press to counteract the right aileron and then 6 to center ailerons again when needed, A/P engage again).

Still though on final approach when you will disengage the A/P you still need to bank left-right with keypad to turn base, line up etc. while using the joysticks for pitch, power and yaw. Totally ruins the simulation.

I still continue the tests in hope of finding a probable cause ...

My spec's:

P3D run in VC view, Windowed mode | PC: i7 3770@4.1 Ghz | NVidia GTX970 4Gb | 8 Gb RAM | Win10 | Prepar3D 3.4.22 | 2048 resolution
2x28'screens at 1920x1080 | Orbx FTX Global Base & Vector, openLC EUR&NAM | AS16+ASCA weather | Chaseplane Camera | vPilot for VATSIM with Mytraffic6 AI

[Gregg_Seipp 565]

4 hours ago, Kyprianos Biris said:

You mean controllers ? Yes all Disabled and controlled via FSUIPC.

And, if I recall, if you restart the sim, the problem goes away, yes?

If that's the way you've always had them, I would turn off the controls in P3D and select the option to send them through FSUIPC calibration.  That's the way I always do mine when I set up a new aircraft.  Make sure they also have their own profile (the checkbox in the middle top of the axis tab).

You tried it in HDG mode, did the problem occur in HDG mode?

From the description above, I would think that either a) P3D is losing signal from your controls...the test above might fix that) or b) when the problem occurs something else is also providing input to the controls...software or hardware (check every axis on every controller, even unused ones that they're mapped to the right things).  What kind of controllers are you using?  Do buttons on your controllers get do the same behavior?

[Kyprianos Biris 12]

Gregg thanks for the follow up.

I think its not related to my controllers because if it were I would be losing control of them at other aircraft as well. This has NEVER happened. It only happens with the RealAir Turbine Duke.

RealAir seem to have some sort of filtering of axis input data before implementing it. I can "see" this by the fact that the aircraft is loaded when P3d completes the launch and it takes 2~3 seconds until control inputs actually start moving the Duke's yoke (regardless if its Cold n' Dark or not). So there must be some filtering there.

Yes I tried a flight in HDG mode and it did not happen. I was flying on HDG commanded by FSCommander's GPS leaving the GTN750 progress map only a visual advisory.

The problem occurs when the Duke autopilot is in NAV mode fed by the GTN750 after some 30 or so minutes of flight.

[jabloomf1230 2,445]

The problem stems from the way that P3d4 saves panel settings between scenarios. For some reason, this only adversely affects the TD Duke. Some internal sim variables are getting overwritten which eventually leads to the control failure.

1. Start P3d4 with the sim default scenario and with the Scenario Manager active so that you first enter the scenario screen and not a flight.

2. In the SM, change the aircraft from the F22 to the Duke.

3. Create or load a flight plan and answer yes to moving the aircraft to the departure airport.

4. Fly.

The next time one starts P3d4, the Scenario Manager will start up with the Duke so one only has to load a flight plan. Whatever you do, don't use a saved scenario.

[Gregg_Seipp 565]

4 hours ago, Kyprianos Biris said:

Yes I tried a flight in HDG mode and it did not happen. I was flying on HDG commanded by FSCommander's GPS leaving the GTN750 progress map only a visual advisory.

Well, it's interesting that it didn't happen with HDG mode.  I'd still try checking your axis, especially in FSUIPC, to make sure they are all mapped correctly.  Then I'd switch them to be callibrated in FSUIPC and, above all, make sure the controls are turned off in P3D.  That's what I'd do.  And it certainly wouldn't hurt to try @jabloomf1230's advice.  Simple to try even before you do any of the above.

[jabloomf1230 2,445]

Thanks Greg. The problem only occurred for me rarely, but I got curious and tried to make it happen on purpose. It's easy to make it happen more frequently with the Duke. First fly from London to Dublin. Save the scenario.  Open that saved scenario and fly to Paris. Save that scenario. Open that scenario and fly to Berlin. You get the idea. As scenarios are further and further removed from the default scenario, the probability of corruption increases.

I've always wondered if the P3d UI setting  for "panel serialization" is what is causing this problem.