Graeme_77

It is an OpenGPWS issue. I bought the TEGB update when it was released, but to my shame didn't try the Challenger in it for a few days. Once I'd noticed the crash the Challenger/OpenGPWS developer worked quickly to identify the issue. It has now been corrected, and the updated code is available now. I've messaged Coop directly with those details too. Some addons like the G500 use OpenGPWS code internally so will need to be recompiled and an update issued. Other addons, typically aircraft built with lua scripting engines, use a plugin version of OpenGPWS. The plugin version is very nearly ready for those cases too.

I totally understand your rant, and agree troubleshooting can be very frustrating. I've occasionally found similar annoyances in X-Plane and sometimes it's easy to run out of energy and motivation to continue to troubleshoot. Rest assured it's as frustrating for the developers and publishers because they really do take a lot of pride in the product and seeing customers have a negative experience is very frustrating for everybody. From some very brief discussions there's a working theory that the issue could be related to antivirus software interacting badly with the simulation. I've seen various reports of this with other aircraft in X-Plane over the years, and there's a good possibility this could be the case for you. If you ever find yourself wanting to try X-Plane and the Challenger again then temporarily disabling your antivirus would be a good place to start for troubleshooting. You can start X-Plane when online, make sure the licence is up-to-date for the Challenger and then restart X-Plane when offline if that would make you feel happier without antivirus. If this does allow the Challenger to operate then we could continue to problem solve from there, but no pressure - as I said I understand how frustrating it can be to spend sim time on troubleshooting. If you are keen to explore the troubleshooting further, the Hot Start Discord is probably the easiest medium for this is it's slightly more interactive. Don't hesitate to tag me on there if/when you get back to it - one of the developers, moderators or the community will be there to try and help you.

This appears to be an X-Plane bug relating to ESP on the Garmin AP. You can also see it "blip" the elevator if you click AP disconnect even with the AP already off. I've reported the issue so hopefully a fix is possible. In the meantime, the workaround is opening the aircraft in PlaneMaker, go to Expert, Autopilot Configuration and deselect "ESP and USP equipped". Best to make a backup of the ACF beforehand. You'll also benefit from avoiding an odd "saw tooth" feeling to the landing flare - don't know what ESP is doing there but it seems to nudge the nose up or down during the flare. I believe this needs Laminar Research to fix.

The issue with these old systems is getting the vertical signal in to the HSI and the AP. The course deviation can be output to the HSI provided the system was designed with an external resolver. (The resolver takes the VOR signal and compares with the OBS setting to generate the course bar deflection - an external resolver system allows a NAV/GPS to feed course bar information directly and to process the OBS selection within the radio - i.e. the resolving happens inside the radio for VOR so a "pure" course bar defection is sent to the HSI) In some cases, similarly, the GPS itself can generate analog GS output signals even when performing LPV or LNAV+V approaches. Given the analog nature of the Mu2 instruments I'd be fairly happy to see the LPV glideslope presented on the avionics when in LPV or LNAV+V. I'm sure a competent avionics shop could make this work, either directly or with some electronic magic. The real thing would probably end up with a flight manual limitation specifying lateral AP coupling only, but it's probably technically capable of making it work anyway. Some avionics setups make it harder and so make use of what's called an LPV Converter. This reads the GPS digital output parameters for the LPV approach and converts them into digital LOC and GS parameters which the avionics ILS display understands and can feed AP inputs. This allows older systems to fly LPV approaches by basically tricking the avionics into thinking they have a real ILS signal. There's a changeover button on the panel somewhere to swap between LPV and ILS. Conceptually, it's like the roll steering button that's used to give GPS steering on the heading bug input, although the implementation is different. GNS Install manual extract - note the analog limit - Garmin could prove their analog outputs wouldn't cause any harm and could be trusted to be standards compliant just like any other VOR/LOC/GS, but if the random old airplane autopilot listens to the digital data who knows what crazy stuff could happen.

Can't wait to have the 733 refreshed and back in action - it was my introduction to X-Plane and made a great first impression. I did my multi crew and jet orientation on a 737 Classic sim, and the IXEG brought back all those memories - even with XP10 visuals it was way better than the actual sim ;-) When you launched back in 2016 I was amazed at how well the sim captured that 737 experience. I can understand doing the XP12 compatibility first then moving to the FMS work later, and hope it comes together easily for you. Perhaps if the FMS is being reworked it would be good to move to the now standard Laminar navdata rather than using a custom set? I know this dataset didn't exist when the IXEG project started, but perhaps some of the edge cases in the nav code would be better handled with this format?

