Pils

I tried this approach in the V1.8 beta (highly recommended!), and was not able to replicate a NO APPR condition using standard procedures. There may be an inconsistency with the earlier implementation of the terminal area approach logic. However, a couple of tips when using Collins Pro Line avionics that are different from Boeing or Airbus: When performing an ILS (or LOC) approach, coming from FMS navigation, it is advised not to arm approach (APPR) before being inbound to the glideslope intercept point (or FAF when on a LOC approach), and established on the final approach course. In the case of ILS Z 08 at BUR, that's the point roughly 2nm before BUDDE (or BUDDE itself for LOC). One can arrive at this point using LNAV/VPATH (or VVS if desired). This is especially important at some airports with multiple step-downs on the intermediate approach segment, and there's an outside air temperature that can cause altimetry errors sufficient for the glideslope to be below these constraints. If on vectors from ATC (or self-vectoring) using heading select (HDG), then one should limit one's intercept angle to the localizer to ~30 degrees, and not to arm approach when too far laterally from the localizer as otherwise a false beam capture may occur. Hope that helps.

Did any of these apply? APPR button is pressed before the FMS has completed the NAV-to-NAV set up. The navigation radio does not tune to the required frequency. FMS is deselected and then re-selected as the navigation source after the Nav-to-Nav set up has completed and Approach mode has been selected. The approach is selected into the flight plan in the terminal area when the Approach mode is active, FMS is not the navigation source, and FMS is re-selected as the navigation source. Are you on the Hot Start Discord? In future it may be easier to troubleshoot these issues in "real time" with the community.

See the GA roll mode in the FMAs? That tells me you've accidently pressed TO/GA and put the plane into Go-Around Mode. In which case the FD is commanding wings level.

Unless it’s at https://www.smartcockpit.com/my-aircraft/bombardier-challenger-604/ I’m not aware of it.

Terminal weather (as provided by the US Aviation Weather Center) is no longer available in V1.7 (the current shipping stable release) due to upstream data service changes.

This is the flight path vector. This is the guidance cue, the HUD's equivalent of the single-cue flight director. The idea is to put the small circle into the big one. This is the radio altimeter readout.

Negative. It’s there to stay.

We agree!

Oh I think the button label changes depending on if the plane was moving, or stopped not near a runway, when the state was saved? Not 100% the logic there, but that's not what I meant. Maybe that's what reality shows though. Or some other combination of circumstances. Hopefully the dev reads this thread eventually.

Shouldn’t matter as long as you press the FLY button and the airframe is loaded. But maybe there’s bugs. Regardless having multiple airframes in the list may be necessary for full functionality.

Maybe it doesn't recognize that airframe as loaded (you'd normally see #Loaded next to it in the list on the left)? Try loading a second airframe and go back to this one?

Untested, but might help: https://github.com/pilsnerish/FlyWithLua-Scripts/blob/main/CL650_ap_eng.lua

Nothing I can share right now.

It's modelled after this hardware interface so have a look there for hints: https://avioniquesimulation.com/dcp-ccp-panel/

@fcAero38 It's untested, but give this a try: https://github.com/pilsnerish/FlyWithLua-Scripts/blob/main/CL650_ap_eng.lua

Yes, the NOAA interface does appear to be working again. But I think this "un-solved" zombie state might have to stay for now.

A demo is available to test this, for what it's worth.

It's possible I misunderstood the motivation behind this design decision for this particular button, however we are talking a matter of milliseconds in the sim so it wouldn't necessarily correspond to irl physical input. I'm hopeful that Mobiflight will improve their integration in the future, most other tools figured this out and provide their own X-Plane plugin for full access to the sim. No promises, but I might be able to come up with this if I get permission from Avionique.

Sadly, the issue at NOAA has returned.

There are several buttons in the real aircraft that need to be helm down to activate, I assume as a safety measure, and these are replicated in the simulation. Personally I wouldn’t touch this software, it’s a hack and known to cause issues in XP. I don’t know those other tools. The developer of other fine CL650 hardware had a similar issue with their DCP/CCP, and was able to work around it with this script https://www.avioniquesimulation.com/wp-content/uploads/products/DCP_CCP/DCP-CCP_panel_lua_script.zip, you can look at it for inspiration.

Its very simple, as I’ve explained elsewhere, the “AP engage” command must be held “active” for multiple frames, however MobiFlight is incapable of doing this as long as it uses X-Plane’s UDP interface.

From the dev: So, I'm afraid the XP11 just flat out broke because of that bad GFS data and there's no trivial workaround. The only way is to use the XP12 version. The XP11 version always pokes at the GFS data and NOAA is returning some bunk that's crashing the plane. You will need to use XP12 until either NOAA fix their data service, or we get a new beta build out with a fix.

This error specifically is a bug in XP’s flight model. You’ll need to report to Laminar. Please post Log.txt from XP regardless.