Leaderboard

I've been experimenting with engine failure on takeoffs, just above V1, the so called V1 cut. So far, I have not been very successful. While I have been able to counter the initial yaw with the nosewheel on the runway, after rotation begins, there is insufficient rudder authority/effectiveness(?) to correct the yaw both in and out of ground effect. I have the flight control page up and the Developer>Show Flight Controls window open. From both indications, I am getting full rudder deflection. Yet out of ground effect, with the wings level, the slip indicator (i.e., doghouse) is about 3/4 displaced towards the operating engine, indicating more rudder is required. The good thing about HS CL650 is that you have the yaw/roll coupling inherent with sweptwing aircraft modeled very accurately. The bad thing is that because of the excellent modeling, the lack of sufficient rudder authority/effectiveness means that the aircraft at V2 is rolling off into the dead engine, making it very difficult to fly. I have much experience in how V1 cuts work, teaching them in the LJ-JET series Level C simulator for many years, as well as being type rated in the Lear 45/75, DA2000, and CL300/350. I suspect that the CL650 with its hydraulic rudder would be very close to the CL350, and at very light weights where V1 is near V1/VMCG, full rudder will be required. I have been practicing these at 35,500 lbs. V1 is 114, VR is 121, and V2 is 131. I'm taking off from KICT's runway 1R on pretty much a standard day. Yesterday, I did some heavyweight takeoffs at 45,000 lbs. hoping the rudder control, authority, effectiveness would be a little better. It was not. Although, the performance following the engine failure was pretty close to what I would expect without digging into the AFM. I am fairly new to XPlane beyond more than casual users. The quality of addons in XPlane has now made it my sim of choice. Is there any way that I can tweak the rudder on this model to see what might work better, and report back to you folks? Any suggestions would be greatly appreciated. Thanks! Rich Boll

Thanks for trying. I suspect this may be one of the crashes already fixed but it’ll be looked at regardless.

X-Plane can also “lose” the “up” event from mouse clicks so check one of the master-caution buttons isn’t stuck down in the virtual cockpit.

Check to make sure no hardware is holding down your master warning/caution reset switch!

I don't think it's you. The three way switches no longer work for me with 1.5.2, even with Google Drive files applied.

Hi, thought I’ll show the electrical panel . Still not wired but Almost there . ive decided to paint the panels all in black , think it provides a better contrast with the white backlight . I know it’s not like the original grey-ish , but hopefully I won’t regret it later requires the bolt cutouts painting ..

Hi folks, Is it me or did the 3 way switches stop working with 1.5.2?

Hello All, This will serve as a formal forum announcement that we have released the version 1.5.2 update for the CL650. All customers who have purchased the CL650 up till now have been sent an e-mail by X-Aviation with complete instructions on how to obtain your update. We have made this a very simple process! For those that purchase the CL650 from today forward, your purchased download will already be updated to version 1.5.2 for you. What if I didn't get the update e-mail? If you did not receive your update e-mail don't fret! X-Aviation has updated our system to allow all customers to update with ease, regardless of whether you received an e-mail for the update! Here's what to do: 1. Login to your X-Aviation account here: https://www.x-aviation.com/catalog/account_history.php  2. Find your original Challenger 650 download and re-download the file. It will download as the latest version! The following is a list of additions/fixes included: What's New / Changed: New Features: 2690: Add a clickspot for inspecting wing surfaces during preflight 2708: Add support for xPilot’s SELCAL datarefs 2716: Implement FANS CPDLC support 2732: Implemented DEP CLX, OCEAN CLX and ATS LOG datalink subsystems Enhancements: 2691: Redesigned the overnight icing accumulation algorithm to use real METAR data 2688: Add support for detecting POSCON client for disabling realistic altimetry feature 2698: Implement workaround for FMod sound bug when loading the airplane with sound muted 2699: Implement dataref interface for libfail to allow 3rd party software to trigger our failures 2320: User request for dataref to indicate when in “walking mode” Bugfixes: 2683: ABEAM REF distance and time isn't working correctly 2687: V-bar FD vertical deflection & rotation stacking should be reversed so the V-bar rotates around the nose indicator 2692: Reduce landing and taxi light brightness to be a bit closer to reality 2648: KEUG I16R with EUG transition is handled incorrectly for the subsequent leg intercept off the procedure turn 2409: Shrink or hide manipulators for engine fire push buttons so they can’t be clicked by mistake 2685: Manual ENG BLEED setting isn't being cross-talked between FMCs 2693: afm_mgr has a potential deadlock due to locking inversion if a state load coincides with a state save 2694: THRUST LIMIT page 2/2 shouldn't be selectable in the air 2695: Smooth FPLN leg joins should anticipate turn radius changes due to climbs 2697: CPC PID derivative rate was still causing oscillations when reloading a climb state at higher ISA around mid-20 thousands 2487: CTD - CL650[chart_prov_navigraph.c:1086]: assertion "chartdb_add_chart(arpt, chart)" failed 2721: Receiving a ATIS datalink message should show green DATALINK advisory CAS 2730: Reduce initial engine parameter variance a bit to help avoid unusually high ITT deviations 2775: Fix radial are off by a few degrees 2776: ATS posts an FMC ERR when FMS3 is selected as active on the left side 2779: Descent altitude constraints can stick past the waypoint where they are applicable 2780: Compressor stalls should stop when the engine is shut down 2773: PFD SVS rendering distance too short 2768: Changing NAV SRC while OEI causes CTD 2784: Small amount of aileron trim causes persistent monitored AP disconnects due to servo misalignment alarm firing 2769: DCT fix in FMS followed by pressing NAV causes CTD 2767: CTD when attempting to use invalid AFCS data 2749: Hold exit followed by FPL disco. clear = CTD 2785: Newly created airframe has right hand side cabin window blinds closed 2786: Engine hydraulic SOVs were being ignored when determining engine-driven pump operation 2787: Manual date setting on STATUS page results in setting incorrect year 2789: Make tail refuel pump fatter by 1mm to avoid spurious AUX TANK HEAVY CAS messages 2791: PBPB waypoint entry when first WPT SEL has 1 option and second WPT SEL has more than 1, empty WPT SEL shows instead 2792: PBPB waypoint checker should be using the passed selection lookup type, instead of defaulting to database-only 2793: WPT SEL screen should return to the caller's subpage 2777: Fix page missing Lat/Lon Cross small text 2795: FLT LOG fuel used needs to allow entering DELETE to reset the value 2796: TERM WX should allow for non-ICAO station IDs 2794: Add a checklist menu item to manually stop the FO's go-around flow 2797: is_valid_icao_code should allow for numbers in IDs 2798: Invalid ICAO code in FPLN RECALL page isn't generating an INVALID ENTRY error Enjoy these latest updates, and stay tuned to the forum as we continually announce the latest happenings.

