Jump to content
Sign in to follow this  
Noel

What makes Fenix the better A32 over FBW...or is it?

Recommended Posts

45 minutes ago, Noel said:

Anyone know how to turn down the volume of the cabin announcements?  I don't see it in Settings > Audio on the Flybag

If you're in the flight deck just shut the door. 😄


MSI Pro Z690-A DDR4 | i5 13600KF | G.Skill Ripjaws V 32GB 3600MHz | ASUS TUF RTX 3080 (12GB) | Samsung 980 M.2 NVMe 500GB | Samsung 980 M.2 NVMe 1TB | Samsung 850EVO 500GB | 2TB Seagate HDD | Deepcool AK500 CPU Cooler | Thrustmaster T16000M HOTAS | CH Yoke | Win 11 22H2 build | MSFS2020 |

Tony K.
 

Share this post


Link to post
Share on other sites
51 minutes ago, Noel said:

All I knew about these fields were that they had to do with Decision Height, and I've always defaulted to 200' in decades of doing this as I never wanted to get into charts.  What does "DA" stand for?  Is that Decision Altitude?  How does "Baro" come into play?  I think only of barometric pressur.   RA I believe refers to Radio Altimeter to assess elevation above ground and that the RA is somewhere around in the beginning of the runway threshold is what I recall reading.

Yes, DA is Decision Altitude.

What does "baro" have to do with this? An altimeter is really just a barometer (a device for measuring air pressure) with a funny scale. This is why the Airbus labels the field in which it wants you to input altitudes as "BARO". This can be either the Minimum Descent Altitude (MDA) for non-precision approaches or Decision Altitude (DA) for precision approaches.

The other option is "RA" which, as you've correctly deduced, stands for Radar Altimeter. This is where you would enter a Decision Height if it applies to your situation.

Note that only CAT II and III minima use a Decision Height. Unless the visibility or ceilings are very low, you'd more typically use CAT I minima on an ILS. These use a Decision Altitude, not a Decision Height. Typically, the Decision Altitude is 200 feet above the touchdown zone elevation, but whatever it is, it should be entered into the BARO field -- you shouldn't simply enter 200 feet into the RA field.  This is because the terrain ahead of the runway may not be flat. In the extreme case, if the runway sits on a plateau, then you may be well below 200 feet above the runway yet still have more than 200 feet above the ground directly below you (as measured by the radar altimeter).

CAT II and III minima, in contrast, need to use a Decision Height, measured by a radar altimeter, because a barometric altimeter simply isn't accurate enough to measure such small distances to the ground. And the concern that the terrain may not be flat doesn't apply here because at the point where you reach the Decision Height, you're already very close to the runway, and a runway with CAT II/III minima needs to guarantee that the terrain ahead of it is essentially flat for a sufficient distance.

 

  • Like 1
  • Upvote 1

Share this post


Link to post
Share on other sites
On 1/22/2023 at 3:37 AM, RaptyrOne said:

Ditto the FBW. Simbrief and Navigraph work seamlessly. So that is not an advantage. At best a tie. 
VNAV also working well on the Experimental branch at least, so again, a tie at best.

On the simbrief integration .. yeah .. a tie

On VNAV..hmm i have to disagree ..I think FBW still has some missing elements here that needs to be worked on.


AMD Ryzen 5900X / Asus Strix B550 F Gaming Wifi / Powercolor AMD 6800XT Red Devil / 32GB Gskill Trident Neo DDR4 3600 / 2x ADATA XPG 8200pro NVME / Arctic Liquid Freezer II 280 / EVGA Supernova 750 GT PSU / Lian Li Lancool II Mesh Performance /

Asus VG34VQL3A / Schiit Bifrost DAC+ Schiit Asgard AMP /  Sennheiser HD 558 / Thrustmaster T.16000M + TFRP Rudders

Share this post


Link to post
Share on other sites

Getting more tempted to consider the Fenix because of matured VNAV and losing the hard pauses that do happen during taxi especially in the FBW, and it appears this has been an issue really forever, or at least the last 6 months even though they are working on it.  So if you know these planes personally: 

  • How is performance in the Fenix, versus the FBW, and especially compared to PMDG 737 series.  The PMDG 738 really is polished in terms of performance and runs beautifully on my system.  The FBW is similar except for these hangs/pauses, but the total smoothness of the PMDG is really impressive.
  • How does the Fenix hand-fly compared to the FBW?
  • The FBW wants to creep and accelerate during taxi.  I did calibrate my throttle.  Is this to be expected in both the FBW and Fenix?
  • What is missing or not working well in the Fenix currently in your opinion?