I've been flying some Instrument Rating test profiles, and have noticed the RMI card is not properly animated. The numbers, arrowed in dashed blue, do rotate as expected. The index, arrowed in solid red does not ever move and as a result makes radio nav instrument flying much more like using an old fixed card ADF. The index should rotate with the numbers, with the outer cardinal arrows remaining fixed in a similar manner to the HSI. Compare witht the stock LR King Air, which has a similar instrument. Furthermore, when tracking away from an NDB, the needle will do a full sweep from -179 degrees (relative to heading) to +179 degrees swinging all the way around the scale. This is stock LR instrument behaviour, but not correct and really should just smoothly move the few degrees from "behind on the left" to "behind on the right". Perhaps this could be solved by decoupling the instruments from the stock LR datarefs and implementing custom logic? Or perhaps you can persuade LR to fix this misbehaviour? Both issues shown in a very short video - you can see at the end that tracking away from a beacon will become pretty frustrating. https://streamable.com/bi0py9

Hello Mu pilots, I've noticed what appears to be an error in the fuel transfer logic. I've been testing engine out cases, and with the right engine shut down fuel from the right tip tank cannot be transferred. The Fuel System diagram in the P.O.M. shows the tanks pressurised by the same common source, not dependant on the on-side engine, so even engine out I believe the tip tanks should both continue to transfer to the main. A secondary issue as a result of this is apparently incorrect logic in the outer to main transfer logic. The manual reads as if the system should not allow either outer tank to transfer to the main until both tips are empty, but as implemented when the left tip is empty the left outer will begin transferring, even with fuel left in the right tip. Not major issues, but perhaps something to be reviewed for a future update? The system will correctly empty both outer tanks as expected when selecting the transfer switches to off and outer manual switch on, but at the moment fuel in the tip on the side of the dead engine is unusable.

Here's the issue in two screenshots. First one has L and R pressed in, but still show closed as no bleed pressure. The APU LCV is closed despite being pressed in, because it prioritises engine bleed. Second pic shows the L and R pressed out. This allows the APU LCV to open, providing pressure to open the ISOL valve and everything is good for starting. Incidentally watch the closed lights on L and R disappear as you press the start switch and they open automatically to allow starting.

OK, so this is a complex one to explain. 10th stage is air conditioning and engine starting, 14th stage is anti ice. 10th stage is what we're interested in here. The valves are pneumatically driven, that is to say they run on bleed air pressure. No bleed, the valves close. The 10th stage system is designed to prefer engine bleed over APU bleed. What I think you've done is select L and R buttons to the IN position, but there's no bleed air so the valves remain closed. But then you've tried switching APU LCV and ISOL on by pressing in, and it doesn't work because the system is trying to command engine bleed rather than APU bleed. This is because you've got 10th stage L and R pressed in with no actual bleed air pressure. Switch those out and the APU LCV and ISOL will open. See item 30 on the cockpit preparation Expanded Procedures, or use the hint images in the sim.

I understand. I use the X-Touch midi controller and XMidiCtl as the plugin, and with that combination of hardware the altitude dial works to my satisfaction. The acceleration should work correctly with hardware.

Sorry for the late response. If are were no external factors 200->180 on base leg. 180->160 on glideslope intercept and 160->vref+5 at no later than 2000ft above the airport. You can obviously go closer in should it be needed, busy airports in Europe can request 160 to 4nm, which is possible in the Challenger. Also have a look at the included Operations Reference Manual, which has a diagram of this exact thing.

Sorry this message seemed to slip through the net. There's no reason I can see for the hardware position (red flashing outline on the thrust lever overlay) to move - the CL650 does not control that in any way as it simply reflects the position of the hardware input supplied by X-Plane. Edit: The issue is caused by using the stock binding for Autopilot auto-throttle speed toggle. You can clear the issue with the binding Autopilot auto-throttle all modes off. I will submit an enhancement request to fix this behaviour.