Yep I believe most school house want *first* to emphasize to young pilots the conceptual difference between non precision approaches (2D Apps) and precision approaches, where for ages everybody did the same way, ie dive to the MDA and maintain it until the missed approach point. The schools don't want pilots to confuse between approach types and may teach [the traditional] different techniques to make the pilot behavior help differentiate APPs types. I would bet it's a pedagogical approach rather than a complete course an all the developing stories on how to fly an approach with CDFA to MDA + addendum. Then later in the airlines, and depending on SOP and budget, the CDFA may be seen as a supplementary technique to teach in order to bring commonalty of operation for all approach types, but the aware pilot still is able to discern between the various approach categories. Maybe just reassure them that you have perfectly understood the underlayin concept... and nevertheless will apply CDFA techniques. Also, in accordance with the evolution of flying techniques, private providers and State chart depictions may differ for the same approaches. Approach_minimums_LIDO_Jeppesen.pdf

I'm going to put in my two cents worth, and my procedure will differ somewhat from what the "schoolhouse" teaches. Let's talk about the easiest scenario, which is an RNAV (GPS) or RNP approach to LPV or LNAV/VNAV line of minima. The minima for these approaches are specified as a decision altitude or DA. They provide the same TERPS or PANS-OPS protection for a momentary descent below the DA as does an ILS approach. From the initial approach fix (IAF) inbound, you should have VNAV selected. You may use VVS, VFLC, or VPTH to descend the aircraft through the initial and intermediate segment step down fix altitudes, and VNAV will honor all of them. However, the easiest is to fly VPTH and let the VNAV track the vertical path through each of the stepdown fix altitudes to the final approach fix crossing altitude. You may select the APP button at any time after the final approach fix. Once selected, the Vertical Glidepath (VGP) mode will be armed (shown as a white VGP in the FMA) and will become the active mode during the in the intermediate segment sometime past the (IF) fix. There are two important things about the VGP mode: 1. It will not honor the altitude preselector set altitude. If you're not cleared for the approach, if VGP has captured, it will descend on the final past the FAF. Once VGP is annunciated in Green, you can set the missed approach altitude just like on an ILS 2. On very hot days, e.g., 40C plus, VGP may not honor intermediate segment stepdown altitudes. The reason for this is that VGP mode from the IF fix inbound uses SBAS to compute the vertical path, which is not affected by non-standard temperatures, and like an ILS glideslope will take you below the intermediate segment stepdown altitudes on a very hot day. So, on a very hot day, you might want to stay in VPTH mode until passing the last stepdown fix in the intermediate segment, then press the APP mode. You might have to use VS to vertical speed down to capture the VGP path from above. I do not know if X-Plane or Hotstart models this behavior, but this is something to watch out for in the real Collins SBAS equipped airplanes. Past the FAF, you would descend to DA in VGP mode and at DA, if the runway is not in sight, press the go-around mode and then climb out and execute the missed approach. On an approach with the LNAV/VNAV line of minima, the procedure is the same; however, VGP vertical guidance is based on Baro-VNAV. You must honor the low and high temperature limits published on the approach, but you don't have to worry about the VGP path going below the published intermediate segment stepdown altitudes. An RNAV (RNP) AR or RNP AR approach is pretty much the same thing. However, I am not sure if the Collins system uses SBAS guidance for the vertical in the final approach or if it is using just LNAV/VNAV. RNP AR approaches are a strange breed because use a "Vertical Error Budget" or VEB for vertical obstacle clearance, which was originally based on Baro-VNAV use. I actually believe it does use SBAS guidance inside the FAF/FAP, but I need to check on that. The next scenario is if you are flying an RNAV (GPS), RNP approach, or a conventional approach (VOR or NDB) using the FMS. The minimums are all based on a minimum descent altitude or MDA, which is a hard altitude that you cannot go below during the approach without the runway environment in sight. For an RNAV (GPS) or RNP approach (not RNP AR...easy to get confused since ICAO has muddled the terminology), you would fly the approach to the final approach fix (FAF) described as above except that you would remain in NAV (LNV) and VNAV (VPTH) mode. Approaching the final approach fix, you would set the altitude preselector to the MDA. In the CL300/350 PL21, when you dial the altitude preselector down by 1000' increments, it will have an increment that matches the BARO setting on the PFD. I don't know if the CL650 has the same feature, but suspect that it does. In VPTH mode, the aircraft will level at MDA that is set in the altitude preselector. However, there's a problem... If you are descending on the VNAV path in VPTH from the FAF to the runway threshold crossing height, if you level even for a moment at the MDA, you are now above path. if you suddenly see the runway, there is an urge to "go for it", and that's how runway excursions and landing overrun accidents occur. With the constant descent final approach (CDFA) concept, you never level off at MDA. Further, you add a height adjustment to the published MDA to account for the transition from CDFA or VPTH descent to the missed approach climb. In some European States, that height additive is specified by type in the AIP (e.g., France). In other States, it's left to the operator. If you have to determine one, a good rule of thumb is the USAF's 10% of the vertical speed anticipated on final, which is shown on the Jepp charts for the goundspeed expected in the final segment. For 3.0 path, that will be about 60 feet for most CAT C aircraft. A descent path more than 3 degrees may require a larger additive. If you don't apply CDFA in Europe, the approach minimums are increase by a meter equivalent of approximately 1/4 SM for CAT C and CAT D aircraft so that you will see the runway before you get to the nominal 3.0 descent path to the runway. That way, they ensure that you see the runway before the nominal 3.0 degree descent point. No such rule in the US where CDA is encouraged, but it is voluntary. Most schoolhouses teach setting the altitude preselector to MDA (with or with additive) when either on VPTH or level in ALT with VPTH armed when approaching the FAF, then using NAV (LNV) and VNAV (VPTH) to descend and level at MDA. My preference is to fly it like an RNAV (GPS) approach with LPV or LNAV/VNAV minima or an ILS approach. I set the BARO to the MDA plus the additive and then use VGP mode since I'm never going to level at the MDA+additive. When the voice says "minimums, minimums", if the runway is not in sight, it's a missed approach just like LPV, LNAV/VNAV, or ILS approach. This falls into "technique", but it does drive some instructors nuts because they want to show me the system. I want to show them how I'm going to fly the airplane! A VOR or NDB approach is similar; however, the FMS will warn you that it is a REF APPR only, meaning that from the FAF to the missed approach point (MAP), you must have a VOR needle or CDI or at the NDB/ADF needle displayed and that it must also be used for primary course guidance in the final segment. Otherwise, the procedures described above are the same. I don't know if this answered your question, but I hope it helps. Rich Boll

I hesitated to buy IXEG, because as we all know, we have ZIBO 738, FJS 732, FF 757/767, why bother to buy 733 from IXEG? Until XA has a discount of IXEG recently, combining IXEG team has a promise of a update of XP12, I bought it in. Suprisingly, it is the most VR playable Boeing aircraft, meaning it is FPS friendly enough, at least my PC can achieve +30fps in HP reverb G1 VR. someone might say ZIBO, not on my PC, it is less then 24fps, FJS is struggling with 24 as well, FF is a fps killer because of SASL. I understand non-programmers won't care too much about FPS, they just want more FPS, but they really don't care FPS. as a programmer, I understand FPS means good software architecture, it turns out only a couple of FPS, but cost brain more. so I will say IXEG is a good team, has protential to create better product

XP12 compatible IXEG update is likely to bring even better fps once FMOD sounds are in place. I've been pouring a bunch of work into Gizmo to enable multi-threaded systems too. Appreciate your kind comments. There are even better things coming in future.

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.