bpcw0001

Hi, I use the walkaround simulation using WASD keys. That works fine, until I set foot into the aircraft itself. As soon as I step onto the stairs, the screen starts randomly jittering and jerking around slightly, as if wind was constantly rattling the aircraft. As soon as I take the seat in the cockpit, or when I get outside the aircraft again, everything returns to normal. So, basically, walking around inside the Challenger without taking a seat shows this jittering view effect. Walking around *outside* of the aircraft does not show this behavior. Interestingly, the jittering immediately stops when I turn off the walk-around simulation in the Challenger's user settings. I have already tried without success: - remove all plugins except AviTab and Gizmo - use a new airframe - made sure that no controller axis or buttons are inadvertently assigned to X-Plane view/camera functions Any idea what could be the reason for this view jittering when inside the Challenger, but not when walking around the aircraft on the outside? Thanks X-Plane 12.09, Windows 11, latest nVidia driver on RTX4090

Hi, it appears that www.celestrak.com does not like the "excessive downloads" of Iridium-related data from the Hot Start CL650: Log snippet: 2024-03-30 16:51:56 CL650[gps4000s.c:2940]: WAAS data download successful 2024-03-30 16:51:59 CL650[curl_util.c:260]: Unable to download https://www.celestrak.com/NORAD/elements/iridium-NEXT.txt: server responded with HTTP error 403 (Forbidden) 2024-03-30 16:51:59 CL650[ics220a.c:573]: Failed to download Iridium-NEXT NORAD track file, will retry in 60 seconds 2024-03-30 16:52:54 CL650[waas_api.c:205]: Failed to download WAAS API data: server responded with error 400 (Bad Request) 2024-03-30 16:52:59 CL650[curl_util.c:260]: Unable to download https://www.celestrak.com/NORAD/elements/iridium-NEXT.txt: server responded with HTTP error 403 (Forbidden) 2024-03-30 16:52:59 CL650[ics220a.c:573]: Failed to download Iridium-NEXT NORAD track file, will retry in 60 seconds 2024-03-30 16:54:00 CL650[curl_util.c:260]: Unable to download https://www.celestrak.com/NORAD/elements/iridium-NEXT.txt: server responded with HTTP error 403 (Forbidden) 2024-03-30 16:54:00 CL650[ics220a.c:573]: Failed to download Iridium-NEXT NORAD track file, will retry in 60 seconds Trying to download via browser yields this: This may be a problem when trying to use Iridium Satellites with the Cl650.

ok, no problem Take your time. Always better than rushing it.

Speaking of beta, is there any ETA as to when the beta will become a new release, or is it a "it's done when it's done" thing and we just have to sit tight until then?

So they did fix it: https://forum.navigraph.com/t/x-plane-12-fms-data-issues-with-transitions/13920

I posted the issue over there at Simbrief, and my post got caught by the Spam filter for review by staff. Interesting ...

OK, thanks for the clarification. It is clear that there was some change made by Simbrief, since I've imported and flown this very route many times without issues in the past. No big deal anyway. The SIDs and STARs never came over from Simbrief on import, which I actually appreciate, since the actual SID and STAR are anyway selected on short notice manually in the FMS. However, long SIDs and STARs should be considered by Simbrief during fuel planning. So I'll do a "normal" briefing to get the fuel figures, and then create a new flight plan without the SIDs and STARs for import in the HS Challenger. Is there any chance that Simbrief fixes this to work correctly?

OK - what file exactly do you need from Simbrief? There seem to be 2 possibilities for X-Plane 12: Which one is grabbed by the HS Challenger during FPLN request in the FMS? I attached both of them. Attached also the current log. You'll find lines like these: 2023-11-11 14:21:32 CL650[fpl_ser.c:780]: Error loading FPL: line "1 LMML ADEP 297.000000 35.857542 14.477439" produced error "NOT IN DATA BASE" LMMLEGLL01.fms LMMLEGLL01_SID_STAR.fms Log.txt

Hi, it appears that after the latest Simbrief update, the Challenger cannot handle flight plan import from Simbrief any more when there are SIDs and STARs included. This used to work fine! Once I remove the SIDs and STARs from the route in Simbrief, the flight plan imports with no issues. I have always used the Simbrief "Default" flight plan layout. Was this changed? What flightplan layout am I supposed to use that the Challenger "understands"?

Wow … this was reported for X-Plane 12.05 already. We‘re now at 12.07 and no fix yet? Is there any possibility to disable the windshield icing effects? This makes the sim basically unusable during winter time.

Is there an "official" bug filed that can be tracked?

Yep, this is becoming a pretty annoying issue as weather becomes more winterly.

It is! See my posted log snippet. I've used the FMS Terminal WX functionality ever since, and it always used to return good data, until now.

