Piston & Turbine Dukes

@Black-Square - Thanks. Sure enough, it was a failure and I misread the manual.

Just finished that flight, SCCI-SAWH. I changed from PMS750 to GNS530 and 430. I didn't use the GPS for navigation, but only VLOC mode. No problems at all. Everything worked as expected. Maybe i will try it again with 530 but using the GPS for navigation.

Thank you very much, that's what I understood.

Ok. then I made a mistake in my thinking. I was of the opinion that the friction lock acts on the trim.
Thanks for the quick answer.
Michael

@LondonSimmer looking at the files, I don't think the final prop heat amp value is actually saved into a convenient variable, but this is a simplified expression that is used to calculate value on the prop amp meter on the panel:
(A:PROP DEICE SWITCH:1, bool) 17.5 * (A:CIRCUIT ON:10, bool) * (A:PROP DEICE SWITCH:1, bool) 18.0 * (A:CIRCUIT ON:11, bool) * + (A:ELECTRICAL MAIN BUS VOLTAGE:1, Volts) 12 > *

The actual expression is much longer, and introduces effects like the needle wobble, but this should be just the plain numbers, if I got it right. Seems to work for me.

I think you might be right about the rnav/nav1 selector its probably with the kns, even tho i dont have the KNS installed on my plane only 2 GTNs... so i'm not sure.. I still dont get why i dont get the GS working as its a different issue, ill try again to fly an ILS and see if i can get it to work

Edit : okay i just tested again and now it seems to work ill try with a 3D rnp now
Edit : okay seems to work now idk why i'll let you guys know if it does it again

I see that on my end too. Thanks for the detailed description. From interrogating variables, it's caused by "outer loop's" commands to the flight director, not the "inner loop", which is the autopilot's PID controller. From my work on the Starship, I've seen that the outer loop has some... interesting behavior when it comes to flight director commands during mode changes. I'll experiment with this a little and see if there is something I can do. That being said, the Duke owner who had a Century IV in his airplane told me that he actually warns passengers before changing autopilot modes because the "bump" can be significant when it commands pitch changes.

You always seem to come to me with the most interesting and minute issues! Thank you for taking the time to let me know about all of them. It was baked into the model file that way. No idea why. Thanks for pointing it out. Easy fix.

Nice!
It is fantastic to see how dedicated you are to get everything working perfectly. Also in a case like this, where many users might never notice that anything is wrong.
Makes it much more satisfying to dive deeper into the systems, when you know that the dev is not just aiming for having the basics "look kind of right", but actually wants to simulate the underlying systems properly.

@SomeoneCalledRay said in WT GNS Still unusable:

So I got the GTN working, haven't retried the GNS because couldn't be bothered, but I had a weird issue today where no lateral modes apart from heading were engaging (pressing buttons, etc).

I'll post about this shortly.

I just had I think the same issue. Only heading would engage, and once it went into Alt, subsequently pressing Att would remain in Alt and level off at the current altitude.

I think it was my first flight after updating to SU15, and restarting from the runway instead of cold and dark for a quick test worked OK.

What ended up happening with you?

The event.txt file in FSUIPC uses this:
AP_Century_IV_Pitch_DOWN#(L:var_AP_PitchKnob) 0.5 + 14.5 min (>L:var_AP_PitchKnob)
AP_Century_IV_pitch_UP#(L:var_AP_PitchKnob) 0.5 - -14.5 max (>L:var_AP_PitchKnob)

I just finished playing with this myself. There's definitely something fishy going on. The sound is instantaneous on the exterior, but there is something on the interior delayed after the nose touchdown, but sometimes before the nose touchdown too. I'll pass this along to my sound designer and see what the problem is. Thanks for pointing it out. I always thought it was just the tires skipping down the runway after a bump.

@Black-Square I think it's something about the linearity of the rates.

What I mean is this: In the Turbine Duke, the prop goes from invisible, to moving at perhaps 50-80 RPM (visually) in a fraction of a second, even though the NP indicates it's still spinning faster than that. But, after becoming visible, it does indeed take a while to stop. The animation doesn't depict a smooth deceleration from disc to visible blades at all (to whatever extent that it should be). Also, the audio seems to end long before either the NG or the prop stop spinning. It feels like the audio should last a bit longer, and the prop should have a somewhat more linear rate of deceleration. (To whatever extent that is realistic.) This is true of the TBM as well.
For example, the spin downs of the Lancair Evolution and FlyJSim Dash 8 Q400 in Xplane 12 seem a bit more realistic, although even the Dash 8's props just suddenly stop at the end of their animation... So maybe just the Lancair? It's audio is also more consistent in its taper off. Of course, I'm open to hearing that the Lancair is the one that's wrong.

Finally, while the TBM 700 seems to take a while to feather its prop after shutdown, as per your linked video, the 850 and later models seem to feather much faster: https://www.youtube.com/watch?v=QfSDPwsIAlo

Aircraft that are inherently stable should converge back to their trimmed state, assuming their CG is properly balanced. However, not all planes are inherently stable, as stability is the opposite of maneuverability. Generally, the more high performance an airplane is, the less inherently stable it is.
All of that being said, I find the Duke to be quite stable when trimmed, and hand flying it is a joy.

@Randolf Loading Position is working now - thx

And by the way: AAO was updated today in the JustFlight marketplace.

I created another thread to be able to have a blender model ready for painting, and a photoshop one too. Hope someone steps up to do it.