intelfx

Is it described in maintenance documentation or something else that I don't have access to? The FMS Operator's Guide only says this:

Since a week or so ago, VATSIM rules were changed to allow more than one ATIS station to be manned by a single controller. Some are using this new rule to provide separate departure and arrival ATISes, using position callsigns <facility>_D_ATIS and <facility>_A_ATIS. They do not seem to be picked up by Challenger's datalink implementation. The feature request is to support these new callsigns in the Challenger's VATSIM ATIS datalink implementation and wire them up to the "SERVICE TYPE" selector on the "ATIS RQ" screen. Note that VATSIM controllers are not required to provide multiple ATISes, even at the facilities which have separate departure/arrival D-ATIS IRL, so it probably should support both position names transparently.

If you arm NAV and VNAV and subsequently give speed control to FMC (magenta speed bug) while on the ground, OR in the air if the magenta speed bug is limited by Vfe, then doing any of the following: turning the HDG preselector turning the ALT preselector taking off ...disengages VNAV speed control and reverts the speed bug to blue.

Just wanted to make sure it's logged.

The cabin lights switch ("CABIN" in the "MISC LTS" group) on the the overhead panel is nonfunctional:

(cross-posting from a duplicate topic) Seeing as this has not been fixed so far, I made a workaround in form of a modified checklists.xml where all F/O actions are converted to appropriate F/O checks: https://github.com/intelfx/hotstart-cl650-checklists/tree/auto-fo When these modified checklists are used, F/O will not act on its own, but watch your actions and advance checklists as you do them.

Seeing as this has not been fixed so far, I've made a workaround in form of a modified checklists.xml where all F/O actions are converted to appropriate F/O checks: https://github.com/intelfx/hotstart-cl650-checklists/tree/auto-fo When these modified checklists are used, F/O will not act on its own, but watch your actions and advance checklists as you perform them.

X-Plane reliably experiences a CTD after 30 seconds or so after reloading a specific saved state (latest for airframe 492ee3fe798e08542851f8ce in the attached archive). In case it's relevant for some reason, freeware KBTV scenery from x-plane.org forums was installed. Note: I trimmed irrelevant state saves from the airframe archive because the archive could not be uploaded otherwise; I did not adjust airframes.db accordingly. Log.txt airframes.zip

Raw reproduction steps (by memory; I'll refine it further once I land): KJFK-CYYZ via GAYEL V374 CFB V270 ULW DCT WOZEE DCT VERKO, uplink from simbrief, activate sec copy to sec, sec legs, delete all down from GAYEL sec fpln, insert Q818 WOZEE activate sec load JFK5 dep, LINNG5 arr (no trans, do not delete discon between WOZEE and LINNG) fly, on departure do a direct GAYEL, at ~20000 ft do a direct WOZEE Log.txt

I'd like to clarify, is this condition persisted in the auto-saved airframe state? When I experience a CTD flying online and then restart the simulator and reload the latest auto-save, the altitude jumps a significant amount suggesting that the CL650 "forgets" that it was connected to online networks earlier in this flight.

Yes, in fact I can reconfigure the hardware to emit "level-triggered" events but I'd prefer not to do that because it would mean I'll have to reflash the HOTAS every time I'm going to fly a different airplane or play a different game.

Currently, the CL650 has just one command to operate the parking brake (CL650/pedestal/park_brake). It would be very helpful for HOTAS owners if there could be separate commands to set and release the parking brakes, which then could be bound to separate positions of a hardware parking brake lever.

Given the FO configuration demonstrated in the attached file, when flying, the FO will automatically read, confirm and advance multiple checklist items in a row, despite actually performing no actions.

It would seem that the automatic FO keeps its own track of the current checklist/item and does not pay attention to the checklist and item that's currently selected on the MFD. If a wrong checklist is started or the current checklist/item is advanced by mistake, even if you re-select the correct checklist/item on the MFD, the FO will continue to track its own position in the checklists and not what is being shown on the MFD right now. Even if it's not a bug, it's unintuitive/unrealistic behavior because I'd expect my co-pilot to actually read stuff from the MFD, instead of going "hey, last item that I read was on the engine shutdown page, so I should insta-switch there and continue reading from that position despite my Captain's inputs".

For anyone else victim to the games that Russia is apparently playing with DNS infrastructure on a national level, you can try adding an override for navcen.uscg.gov into your hosts file (/etc/hosts on Linux, C:\WINDOWS\System32\drivers\etc\hosts on Windows): 206.65.196.29 navcen.uscg.gov (At least in this country, it would seem that the host itself is not being blocked, just the DNS entry is being filtered.)

Understand that a proper/matching CSL for CL650 (CL60 code) is planned, but very low on the list. In the meantime, does anyone has an idea which publicly available CSL model of a similar jet can be used as an interim solution?

Isn't it supposed to be in public domain, like all other data released by the US government?

Yes, it is connected to the Internet. And indeed, that seems to be the problem: 2022-01-08 08:49:57 CL650[alm.c:151]: Unable to download GPS almanac from https://navcen.uscg.gov/?pageName=currentAlmanac&format=sem: Couldn't resolve host name

After completing the flight compartment checklist, the GPS subsystem appears to be stuck in a weird state with debug screens not working and nothing apparently happening.

Well, what they said. Thanks.

Yes, of course, I've double checked that the built-in failures were all disabled (i. e. "always working"). So, I just flew the same route (that I unsuccessfully tried to fly twice yesterday) without time acceleration and the problem did not occur. This is far from hard evidence but it supports the theory. So, is it a bug? IOWs, should I expect this to be fixed someday or should I just view this as an inherent limitation and refrain from using time acceleration?

I'm sorry for necroposting, but I have just reproduced this exact bug, can confirm and also provide a possible explanation. It happens when UI scale is not set to 100% (which explains the reproducibility — @robder likely has a high-DPI Retina screen which probably necessitates the use of UI scaling). Any chance this could be fixed (along with other bugs that manifest when UI scaling is used)?

(Okay, now I'm embarrassed about the amount of topics I created in recent days, but this one is a serious question.) In recent days, I made four simulated flights with TBM900 (not counting various experiments and training — that is, long flights). During all four of these, the TBM900 broke in (almost) the same way. Three times (#1, #2 and #4), the engine suddenly caught fire and the crash bar dropped without any intervention on my part. One time (#3), ITT suddenly spiked to 1000°C and continued to raise extremely rapidly through 2500°C, at which point I pulled fuel and ITT started to drop, but unlike the above case, the plane did not lose electric power. In all cases, post-landing inspection revealed broken turbines and combustor. I'm not sure what could cause this. I tried to operate the plane according to the checklists found in the FMS and supplementary information found in the real-world TBM900 manual. All of these times the plane was in level flight with engine set up for long range cruise. After the third crash, I surmised this could happen because I operated the plane without inertial separator (and the checklists are vague about whether I should keep it or not after takeoff and climb). However, last time I flew with inertial separator on and the plane has just crashed again. The only other nontrivial thing in common between the four crashes is that I used time acceleration, and the plane crashed when it was on. Any ideas? I'm attaching the logs and airframe state files from the last two failures. The "crash 3" dump was taken a short while after the crash, when I already stabilized the plane for emergency descent and landing. The "crash 4" dump was taken almost immediately (within 1 second) of the autopilot disengage warning sound, with simulator paused. Please advise if I can provide any other relevant logs or data. TBM900 spontaneous failure.zip

Ah, now it's clear. Thanks.

Hmm, so I flew with this cabin in "deathtrap" condition up to 30000 ft, and it did pressurize okay. Is it going to slowly leak air or something?