Thanks all the Fenix is currently $60 so it will help to know these things before deciding.

Thanks!

After 4 successful flights in the FBW went back to PMDG 738 and anyone who tries to tell me the B738 is more complex to fly have clearly become seduced by the fun of having to do so much more to make the plane function! 


Noel

System:  9900K@5.0gHz@1.23v all cores, MSI MPG Z390M GAMING EDGE AC, Noctua NH-D15S w/ steady supply of 40-60F ambient air intake, Corsair Vengeance 32Gb LPX 3200mHz DDR4, Sabrent NVMe 2Tb x 2, RTX 4090 FE, Corsair RM 850W PSU, Win10 Pro, LG Ultra Curved Gsync Ultimate 3440x1440, TCA Boeing Edition Yoke & TQ, Cessna Trim Wheel, RTSS Framerate Limiter w/ Edge Sync for near zero Frametime Variance achieving ultra-fluid animation at lower frame rates.

Aircraft used in A Pilot's Life V2:  PMDG 738, Aerosoft CRJ700, FBW A320NX, WT 787X

 

Share this post


Link to post
Share on other sites

I believe you’ll find the Fenix comparable to the PMDG 738 in terms of stability and smooth performance. I have not experienced significant hangs or pauses with the Fenix, although I may occasionally encounter a brief stutter on final approach at complex payware airports - most likely due to the traffic and vegetation settings. 
My only peeve with the Fenix is that the text displayed on the Nav display and the MCDU is not as sharp as you’ll find with the PMDG. And this is with a 4K monitor at native resolution and using TAA.  I like to track the waypoints and altitude constraints via the flight path on the Nav display, but the Fenix does not display these with much sharpness. Perhaps others have a workaround for this shortcoming. 

  • Upvote 1

Share this post


Link to post
Share on other sites
29 minutes ago, rlashier said:

I have not experienced significant hangs or pauses with the Fenix, although I may occasionally encounter a brief stutter on final approach at complex payware airports - most likely due to the traffic and vegetation settings

Do you find the same w/ the PMDG 737/8, with the same sim settings, a brief stutter on occasion on final at complex airports?

31 minutes ago, rlashier said:

My only peeve with the Fenix is that the text displayed on the Nav display and the MCDU is not as sharp as you’ll find with the PMDG

How would you compare the Fenix to the FBW in this regard if you've tried the FBW?


Noel

System:  9900K@5.0gHz@1.23v all cores, MSI MPG Z390M GAMING EDGE AC, Noctua NH-D15S w/ steady supply of 40-60F ambient air intake, Corsair Vengeance 32Gb LPX 3200mHz DDR4, Sabrent NVMe 2Tb x 2, RTX 4090 FE, Corsair RM 850W PSU, Win10 Pro, LG Ultra Curved Gsync Ultimate 3440x1440, TCA Boeing Edition Yoke & TQ, Cessna Trim Wheel, RTSS Framerate Limiter w/ Edge Sync for near zero Frametime Variance achieving ultra-fluid animation at lower frame rates.

Aircraft used in A Pilot's Life V2:  PMDG 738, Aerosoft CRJ700, FBW A320NX, WT 787X

 

Share this post


Link to post
Share on other sites
2 hours ago, Noel said:

After 4 successful flights in the FBW went back to PMDG 738 and anyone who tries to tell me the B738 is more complex to fly have clearly become seduced by the fun of having to do so much more to make the plane function!

Genuinely curious: What areas take more work for you in the A320 than in the 737?

Share this post


Link to post
Share on other sites

The Fenix and PMDG 737 behave very similarly for me with the same settings at the complex airports. Perhaps I would give PMDG a slight edge in this regard.

As for comparing the sharpness of displays in the cockpit, the FBW Neo is superior insofar as presenting a brighter cockpit with very legible text on the Nav displays and MCDU. The Neo is a much newer model of the A320, and the text and data are displayed in a basic but sharp block font that is very legible even at low zoom settings when panning the cockpit. The Fenix is an older version, and the text and data are displayed in a more complex font which is not as discernible.  I don’t know if the font and text choice used by Fenix is true to life or not, but I would like to see this improved. It should not be that tough to read waypoint and altitude constraint data off the Nav display. Others may consider this a minor thing, but we like immersion, right?

