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

As I understand it, the engines never suspend consumption from the mains--they feed *only* from the main tanks, never directly from the aux tanks. Though the collector tanks are physically located in the aux tank, they remain functional components of the main tank system, in that they only receive fuel from the mains. As long as a main tank is below 93% full, the aux tank feeds the main tank to maintain the level at 93%. Once a main drops to 93%, the main quantity will remain constant and the aux level will drop. It will appear that the engines are burning from the aux tank, but in reality the engines are burning from the mains and that fuel is being simultaneously replaced in the main tank from the aux tank ejector xfer pumps. Regards Bob

I'm having a similar but more dramatic issue with offline ATC (Radar Contact)--this seems to be a problem more related to temperatures--the ambient temp set by ASXP and reported by X-Plane at FL280 is -32 +/- 3 deg C, but the temp on the PFD is wandering through a series of fairly sudden changes, with SAT ranging from -9C to -19C. When indicating SAT at -19C (ISA +21) the indicated altitude reported by X-Plane is more than 1800 feet higher than the Challenger's altimeters. So the RC4 controller is giving it to me with both barrels for being off my altitude. Regards Bob

OK, I hadn't played with the system study windows before this. It looks like this is an indication problem, because the study window shows fuel transferring out of the L main and into the fwd aux tank, but the indications on the Captain's MFD do not reflect the transferred fuel in the aux tank quantity (still indicating zero after transferring 266 lbs from the L main to the fwd aux tank) and the total quantity indication has decreased 230 lbs from 4370 to 4140 lbs. Here are the screenies--seq 1 is initial condition, seq 2 shows the panel config and study window after transferring for 3 min, seq 3 shows the study window and MFD indication a few seconds later. Regards Bob

I am using version 1.4.1 of the Challenger. There's a nasty bug in the fuel transfer logic. When transferring I am seeing a drop in total fuel quantity, inconsistent transfer of fuel to the aux tank, and no aux tank scavenge pumping back to the main tanks when on boost pump pressure. Scenario--acft on ground, powered by ground AC unit. There is no fuel burn occurring, so in all cases total fuel quantity should be preserved as fuel is transferred between tanks. Starting tank quantities are (LMain-Aux-RMain-Total in lbs) 2160-0-2170-4330. Tail tank quantities remained zero throughout the test. I turn on both boost pumps, and select L-to-Aux on the transfer panel and transfer for three minutes. Then I allow one min for qualtities to stabilize. Quantities after the transfer are 1880-0-2170-4050. No fuel was transferred to the aux tank, and the LMain and Total quantities dropped by 280 lbs. Then I transfer R-to-Aux for three minutes. After stabilizing, quantities are 1880-120-1900-3900. 270 lbs left the RMain tank, 120 were added to the Aux, and total dropped by 150 lbs. Then I transfer from L-Aux for three min again, leaving me with 1640-300-1900-3840. 240 lbs left the LMain tank, 180 lbs were added to Aux, and 60 lbs were lost from the system total. In none of the cases did I see any scavenger transfer of fuel from the aux tanks back to the mains, which should be occurring with the mains at less than 93% and boost pump pressure. I repeated this test three times after restarting the sim with similar results. Regards Bob