When in descent and you change to manual heading mode what happens to your VNAV? In the Fenix it goes into manual v/s. Is this what the real aircraft does?
That’s one thing that always gets the profanities coming out thick and fast…
737 you can stay in vnav when doing the good old vectors…
A320… HMMM what am I doing wrong…?? That’s the very conservative word comming out of my mouth
Anyone having LOC offset issues on an ILS approach in the Fenix? Ive reached out to Fenix and Navdata in regards to the issue. Happens with 3rd party scenery and default scenery. Doesnt happen with any other aircraft. Just wondering if anyone has a work around for this
When looking at the EFB at descent and at the arrival performance. When do i use 4,3,2, or 1? What’s the weather of runway state has to be.
What also seems to me is that a lot of times at smaller airports the weight auto created in a simbrief profile is much to heigh to land and stop not overshooting the runway. It’s always around 63tonnes
I posted the below in the Fenix Discord yesterday, but it got kind of buried today, so posting here (with the one possible solution provided as well):
I’m flying the Fenix into KDEN, via the NIIXX3 STAR, which has different routing for landing south and north. I originally had ILS 35L plugged in, but the winds changed, and ATIS switched to 17R. I tried simply updating the approach to 17R in the MCDU , keeping the STAR and transition, but it kept the same routing as if I was landing on 35L. I had to eventually delete the STAR and re-add it in order to get the south routing to 17R, which took a few minutes of fiddling (and I’m not quite sure what I did).
Is there an easier method to do this?
The one response I got, which would work, but there’s got to be a way to do this in the active Flight Plan:
“When I’m importing my initial flight plan into the MCDU, I copy it to the secondary flight plan before entering the STAR and arrival runway. When you get those last minute runway changes, it makes it really easy and only takes a few seconds to enter the STAR, approach and VIA (if applicable).”
That is annoying. But possible it’s more Denver specific? As the NIIXX3 STAR is like 4 or 5 STARS & transitions in one. Maybe that’s why it wanted you to reinsert it?
Have you tried a last minute runway change using an airport with a more simple STAR (one that can be used for both runways?) I bet that will work.
Other than that I think the advice of having a secondary flight plan in the MCDU is a good one as a backup although you would still need more than 2 options for KDEN.
I’ll see if I can reproduce this scenario. I’ll guess that the ROBUC3 into KBOS would give similar results, as it has multiple transitions and different paths to different runways, similar to NIIXX3 at KDEN.
What I think I did to get the new RW in place was 1) put the plane in HDG mode, changed to a different runway and different (random) STAR, then changed again to the new runway and the original STAR, then direct to whatever fix I was originally heading for. It was rather convoluted, whatever I did.
Yeah I’ve seen that happen too, and I also had to use the switch to a different runway and back while on HDG. I’ve no idea how the real plane behaves for this.
Maybe I’ll submit a support ticket if I can consistently reproduce this. Glad to see it’s not just me.
I also want to know, do you have an answer? Can you let me know?
I was able to repro my issue, last night, flying to KDEN on the SSKII1 arrival. Well before ToD I decided to change from 16L to 34R, left the already-set STAR/transition, and it still kept the same routing for a southbound landing. To get around it I went to HDG mode, temporarily selected RW 8, “NO STAR”. Then I changed it to 34R, selected SSKII1, and it all worked (and pressed the HDG to go managed). I then had to do the two-step method to get it back to the original 16L.
I think I’ll still plan to copy the flight plan to Secondary FP before entering a STAR/arrival RW, especially when I’m on VATSIM, so I can quickly swap and add a STAR.
After updating SU14, my 320 DU and FCU windows display delay very serious, and there is a serious stuttering phenomenon. May I ask what the reason is?
I have a question for the IRL pilots who are here and who kindly teach us with their advice to improve and make our virtual flights more realistic.
In icing conditions, if we go through a cloud layer, when do we turn on the anti ice? Before entering the clouds, or we don’t turn it on till “ice det.” appears in the ECAM?
Thank you for your advice, and merry Christmas
Until today, I didn’t have any major problems with the fenix A320, but today I’m really annoyed. I don’t have that much freetime for flying as before but I wanted do one few hour flight. But right before landing the cockpit knobs commands stopped responding and from exterior view left aileron is down like with cold plane and right speedbrake is up. I was hoping that by now MSFS and Fenix app connection would be stable. I restarted the app but whole plane went cold dark and plummeted into ground. Thanks fenix app.
Now I’m flying an Airbus with auto mode for the anti ice so during cruise not much to do or think . But rule of thumb for the previous without the auto mode, takeoff and landing when it was expected to encounter ice or in the conditions described in the manual. For cruise we waited till the ECAM. If it was not a thin layer of clouds and expected to encounter icing conditions we used to turn it on in advance. Maybe other operators have different procedures…
I’m not on fenix discord, any news from fenix team about updates,?
I think this message explains mostly of the problems they have
“One of the major issues we have right now is detail maps; we rely heavily on them for the V2 and built the new art around them, however they seem to just not function properly on some exports and sometimes, scarily, on the user’s side. It seems to have been introduced in a recent(ish) SDK update, but where we’re screwed is that we need the fixes in the new SDK for several features, but also need the old one to export a working model. We’re having to quite significantly roll back on several months of work as it seems Asobo will not be addressing this issue anytime soon (the bug report was sent several months ago), whilst still meeting our initial objectives. The worst bit is, this fix is likely just a few lines of code somewhere in the MSFS shaders, but nothing we can change sadly.”
This is really sad thank you for the information