Hi, requesting terminal weather for a given airport no longer works: 2023-10-20 19:30:27 CL650[cmu_subsys_comm_mgr.c:494]: DL[https://www.aviationweather.gov/adds/dataserver_current/httpparam?dataSource=metars&requestType=retrieve&format=xml&hoursBeforeNow=2&stationString=LSZH] SENT -> FAILED (code 404) 2023-10-20 19:30:29 CL650[cmu_subsys_comm_mgr.c:494]: DL[https://www.aviationweather.gov/adds/dataserver_current/httpparam?dataSource=tafs&requestType=retrieve&format=xml&hoursBeforeNow=2&stationString=LSZH] SENT -> FAILED (code 404) 2023-10-20 19:30:32 CL650[cmu_subsys_comm_mgr.c:494]: DL[https://www.aviationweather.gov/adds/dataserver_current/httpparam?dataSource=aircraftreports&requestType=retrieve&format=xml&hoursBeforeNow=3&radialDistance=35;8.55,47.46] SENT -> FAILED (code 404) 2023-10-20 19:30:34 CL650[cmu_subsys_comm_mgr.c:494]: DL[https://api.autorouter.aero/v1.0/notam?offset=0&limit=200&itemas=[%22LSZH%22]] SENT -> FAILED (code 401) It appears that the aviation weather api was changed: https://aviationweather.gov/data/api/#/ I get weather in XML format when using e. g.: https://aviationweather.gov/cgi-bin/data/dataserver.php?dataSource=metars&requestType=retrieve&format=xml&hoursBeforeNow=2&stationString=LSZH i. e. same query params, different server.

What was the solution?

My point being: a lot of simulations tend to exaggerate certain characteristics of an airframe in order to make a point. I'm not claiming this here in our case, but still, the massive trim changes required to control flaps 20 retraction/extension are hard to believe. I'd definitely like to hear more real-world Challenger pilot input on this matter.

Hi. I tried to do a FPLN wind update, but the request never came back. In the logs, I can find: 2023-10-12 20:38:28 CL650[gps4000s.c:2979]: EGNOS data download successful 2023-10-12 20:38:33 CL650[gps4000s.c:2940]: WAAS data download successful 2023-10-12 20:41:23 CL650[cmu_subsys_comm_mgr.c:494]: DL[https://rucsoundings.noaa.gov/get_soundings.cgi?start=latest&data_source=GFS&airport=51.9,0.2&] SENT -> FAILED (code 502) 2023-10-12 20:43:34 CL650[gps4000s.c:2940]: WAAS data download successful 2023-10-12 20:46:10 CL650[cmu_subsys_comm_mgr.c:494]: DL[https://rucsoundings.noaa.gov/get_soundings.cgi?start=latest&data_source=GFS&airport=51.9,0.2&] SENT -> FAILED (code 502) 2023-10-12 20:46:46 CL650[cmu_subsys_comm_mgr.c:494]: DL[https://rucsoundings.noaa.gov/get_soundings.cgi?start=latest&data_source=GFS&airport=51.9,0.2&] SENT -> FAILED (code 502) 2023-10-12 20:48:35 CL650[gps4000s.c:2940]: WAAS data download successful 2023-10-12 20:53:29 CL650[gps4000s.c:2979]: EGNOS data download successful 2023-10-12 20:53:36 CL650[gps4000s.c:2940]: WAAS data download successful Is rucsoundings.noaa.gov the culprit here? If yes, what other Challenger systems are affected by this? Is there any other way to quickly load wind data into the FMS (e. g. from Simbrief data), other than using the Simbrief wind data and type them in manually at each waypoint? For shorter routes, I can go with average winds instead, but for longer routes, this becomes more critical.

Well, good to hear. We should all get a ride in a CL650 some day and see what it is really like.

One of the issues is the very strong attitude change when retracting/extending flaps 20. Typically, when flaps 20 are retracted on takeoff, you'll need a good deal of nose-down trim applied immediately. From real-world takeoff videos, you can see that pilots do apply this node-down trim after flaps 20 retraction as well, but it doesn't look as pronounced and dramatic of a change as it is in the HS Challenger. Same goes for flap 20 extension, which makes the aircraft "balloon" quite a bit. Not sure if the real thing does that as well to this extent.

will do when it happens again This time I just restarted and didn‘t save the log away after looking into it.

Sometimes, when using the CLR/DEL and the RSK'ing on an altitude constraint on the LEGS page, the altitude value of the constraint clears, but there remains an arrow up/down, indicating the type of altitude constraint (CLIMB/DESCENT). Often when doing this, I get a CTD with the same backtrace as I've already posted here with a seemingly unconnected issue. Is it intended that on deletion of an altitude constraint, the constraint type in form of the up/down arrow remains? Should the constraint not go away including both value and type?

To my knowledge, the ATS behavior cannot be tweaked by users and there are no settings for it. Still, I've never experienced any of this, the ATS just works fine. As for going over the speed during descent and the GND spoiler thing, I need to check this. I do get the "SPEED MSG" alert though if the speed doesn't come down. However: Ever since upgrading from X-Plane 12.05 to 12.06 and 12.07, I occasionally face quite the contrary issue: the ATS reacts way too slow to keep speeds on approach, typically when going "gear down flaps 30" or later with "flaps 45" and the respective speeds set manually, the ATS sometimes (not always!) lets the speed drop way below the selected value, so I end up disconnecting the ATS and taking over the throttles (N1 target is selected, ATS displays "SPEED" mode, so no pilot error here).

OK. Thanks. I had GPS outages when I took the Challenger into the Middle East, where this is expected, so I did not consult the map, which would have taught me what the jammer depiction looks like. Consistent loss of GPS around Berlin on multiple occasions, days apart, made me misinterpret the situation. Sorry.

Hmm ... ok ...So what's that black square then? My current location? What does an active station look like on that map? Seems I got it wrong entirely?

Thanks! That's great news. What about this effect here: Is that fixed too?