Bob Scott

You might want to go look at PMDG's 24 Feb 2024 update (there's a repost of it here in this forum), as it seems some PMDG 737 users have been having this same problem (plane stuck in the sky), which they've narrowed down to an issue with TCAS getting overrun with data. Might be related, or might not, but I had the same issue with the Fenix A320 some weeks ago as well.

And I'm saying that managing the VSpeed has the effect of managing the attitude. The two are not independent of one another. I know that if I select a VS of 3000 fpm or less, it will result in an acceptably moderate deck angle for a climb. And I know that if I were to set an acceptably moderate deck angle (e.g. hand-flying in a FBW acft like a Scarebus), it would result in a VSpeed of less than 3000 fpm. Either way, if I am climbing at 5000 fpm, it's gonna be accompanied by an excessive deck angle, and it will be out of the comfort zone. Both high attitude and high VSpeed are valid and complementary indications, and directly controlling either attitude or VSpeed indirectly controls the other.

If you post the edited version here, I'll do an admin edit to replace the original post for you.

Well, I fundamentally disagree...this is a semantic argument that loses sight of the forest for the trees, and disregards the practical reality of how a pilot actually manages flight parameters. There's a clear physical relationship between vertical speed and deck angle when flying normal climb or descent profile airspeeds. I don't believe there exists a fixed-wing passenger aircraft that can climb at 5000 fpm without the pointy-end aimed significantly skyward--in other words, with a high and uncomfortable deck angle. When the pilot lowers the nose (IOW reduces the deck angle) the result is a lower vertical speed. Conversely, when you climb in selected vertical speed mode and reduce the target VSpeed, the result is the nose is lowered--a lower, more comfortable deck angle. Do you propose some other means of controlling deck angle? So yes, I advocate avoiding high vertical speeds during climbs and descents where possible in the interest of pax comfort, because there absolutely *is* a connection between vertical speed and deck angle, and by extension pax comfort.

The 6 degree-of-freedom motion systems in high-end simulators take advantage of the human somatosensory system to, in essence, "trick" the body into an artificial sense of fore/aft acceleration by tilting the motion platform to change the direction of the 1g gravitational vector. People notice and in fact do sense what their bodies interpret as vertical speed when an aircraft climbs or descends, not because the acceleration changes, but because the direction of that 1g gravitational vector is not straight down through their butts when seated. Hence the age-old flying term "seat of the pants"... Many people don't find large deck angles comfortable. Even if it isn't uncomfortable, to most it still does not feel natural. Since (usually) a high rate of climb or descent in a fixed-wing aircraft is accompanied by a significant deck angle (pitch), a pilot trying to maximize comfort will try to avoid high deck angles (up or down) when not necessitated by safety or operational considerations--and that means limiting vertical speed in a climb/descent when possible, as well as managing configuration/speed to accomplish the same outcome.

Ausgezeichnet!

"Safety-Comfort-Reliability"...SAMFOX, baby!! 😉

In my r/w Gulfstream flying, when departing with a light jet, after clearing any obstacles and at/above altitude restrictions I'd fly the climb in VS mode at 3000 fpm until the power required to hold that rate was close to the FMS computed climb power, and then switch to VNAV for the rest of the climb. It's not just about cabin pressurization--at light weights, climb rates at full climb power could be 5000 fpm or more, which results in an uncomfortably high deck angle. The Gulfstream V could carry enough fuel for a 12-hour leg, but most of my flights were far shorter, so really lightweight departures were common. I suspect it's less often an issue with airliners, as they tend to fly pretty full of pax these days, but something like a short leg in a 777 with a super light fuel load for a 1-2 hour leg (Air France used to fly Santiago Chile to Buenos Aires enroute to Paris as one real-world example) would pose the same considerations.

It was a 6.5 hour flight reduced to ~1.5 hrs in real time using Quantum Leap. I wouldn't consider a single CTD a trend--I also had trouble with a couple CTDs this morning and when I finally got it started up there was a new update waiting, so I'm wondering if maybe we got caught in the database changeover on the servers (?)