Rich

Share this post


Link to post
Share on other sites

It just seems so convoluted compared to the 738, but that is probably explained by trying to come up with work flow and that takes time.  My neighbor's son just got hired by Frontier and will be training for 3 months on Airbus which is new to him, coming from King Air hours primarily lately and no jet time of any type.

Maybe you can help me understand what this green arrow means to the right of the this STAR waypoint (EBOMA). I was trying to link EBOMA to C125 but it doesn't work.  I've done this several times on prior flights and it worked as I guessed it should, but not this time.  I hadn't noticed the green arrow so that must indicate something I just don't know what it is:

spacer.png

 


Noel

System:  9900K@5.0gHz@1.23v all cores, MSI MPG Z390M GAMING EDGE AC, Noctua NH-D15S w/ steady supply of 40-60F ambient air intake, Corsair Vengeance 32Gb LPX 3200mHz DDR4, Sabrent NVMe 2Tb x 2, RTX 4090 FE, Corsair RM 850W PSU, Win10 Pro, LG Ultra Curved Gsync Ultimate 3440x1440, TCA Boeing Edition Yoke & TQ, Cessna Trim Wheel, RTSS Framerate Limiter w/ Edge Sync for near zero Frametime Variance achieving ultra-fluid animation at lower frame rates.

Aircraft used in A Pilot's Life V2:  PMDG 738, Aerosoft CRJ700, FBW A320NX, WT 787X

 

Share this post


Link to post
Share on other sites

The stuttering issue is being worked on, but fixing it requires entirely rewriting a big component of the aircraft, so it will take a bit. We also have multiple display optimisations in the pipeline, which should improve general frametimes too.

@NoelRegarding your routing issue, this is also known and will be fixed. However, there is an element of this particular routing situation that is still unknown to me relating to how the real aircraft handles this. So I am waiting on more confirmation from pilots.

Edited by holland786
  • Like 1
  • Upvote 1

Developer - FlyByWire Simulations

Share this post


Link to post
Share on other sites
3 hours ago, Noel said:

The FBW wants to creep and accelerate during taxi.

This is realistic considering the engine performance, at some weights.

  • Like 4
  • Upvote 1

Developer - FlyByWire Simulations

Share this post


Link to post
Share on other sites

Well, it's fantastic already!  Thank you so much and I am happy to donate if it helps!  I have found as mentioned on the website that DX11 is better than DX12 which was my default previously and I have truly perfect performance everywhere, so will stay in DX11 til the dust settles.  Thanks!


Noel

System:  9900K@5.0gHz@1.23v all cores, MSI MPG Z390M GAMING EDGE AC, Noctua NH-D15S w/ steady supply of 40-60F ambient air intake, Corsair Vengeance 32Gb LPX 3200mHz DDR4, Sabrent NVMe 2Tb x 2, RTX 4090 FE, Corsair RM 850W PSU, Win10 Pro, LG Ultra Curved Gsync Ultimate 3440x1440, TCA Boeing Edition Yoke & TQ, Cessna Trim Wheel, RTSS Framerate Limiter w/ Edge Sync for near zero Frametime Variance achieving ultra-fluid animation at lower frame rates.

Aircraft used in A Pilot's Life V2:  PMDG 738, Aerosoft CRJ700, FBW A320NX, WT 787X

 

Share this post


Link to post
Share on other sites
1 hour ago, Noel said:

Maybe you can help me understand what this green arrow means to the right of the this STAR waypoint (EBOMA).

(Edit: See below for an update now that I realize you mean the arrow on the MCDU F-PLN page.)

