Graeme_77

Check this CB please. You may need to recycle the window heat switches after resetting it.

Thanks. This confirms the issue is a pressurised cabin. Most likely caused by repositioning an aircraft from a low altitude airport to high altitude. I know PHX is not really that high, but enough to cause sufficient deltaP to prevent door opening. The developers will investigate the issue and potentially adapt the persistence logic to deal with this. In the mean time, jump inside the aircraft using the normal X-Plane view controls, power it up and start the APU and bleeds in the normal sense and the cabin pressure control should take over and fix the situation.

The Challenger does not need specific navdata update procedures. It uses the X-Plane nav data, so once you've updated X-Plane in the normal way that data is available to the Challenger. You will need to tell the FMS to use the new data, just like a real aircraft, and this is detailed in the FMS primer document, included with the product.

Not a known issue. Trims set correctly? If it happens again, set the aileron trim as required and then grab a screenshot of the PFD and MFD please.

You can't follow a vertical path automatically when in VOR (green needles) mode. You have to select VS and fly the profile from the chart. The alternative is to treat it like an RNP approach: Check the database coding to make sure the track and descent angle are as per the chart. Tune the VOR, and display the VOR needle using BRG SRC on the DCP. This is to allow monitoring. Leave the navigation in FMS mode - magenta needles. Fly the approach with APPR mode, you should have APPR LNV1 and VGP / GP FMAs. This is shown in the Operations Reference pdf, included in the Documentation folder.

Usually caused by doing an APR check without the engines running. Follow the supplied expanded procedures, start the engines and then do the APR check. In this case the message will clear when you do the APR check with the engines running.

Report 2395 Fixed in v1.1r1, January 22, 2022 Issue should be corrected now, related to how the FMS was using the elevation provided by the GPS systems. Please report any further occurrences in a new thread, and mention Report 2395. TVM.

This could be caused by cabin differential pressure - I'm looking for cases that could cause that, but should the situation occur again, please post a screenshot of the Pressurization Control Study window (Under the Challenger 650 \ Study \ Environmental menu)

Report 2240 Fixed in v1.1r1, January 22, 2022

Report 2291 Fixed in v1.1r1, January 22, 2022

Report 2273 (don't exclude VFR only airports) Report 2281 (don't exclude airports with only grass runways) Fixed in v1.1r1, January 22, 2022

Thanks for the report. Further work may be necessary for the temperature persistence features as we've had a few reports of similar issues. I've marked this as an open issue for now, and will update the status when investigated.

Report 2282 Report 2322 Fixed in v1.1r1, January 22, 2022

Report 2325 Fixed in v1.1r1, January 22, 2022

Report 2275 Fixed in v1.1r1, January 22, 2022 The updated Vatsim client should resolve this issue, but the Challenger 650 has also been modified to disable checking weight on wheels status for TCAS traffic which should also allow provide correct behaviour with older vatsim clients. If the update does not also correct IVAO or other clients, please open a new thread for each individual issue to help tracking. TVM

I did a little bit of checking to see what xPilot client was reading, what the Challenger 650 was writing back to X-Plane, and what it wasn't. This seems like inconsistent xPilot behaviour. It appears to be reading the wrong dataref. For gear and speedbrakes it reads from cockpit2 (the switch position), but for flaps it reads from flightmodel. "sim/flightmodel/controls/flaprat", DataRef::FlapRatio CL650 writes to "sim/cockpit2/controls/flap_handle_deploy_ratio" which seems more logical given the other datarefs. These datarefs are written by the Challenger 650, and as far as I can see, read by xPilot. Could be an xPilot bug if not being sent to the libxplanemp datarefs. "sim/cockpit2/controls/speedbrake_ratio", DataRef::SpeedbrakeRatio "sim/flightmodel2/gear/tire_steer_actual_deg[0]", DataRef::NoseWheelAngle These datarefs will need some changes on the Challenger 650 code to "send" back to X-Plane such that xPilot can then read. "sim/cockpit2/switches/taxi_light_on", DataRef::TaxiLights, "sim/flightmodel/engine/ENGN_propmode[0]", DataRef::Engine1Reversing (default MD82 makes this parameter "3" when reversers are deployed) "sim/flightmodel/engine/ENGN_propmode[1]", DataRef::Engine2Reversing

Report 2240 Fixed in v1.1r1, January 22, 2022

For the op, were three threads about the same thing in one day necessary? Report 2258 Fixed in v1.1r1, January 22, 2022 Challenger 650 now directly overrides the XP default systems avionics state. Should resolve this issue - in the event this issue persists, please open new topic and refer to "Report 2258"

Hello Rich, V1 cuts were tested during the development phase, and rudder authority increased to make it workable, but it is possible some further refinement is needed. The support volunteers vary in experience, from PPL, Airbus, CRJ and Gulfstream pilots, and there are experienced Challenger pilots and Challenger subject matter experts who also know their way around X-Plane well. As an Airbus driver I do find the Challenger hard work on one engine in X-Plane, partly because the Airbus is blessed with a massively powerful rudder and trim, and also because I have pretty cheap rudder pedals and typically fly twist stick rudder. I've asked one of the Challenger pilots to have a look at your report and provide feedback. Should changes be required the developers will do the very best they can, as the objective is to make this simulation as close to perfect as the technology allows. The standard disclaimer about a recreational product, not for real training, etc, etc. Thanks for a detailed write-up, and it's great that the simulation appeals equally to enthusiasts and professional pilots.

This sounds like a case of needing more (A) fuel! and (B) single engine flying practice ;-) v1.1r1 will have some practice failure scenarios and notes, one of which leads to an engine shutdown and single engine landing. Would be a useful starting point.

Report 2252 Fixed in v1.1r1, January 22, 2022

Don't switch off the battery while the is APU running and this APU event will not occur. Can be reset by accessing the APU fault panel on the left rear fuselage.

Further examination is needed for the persistence of engine temperature as persistence may not be guaranteed. Will log issue for tracking.

Report 2314 (nose light spill) Report 2344 (speaker volume) Fixed in v1.1r1, January 22, 2022

Report 2294 Fixed in v1.1r1, January 22, 2022 There is no bug here, but due to a lack of general community knowledge about temperature compensation this feature has cause a lot of support traffic. In v1.1r1 new airframes will begin with Temperature Compensation defaulting to off. It can be changed on the FMS Defaults pages if desired, or switched on for individual flights on the TEMP COMP page.