airforce2

OK, it appears that this problem is being caused by some kind of conflict between the throttles and the (separate/single) reverser axis--if I remove the reverser axis assignment, the A/T catches the speed normally, and with the reverser axis enabled the problem repeats. I tried increasing the deadzone on the rev axis (confirmed to be producing a stable 0.00 input with no jitter by monitoring the USB axis directly) and it did not help. If I map the same controller axis to the reverser axis via a virtual device using Joystick Gremlin and vJoy, everything works properly. I tried using some of the other axes on the same controller and they misbehave the same way. When I do the slowdown, the throttle retards to idle--with the problem axis enabled, the throttles retard slowly and then "snap" to the idle detent when they get close, and when the power-up approaching the target speed should occur you can see the throttles jittering like they're fighting the reverse axis while the airspeed decays through the target speed. With the reverser axis either disabled or assigned indirectly via the virtual HID device, it's completely smooth as it retards to idle and it smoothly adds power to capture the selected speed. Behavior is the same on v1.7 in XP11.55 and 12.04r2, and on 1.8 beta9 in XP12.

I'd like to try the 1.8 beta before I start disturbing my flight control setup, please. I have joined the Discord group.

I uploaded a second video, this time with the PID windows open and a look around the flight deck. Prior to making this one, I assigned the throttle axes to a different joystick device which is calibrated and does not have response curves added. The behavior is the same...a 50 knot deviation below target speed before the ATS recognizes it and corrects. Log file for this run is also attached. Video at: Log2.zip

That's intentional--I have calibrated them in XPlane and then employed response curves via the standard X-Plane controller interface to put a small dead zone at each end of the axis travel to quell any axis jittering during use of automation in flight. Those messages are what you get when you do that. The post-calibration throttle positions range from 0.00 to 1.00 as intended per the XP datarefs (e.g. sim/flightmodel/engine/ENGN_thro[0-1]). The throttle positions reported in the CL650 datarefs range from 0.128 at idle to 1.00, and 0.00 when the respective throttle is placed in cutoff.

Yes--1.7r1 My best educated guess is that the ATS controller may be setting the throttle pos to zero internally when it retards the throttle to idle, where the throttle position at idle is actually ~0.128 from examination of the dataref. In such a case, the PID controller would push up the throttle setting from zero rather than idle/12.8% initially but not sense any increase in N1/N2, and depending on how the feedback loop is coded, might result in a prolonged delay until the throttle position increases from zero to a point that's within the idle-to-full power range. Punching off the ATS and setting idle+a smidge and then re-engaging gives the ATS a new starting point within that range, which could explain why that works to quickly recover ATS function. Log attached. Log.zip

Yes--1.7r1 Log attached. Log.zip

OK, I used OBS to record the ATS problem. https://www.youtube.com/watch?v=BNIUj9di03Q The video begins with the jet stable at 4000 ft and 270 KIAS. ATS is in SPD mode, and TO is selected as the thrust limit in the FMC. I make a large target speed reduction back to 230 KIAS to drive the ATS to command idle thrust during the speed reduction and the engines to stabilize at idle. The ATS fails to add power when reaching the target speed; instead the speed decays far past the 230 KIAS target, remaining in SPEED mode and idle thrust, until it finally initiates a correction 75 knots (!) below target speed at 155 KIAS. I've done a bunch of flight testing on this, and the key to triggering this problem is for the ATS to get the throttles all the way back to idle while in speed mode. If the speed reduction is small enough to keep the throttles above idle, it works normally. And if I command a VSPD descent that is steep enough to get the throttles back to idle, the throttles remain in idle and the speed decays as soon as I level off. If I disengage the ATS and then re-engage it with the throttles still back at idle, it does not respond. If I disengage the ATS and bump up the throttles even a tiny bit above idle and then re-engage, the ATS responds immediately. I watched the ATS IAS Speed PID Controller and the L/R N1 PID Controllers in the study windows during a few of these excursions--the ATS IAS controller is properly showing an increasing proportional input required as the speed decays past the target, but the N1 PID controllers remain stuck at full idle (P=~3.5) for a prolonged period...sometimes all the way from 250 KIAS into the stall shaker.

