The one on flightsim seems to have been taken down. A2a has one that came with the Aerostar but it doesn't seem to work any more either. I'm guessing Asobo broke it with SU4.

@turnandbank oh yeah, different issue then -- I'm referring to the actual gauges. I find the cockpit to be very dark when the outside light is approaching full daylight, making it very difficult to read the gauges even if I scoot my view up a bit. I have a feeling it's a sim issue but maybe it's something else I'm not aware of.

Did you also Clear Engine and Clean Filters?

@Black-Square Sorry Nick, I had to crop the screenshots because 1440 is apparently too big for the forums to handle, and I thought I did a better job describing. And yes, I am in MSFS 2024, which I'm sure I missed saying in the OP. Yes, I have been starting with the propeller feathered, only for the last screenshot with the battery charging and positive instrument air had the propeller out of feather and in the high pitch position. Incidentally, I noticed with the propeller feathered that instrument air and fuel pressure reached nominal levels during startup, and then fell off again. I thought I had been keeping abreast of the propeller RPM issue, but apparently I missed how pervasive it is. Sorry about that. This is the same issue as the generator not being tied to the Ng, and therefore not putting out enough power at lower RPMs?

Hey guys, I don't know exactly how the throttle axis is configured on your TQ6s, but I had good results with my Velocity One quadrant using the MSFS 2024 sensitivity settings. I posted the results here if anyone would be interested in taking a look. This gives me the entire range of forward and reverse travel on one axis and roughly matches the virtual detents with the proper positions on my physical axis, though I don't have physical detents. If you guys have physical detents, this same method should, if I'm understanding it right, allow you to tweak it such that you can match the physical detents to the virtual ones, it might just require a different neutral and Sensitivity+/- settings.

I know this is not what you guys are looking for, but I highly recommend leaving the internal settings behind and switch to something like Axis-and-Ohs, spad.next, Mobiflight etc. This does not only solve the mysterious loosing of controls sometimes it also opens up a lot more options in terms of what you can control. Just as an example I can even manage my sunshades via hardware, every air intake,aso. Initial setup takes a bit longer for every new plane but it is worth it. Only limitation is the number of buttons and axis available as hardware.

@Mark Appreciate it as always.

@jmarkows Looks like you are 100% correct. This is f-ing awesome that even someting like this is modled. This level of detail is beyond amazing. Thanks to Nick.

@Mark Is there a chance this issue could be verified and fixed? The Vulcan is an amazing model and I've been thinking about it for a long time, but it's a pretty serious immersion-breaking issue. If you need more examples, I'd be happy to help. The basic problem is that the stick's deflection isn't symmetrical, so theoretically, it's enough to correct it so that the deflection to the left is identical to the deflection to the right.

There are a couple of sync issues with the sync of the display when H:Event are used to toggle failures. Here are 2 use cases specifically: USE CASE 1, "show only active failures ENABLED" Here are two failures being toggled remotely in the TBM (causing them to enter FAIL state, as expected) [image: 9a391b9a-8c67-4df3-a5e1-a8b0578c6dd6.png] The tablet shows the state correctly. I then toggle the R BRAKE, causing it to be fixed... [image: b76352b7-3647-40d7-ba69-be4a4920caf5.png] ALL GOOD SO FAR. Lastly, I toggle the GEAR CONTROLLER, which was the only remaining failure. This fixes it as expected however the LAST item isn't cleared from the list and remains in red. Notice ACTIVE FAILURES is 0, which is correct: [image: 8e75aa2f-3fbe-4192-8182-a19683b57ac6.png] if I click RESET on the tablet....it actually triggers the failure... (photo taken after clicking RESET) [image: e2967322-6e50-406a-994c-ba007689069b.png] if I click RESET on the tablet AGAIN...it works as expected, 0 failures and clear panel: [image: 49f4250e-91f3-41a8-8fef-df73233689c1.png] USE CASE #2: "Show only active failures DISABLED" I click R BRAKE and toggle remotely (triggers a fail, as expected) [image: e10d7888-76d7-4915-b10e-b52282113426.png] I click R BRAKE and toggle (triggers a fix, as expected). Notice the tablet remains RED for that item, despite Active Failures correctly updating to 0. [image: 59046a3f-2713-426e-9c3f-3bf671606995.png] The same behavior from use case #1 also happens here where if I click RESET on the tablet, it things it's resetting but it's actually toggling to fail mode...it then takes ANOTHER reset to clear. Keith Smith PilotEdge

For Axis And Ohs I managed it, changing the Interior.xml a bit. At the component ELECTRICAL_Switch_Alternator_1 I added this code: <OVERRIDE_ANIM_CODE> (L:var_GeneratorSwitch, number) 1 == if{ 0 } (L:var_GeneratorSwitch, number) 0 == if{ 100 } (L:var_GeneratorSwitch, number) 2 == if{ 200 } </OVERRIDE_ANIM_CODE> Afterwards I used the "Layout Generator" from fs.to to recalculate the layout.json. Now I'm able to control the Switch using something like 1 (>L:var_GeneratorSwitch, number). @Black-Square It would be great if you could add this to one of the next updates. This was already missing in the 2020 version and drove me nuts.

Thank-you both for the replies. You are right! Although I understand the difference between TAS and IAS, I didn't realize two things until now: how high an altitude the Turbine Duke can fly and how much of a difference there is between the two speeds at that ceiling altitude and temperature. I just used an online calculator to illustrate it to myself. 200 KIAS at 28,000 feet and -40 C is 308 KTAS! I'll see if I can use the temp/altitude calibration dial on the airspeed indicator to confirm this next time I'm in the virtual cockpit. [image: 442b95cd-17ea-49e9-acc3-81b35ddc7238.png]

Thank you very much for your advice - greatly appreciated.

Agreed and the OAT gauge top left. The deg C does not match. Dunno about F.

@MarkS Yes, it would be nice if one could quickly determine reasonable PID values ​​without constant testing. Strangely, this only occurs with the autopilot activated in the Cessna 152 when tracking VORs; everything is fine when tracking the GPS flight path. Therefore, I wondered if MSFS had artificially degraded the signal using a random number generator. But that can't be the case, since the C172 doesn't have this problem. What always works is the cone of confusion and, of course, the maximum range. To avoid triggering an error due to the missing line of sight, I also tested this at higher altitudes in flat terrain. Sometimes the autopilot tracks 50 NM without interruption, and then it cuts out for no apparent reason. There's also a peculiarity with the C152 that I only discovered by constantly monitoring the bus voltage variable. For a few milliseconds, the bus voltage drops to zero. You can't see it on the instruments. But since a missing bus voltage triggers a restart of my autopilot in my LUA script, it keeps restarting. The autopilot in the Cessna remains switched on. In summary, this means to me that clean tracking can only be achieved with correct PID values ​​for navigation, roll, etc.