With this 1.07 update, we now have the ability to change the fuel load inflight, which makes abbreviated flights using a skip-ahead repositioning tool like Quantum Leap or the DevMode teleport tool possible. I just did a 6.5 hr flight from Amsterdam to Doha...took off heavy, flew the SID up to cruise, then used Quantum Leap to reposition the jet to a forward waypoint ~200nm short of Doha, reset the fuel load and flew the descent, arrival and landing. FedEx from Memphis to Anchorage this afternoon... It'd be nice if they'd fix the fuel burn and autopilot stability issues in accelerated flight, but with repositioning now in play, this bird is a good fit for long haul legs without having to endure hours and hours of droning at cruise.

Could be a wonky set of PID parameters for the autopilot, or an inherently unstable flight model, or a combination of the two. It can also be caused by a CG that's too far aft (too close to the CL). You might try loading the plane with a more forward CG and see if that stabilizes things.

There's the free Milviz Piaggio P-180, which is a fast turboprop with performance at-par with a VLJ and the same well-done (and complex) Collins Proline 21 avionics suite as in their B350i King Air. Flight1 has a Cessna 510 Mustang port-over that has a patch to make it compatible with P3Dv5. My personal go-to in P3Dv5 is the PMDG BBJ...its wingspan is only 14 ft wider than a Gulfstream 700/800, and with the extended range tanks it has 6500nm legs. When flying it on short legs with a typical light bizjet payload it's quite the rocket.

Well, the "pressure" has been on Asobo for going on two years now to fix the ground texture tile swapping bug that makes using DX12 (especially with some of the better add-on airports) a pretty underwhelming proposition...and DX12 is required if you want to use FG. Without a fix to that problem, FSR strikes me as a pretty pointless endeavor.

I agree. Knock it off and get back to the topic, please.

You set DistanceToNotAnimate on which object(s)? That parameter is set in the sim.cfg for individual objects. And also, increasing the value means the object is animated when much further away, which, if it has any effect on performance at all, would tend to diminish performance rather than improve it. Sounds like it might be related to the traffic that's being generated. Have you tried killing the traffic in the FSTraffic GUI to see if your frame rate comes back up?

Back to the topic please. If you want to run on about War Thunder et al, start a new thread in Hangar Chat, this forum isn't the place.

The visibility reported in a METAR is the prevailing visibility, defined as the minimum viewable distance over at least one-half (180 deg) of the horizon. So it's entirely legit to have a situation where 9km PV might give you 9km looking one direction, yet much less in another. If RVR or RVV are reported, they reflect the measured visibility at the approach end of the runway looking down the runway (RVR) or at some point other than the approach end (RVV). A typical morning fog situation on an eastbound runway 09 (looking into the sun) might be 3SM R09/1200FT, which means 3 miles visibility over at least half the horizontal plane, but only 1200 ft when looking down runway 09 from the approach end. If you're flying a Cat I ILS with a typical 200 ft HAT in that weather, you're probably gonna end up going missed approach, since you need more like 2400ft vis to see the runway at DH. Also keep in mind that the METAR might be up to an hour or more more old...visibility can and often does change quickly, which is why ATIS/ASOS or ATC reports are used for operations and METARs for planning.

I've been building with 32GB in my flight sim system configurations for at least six years now, and have yet to find myself wanting for more.

Hardware--PFC Jetline yoke, throttle quadrant, and pedals (serial I/O version) which I first acquired in 2002 and later retrofitted with Hall sensors and USB interfaces in 2012. Software--Radar Contact, since 2003 thanks to the rock that is the FSUIPC interface, in use since 1999.

The four levers span 6.5" across. It's slightly awkward--but then again, the real-world throttles in the C-141 transports I used to fly were a handful, too. There's a bit of a challenge getting all four into reverse--I typically bring the two center engines into reverse idle together, then #1 and #4 one at a time, then bring everything back to full reverse.