Hello Marcus, Phew that's quite a bit to answer in one post. Let me try and cover it. 1) ILS approaches. Let me describe the normal method, assuming you have a FMS flight plan with an ILS approach and you've checked the lateral coding to make sure it all works. You don't need to set anything up specifically for the ILS. Loading the ILS approach should be enough. Make sure the left PFD is navigating with FMS1 and the right side is FMS2. You will have a magenta CDI indication. When you are close to the airport you'll also see blue "ghost" indications on the HSI and blue diamonds in the localiser and glideslope scales on the PFD. Typically when the final approach point is the next waypoint, press the APPR button and this will arm the system for localiser and glideslope capture. You don't need to mess with the altitude knob as long as the aircraft is actually at the ILS platform altitude (you shouldn't need to do this with a 737NG either, but that's another story). When you capture the glideslope, set the altitude for the missed approach altitude. 2) Speeds. Manual control of speeds is normal using the speed knob or manual thrust. If you have VNAV enabled you can resume the VNAV speeds using the PERF page on the FMS, but really that's a bit pointless and it's easier to fly it on the speed knob. You need to know 250 kts, 200 clean, 180 with the first stage of flaps and 160 with gear and the second stage of flaps. Select the final stage of flaps and slow to vref + 5. It's no more complex than that. Even on an Airbus with managed speeds, lots of pilots prefer selected speed modes - LNAV/VNAV and chill is very much a sim-ism and not how aircraft are actually operated. 3) It's just a machine, so isn't very likely to "freak out" as you say ;-) Bearing pointers have no influence on flying the approach, they are for the pilots reference only. I'd suggest reading (1) above carefully, then pick a long ILS approach, and post some screenshots of the aircraft level at the platform prior to intercept, and another couple of pics on the approach. Suggest EDDF 25L via CHA VOR - grab a screenshot flying level at 4000ft between CHA and LEDKI, and another on the ILS at 3000ft, and another at 1500ft - make sure we can see the full PFD clearly.

It does sound like the packs were either not operational, or not supplied with bleed air. The checklist procedures supplied with the aircraft, and carried out by the simulated First Officer should leave the aircraft in a sensible state, so if this happens again please post a screenshot of the overhead pane and "Study - Engines - Bleed System" window and "Study - Environmental - Cabin Pressurization Control" window. Thanks

The aircraft has "acceleration" on the knobs which is also in the simulation - effectively the faster you spin the knobs the bigger the steps are. This was changed in one of the later versions, so hopefully the behaviour is now better for hardware users. The model is not likely to be modified to support a 1000/100 mode of operation, as it's not how the real aircraft is built.

That same table is included in the product documentation (CL650 Operations Reference.pdf), but thanks for the post - always helps to raise awareness of the pitch power tables and manoeuvring speeds.

The hint images can be controlled from the User Settings screen.

Also worth remembering that the sync function won't operate with the flight directors in takeoff mode (TO / TO). Engage heading or nav, then the vertical mode will revert to PTCH and then you can hold sync.

Not something we're going to be discussing here. If your "friend" sent you a copy of the aircraft then they too are a software pirate. This is both illegal and deeply insulting not only to the developers who have spent years of their life developing this project, but also to everybody else on the forum who spent their own, hard and honestly earned cash on this product. I'm locking this thread to protect ClearForTakeoff from the impeding community fallout, as that sort of thing does no good for a community forum. I'll also add the strong recommendation that they, and their friend, consider how they value simulation products and the community, and consider the fact you are, in no uncertain terms, stealing from a small, dedicated group of developers that have done nothing but good for the wider sim community.

Issue solved, fix will be in next version."I've added a delay at boot before icing is applied. That should hopefully give enough time to any weather injector to come alive. I've also implemented historical METAR reading for the nearest station, which will give accurate temps and weather evolution. This mechanism is used if we detect that real weather has been configured by the user (either using X-Plane's weather, ASXP, xEnviro or XP-NOAA)."

Issue solved, fix will be in next version. "I've added a delay at boot before icing is applied. That should hopefully give enough time to any weather injector to come alive. I've also implemented historical METAR reading for the nearest station, which will give accurate temps and weather evolution. This mechanism is used if we detect that real weather has been configured by the user (either using X-Plane's weather, ASXP, xEnviro or XP-NOAA)."

Also worth checking you don't have any control axis accidentally bound to Tiller. IIRC when there is a tiller control bound X-Plane will limit the steering available with rudder. With no tiller the rudder can provide the full steering range which sounds like what you need.

Issue solved, will be in next release version. "Navigraph has a duplicate chart at RJSS, which is what was causing this. Put in a workaround to handle this case."

Report 2292 Fixed in v1.1r1, January 22, 2022 Sorry - Late thread update.