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

[speedyTC 195]

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. 😄

[martinboehme 492]

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.

 

[Maxis 1,865]

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.

[Noel 4,502]

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! 

[rlashier 93]

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. 

[Noel 4,502]

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?

[martinboehme 492]

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?

[rlashier 93]

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

[Noel 4,502]

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:

 

[holland786 504]

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 January 24, 2023 by holland786

[holland786 504]

3 hours ago, Noel said:

The FBW wants to creep and accelerate during taxi.

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

[Noel 4,502]

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!

[martinboehme 492]

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 January 24, 2023 by martinboehme

[holland786 504]

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.

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.

 

[martinboehme 492]

@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!