I don't see an arrow there? What I see at EBOMA are the constraints in magenta (-FL120 and 250KT) and a white circle indicating that the altitude constraint isn't applicable (because you're still in the climb). See here for a guide to the symbology.

Or do you mean the green leg that goes from EBOMA to the northwest without an apparent waypoint that it connects to (though that waypoint may be off screen)? It looks as if all of the STARS in question should have MOLBA as the next waypoint, which lies between EBOMA and LFPO, so it should be visible on the screen, but it's not. Maybe this is the issue that @holland786 refers to? @holland786, can you elaborate?

1 hour ago, Noel said:

I was trying to link EBOMA to C125 but it doesn't work.

Note the waypoint is called CI25 (with a letter "I", not a number "1").

What are you doing to try to link these? If would be helpful to see a screenshot of the F-PLN page on your MCDU. Generally, you should be able to clear unwanted legs or discontinuities in your flight plan by pressing the CLR button and then the line select key next to the line you want to remove.

Edit: I see now that you do have the MCDU included in the screenshot. Sorry for not noticing earlier.

The green arrow next to EBOMA means that EBOMA is a flyover waypoint, rather than a flyby waypoint, and that after flying over EBOMA, the aircraft should turn to the left. Maybe the problem that @holland786 mentioned is related to flyover waypoints?

I do see that you don't have any discontinuities or other waypoints between EBOMA and CI25. I'm confused because on the STAR in question (ARDOL 9W), EBOMA should be followed by MOLBA. Did you delete MOLBA from the flight plan?

In any case, I imagine the problem may be caused by the fact that the FMS thinks it should turn left after EBOMA, but CI25 requires a turn to the right.

As a workaround, I would suggest using DIR TO or heading select after EBOMA.

Edited by martinboehme

Share this post


Link to post
Share on other sites
4 minutes ago, martinboehme said:

@holland786, can you elborate?

The airbus FMS selects a few algorithms to generate LNAV turns based on multiple conditions, like the type of routing at play (DME arcs use a different algorithm than for example). Sometimes, this condition is that a prior algorithm failed to generate an appropriate turn (too big, overshoots, too tight/wide, etc.) In this case here, a "path capture" turn algorithm is used, which while not uncommon, here begins way too early along the leg. There is in fact a leg between EBOMA and the next waypoint which I can't make out the name of (CI25 maybe?) but the turn generates so far away from the end of it that it is completely cut off.

Turns generating away from the very end of a leg is normal, since the aircraft needs distance to complete the turn, but here, it is excessive.

This algorithm is quite simple. Its only goal is to turn to intercept the next course at a 45 degree angle - if you look close, here, you can actually see that the massive line going into the void (part of the turn) is stopping when it intercepts the approach course.

spacer.png

This issue actually happens in the real plane - albeit at a smaller scale and generally only in unusual scenarios, like when the speed exceeds the limits designed for a procedure. We have experienced it flying an A380 simulator out of a SID from which this kind of traffic does not depart.

My guess here is either:

a) that a discontinuity was deleted when it should not have been. This looks like maybe a TF -> CF turn which would never happen in a correct procedure at that kind of distance. Deleting discontinuities is effectively telling the FMS to compute things that could be geometrically impossible with the simple-ish algorithms the Airbus FMSes employ.

b) that a normal turn was generated at a too high distance due to the A32NX not yet accounting for speed predictions when computing turns. this is being worked on, but effectively means that some turns could be computed with 400 KTAS in mind when it will really be flown at 200 KTAS. This can have very large effects.

 

  • Like 3
  • Upvote 1

Developer - FlyByWire Simulations

Share this post


Link to post
Share on other sites

@holland786 Thanks for the detailed explanation -- I for one found it fascinating. I did some hacking around a long time ago trying to come up with these sorts of algorithms, probably just for fun, or maybe I wanted to create my own FMS -- I don't really remember. It never went anywhere, but I worked on it enough to get an appreciation for all of the different cases that can occur (and at the time, I wasn't even aware of all of the different ARINC 424 leg types).

10 minutes ago, holland786 said:

This algorithm is quite simple. Its only goal is to turn to intercept the next course at a 45 degree angle - if you look close, here, you can actually see that the massive line going into the void (part of the turn) is stopping when it intercepts the approach course.

Ah! Now I think I understand what's going on. Thanks again for lifting the curtain!

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Tom Allensworth,
    Founder of AVSIM Online


  • Flight Simulation's Premier Resource!

    AVSIM is a free service to the flight simulation community. AVSIM is staffed completely by volunteers and all funds donated to AVSIM go directly back to supporting the community. Your donation here helps to pay our bandwidth costs, emergency funding, and other general costs that crop up from time to time. Thank you for your support!

    Click here for more information and to see all donations year to date.
×
×
  • Create New...