You mean like this?

Not sure I understand your question about expansions. The TCA Airbus throttle has a small plate on the bottom that you remove (two screws) and turn around to disable the Airbus detents, making the lever travel continuous without detents, except for the reverse idle stop, which allows you have a true variable reverse axis with paddles on the levers that you pull up to allow you to go past the reverse idle stop into the reverse range. That's a much better solution than the all-on or off reverser switches on the Bravo and the TCA Boeing quadrants. You can also lock the reverse idle stop paddles up by pulling them up and turning a small knob on the side of each lever, which gives full range of travel on the throttle axes without any detents at all. The speedbrake/flap "sidecar" extensions work with other acft, although the flap control has 5 detented positions. I wrote a Lua script that runs in FSUIPC to make the flap lever work something like my PFC unit does with Boeings and other acft with more than 5 flap lever positions...when I move the lever from the center position up one detent and back to center, it raises the flaps one increment, when I move the lever down one position and back to center it lowers the flaps one position. If I move the lever to full up or full down positions, I get flaps full up or full down. Using an axis variable to control flaps is hit or miss proposition, and flat does not work on a number of add-ons. And that said, I don't know of any consumer-grade quadrant that does 7 or 8 detent flap control like you'd need to replicate a Boeing flap handle.

Well...it's $300 vs $120 for the TCA quadrant. Sadly, Honeycomb's offices are reportedly vacant/boarded up and future support looks unlikely, warranty or otherwise, and from reading the mail over the last few years, a significant number of folks in the community have indeed found themselves needing that support for bad switches, bad pots and other issues that don't exactly scream "much better build quality". So maybe it really isn't the "Best Throttle Available" when taking into consideration the real possibility of ending up with a broken and unrepairable unit. I have a good friend here locally with the Bravo throttle unit, and he's had absolute fits with the driver software ever since the day he got it. As long as there was decent support behind the product, I think the Bravo was a reasonable risk. But with the history of reliability issues and without support going forward...well, that's another story. Caveat Emptor--let the buyer beware. So the lighter and more inexpensive Thrustmaster is a lower-cost but less mechanically robust alternative to taking that risk. Another alternative is the PFC throttle quadrant, which is even sturdier and better built than the Honeycomb, and customizable via both software and hardware with swappable lever configurations. But then they start at over $800.

I would not personally buy a $300 hardware product from a manufacturer that by most accounts is circling the drain, unless you're comfortable with sourcing your own parts and doing your own repair work. As an alternative, I rather like the Thrustmaster TCA Airbus throttle quads as an option--they're certainly not as sturdy as the Bravo, but then they cost less than half as much, use Hall Sensors, and have a good workable on-axis reverse thrust capability. You can use the Airbus-style throttle detents, or quickly remove them with a screwdriver and two minutes of work for detent-free axis inputs on Boeings and other acft. The TCA Airbus quads use reasonably thick plastic levers, and have a light but precise touch. I take one with me on the road with my portable rig, and haven't had any issues with damage. As long as you're not manhandling them or throwing them around, I think they're well-fit for purpose. The Thrustmaster Boeing throttles, on the other hand, are on the flimsy side mechanically and (ick!) use on/off switches for reverse thrust rather than the reverse detent stops and variable reverser axis inputs you get with the Airbus version.

It looks to me like your main thread is running on core 5 rather than core 6, and I have no idea why core 4 would be loaded up like it is--the Concorde dll, perhaps? Is this behavior reproducible? Is there anything else running in the background when you see this kind of CPU utilization? The only time I've seen weirdness like this is if I disturb P3D's processor affinity with an external utility like the task manager or Process Lasso, at which point the OS then does what it wants with thread allocation without further regard to P3D's internal affinity settings. I find myself wondering if the Concorde add-on is manipulating thread affinities, and in so doing is negating the affinities set by P3D.