I've been able to duplicate this in both XP11.55 and XP12.04 The video is crappy, but you can see what it's doing--at ~3:55 I am descending to 3000 ft at idle with 200 KIAS on the speed bug, in speed mode with TO selected in the FMC and annunciated in magenta on the MFD. At around 4:00, the jet levels off, and the airspeed decays right past the bug speed, with "SPEED" still on the ATS mode...at about 30 knots slow and still decelerating, I disengage and take manual control. CL650_ATS_dropout.mp4

I've had this happen to me two flights in a row now--during descent once, during the slowdown/maneuvering in the radar pattern the second time. With the ATS in in SPEED mode, I reduce the commanded speed on the MCP, and the ATS drives the throttles to idle. As the jet approaches the commanded speed, the throttles are remaining in idle and the speed just keeps decaying right through the target--I let it go once and it dropped to over 30 KIAS below target and was still dropping when I punched it off and reverted to manual throttle control. When this happened, "SPEED" was still annunciated on the glareshield ATS panel, and TO was the selected ATC mode in the FMS. When I disconnected the ATS and reverted to manual control, the "ghost" throttles were all the way back at idle, so it wasn't a case of the acft not responding to an ATS input. Of further note, I was flying into KAFW (Dallas Alliance) both times and was approaching/overflying the very busy KDFW airport--CPU load was very high at the time. My machine is a 24-core 13900K and 4090. It occurred with v1.7 of the CL650 running on XP 12.04r1/r2

OK, I'm confused here--is WAAS not operative at all in the panel, or is the add-on temporarily simulating a global WAAS outage? If it's a simulated outage, something like a NOTAM pop-up notification at the FBO would be helpful rather than leaving us to wonder what we might be doing wrong given the lack of documentation on the Challenger's avionics.

Now that v1.7 is out with XP12 compatibility, is the "--num_workers= n" command-line option still needed in XP12?

Sounds like your throttle quadrant disconnected...a common issue is the USB port powering itself down after a long period of inactivity. Check all your USB hubs in Device Manager and make sure the "allow the computer to turn off this device to save power" option is unticked on the Power Management tab.

This isn't just about online ATC programs--the nonstandard altimetry breaks compatibility with other utilities that determine altitude using the provided X-Plane dataref. Why can't Hot Start just provide a user switch to turn the "realistic" altimetry off? It's got to be a whole lot simpler than auto-detecting online communications from specific ATC programs, and it would preserve the option to employ the standard interface to X-Plane. This *is* a Hot Start issue--this is the *only* add-on I am aware of that chooses to do its altimetry independently of the X-Plane platform dataref, which breaks compatibility with anything not specifically coded for that...in other words, lots of stuff. In my case it's Radar Contact v4, which is not being developed any longer but which works flawlessly with any aircraft that adheres to use of the standard platform dataref. It's also an issue with the Pilot2ATC and PF3 offline ATC add-ons as well. Why is it considered preferable to build complex auto-detection routines in for a select group of ATC clients, rather than just allowing the user to de-select the nonstandard HotStart altimetry with a tickbox?

I'm somewhat dismayed that this was neglected in the 1.5.2 update. Bob

But it shouldn't be an issue however XP12 computes it in the future as long as XPlane is reporting the same altitude that is displayed on instrumentation of acft running on it. The problem here is that this airplane is doing its altimetry independent of the platform. However the platform computes the altitude, for better or worse, the add-ons running on it need to be able to do it the same way, or it creates obvious disconnects between the add-on and everything in the rest of the world. Interconnectivity doesn't benefit from having things done in precisely the correct way, but rather by doing them precisely the *same* standardized way. Radar Contact 4 is having the same problem as what the OP reported here with P2ATC. It uses the altitude reported by XP11 via XPUIPC. The CL650's indicated altitude differs by sometimes several thousand feet from that. Bob