NAV1 on both runways

Hello,

I am trying ton use the new Autoland feature, but when I select a runway at an airport as NAV1, it sets both ends as NAV1, making my plane overshoot the runway for some reason when I ask it to autoland. Any suggestions?
Device: iPad Pro
Operating system:iPadOS 16.4

@Aslan_S Welcome to the community!

It’s normal for the two ILS’s for a particular runway (both directions) to light up when you select NAV1. You just have to be within the acceptable altitude and approach angle limits (and speed limit) for which of the two ILS’s you are using. The following explains the details:

2 Likes

Yes I did, I followed all steps, and the only thing that seems to differ from what’s happening on his screen and mine, is that when he selects his runway, it only says NAV1 in green under the runway he selected. While for me it says NAV1 in green under both sides of the runway.

I think this is the issue, but I’m not certain.

Not all runways have ILS approaches from both directions. The one he selected doesn’t have an ILS from the opposite direction. So it can’t light up.

If there are ILS’s from two directions on the same runway, both will always light up.

So there must be a different issue that causes you to miss the ILS?

Being too high above ground or too large an approach angle as you approach the intercept is the most likely reason.

You need to start far enough away from the runway so that the glideslope is above you before you hit APPR, at no more than, say 3000feet AGL, and no more than about 30 degree intercept angle.

If you follow those conditions, then you will intercept the correct ILS even though both directions are lit up for NAV1

I do follow these conditions. I turn APPR on at 3000 feet, under 200 knots and at a 30 degree angle. And when I click it, it find the localiser and the LOC turns green, then after a bit the ALT also turns green, and it makes all the changes in heading on it’s own, but it doesn’t descend in altitude until way too late.

Any ideas?

1 Like

Is it still in an actual an descent or is it at level altitude and refuses to go lower when this happens?

I typically hit APPR at 180. Depending on your aircraft, level descent can only be achieved at specific speed.

The ILS delay shows an error in your system, and the quick descent profile is called a ‘slam dunk’ in IRL Aviation. Very fun approaches, mind you.

edit: I’m backtracking a bit on what I wrote below. Some factor or factors are still giving inconsistent results. More than one factor is involved? The error needs to be consistently repeatable. And I fail to do that yet.

I think I’ve got it after a bunch of testing.

Every time I try to get into a good intercept position using GPS waypoints (constant 3000 feet alt, below GS, good intercept angle), and I hit APPR while still being in LNAV (again with GPS set rather than NAV1), APPR refuses to descend to follow the GS.

So a I stay stuck at 3000 MSL (I was at SFO, sea level).

It was confusing because even though I was doing LNAV with GPS, hitting APPR changes GPS to NAV1 for you. But, it wouldn’t descend even though it had switched to NAV1. If I had it in GPS first, the descent just didn’t seem to work.

Speed doesn’t appear to be a factor. As long as you get the descent to engage, even a higher speed may work. I was trying beyond 230kts (above 250kts APPR gives you a warning and won’t engage)

Hey, can you try sharing a screen recording of you trying APPR in a flight?

1 Like

I definitely would if I thought it would be useful. But to be useful, I think it has to be meaningfully representative of the issue, by showcasing some distinguishing setting or aspect which reliably recreates the issue. But I haven’t been able to figure out what that is.

Whenever I think I’ve pretty reliably approached pinning it down (by it looking like I’ve caused it in one case but not another), my next step is to run tests to try to invalidate my conclusion.

My problem is, so far, I have been able to invalidate all my conclusions, in other words to falsify that my initial conclusion was consistently reproducible.

So as soon as I can find a video that doesn’t invalidate my conclusions, that will be the one to share.

But unfortunately, that’s also the one that solves the problem, if you see what I mean.

So, I was able to reproduce not capturing the GS occasionally when testing, but with no conclusion as to what conditions cause it.

In testing many times, by far the majority of times I do get proper capture of GS when obeying the 30 degree max intercept angle, GS is above me, and I’m at level altitude (roughly 2500 to 3000 feet AGL ), not too close to the entry of the approach cone.

I would recommend trying again, more than once, verifying these conditions. If you continue to have trouble not descending, if you could share a screen shot, it would likely be very helpful.

Hello.

EDIT: I WAS ABLE TO UPLOAD THE VIDEO, THE UNLISTED YOUTUBE LINK IS DOWN BELOW.

So I wasn’t able to upload a Screen Recording because of the file type, but here are some screenshots from my screen recording. I set London City as runway 9 as NAV1, and it selected both runway 9 and 27 as NAV1.

I then intercepted it at lower than 200ks, 2500ft, and at no more than a 30 degree angle. The APPR immeditely locked the localizer. And then locked the glideslope right before the runway. And it overshot the runway and landed extremely smoothly on random terrain post runway.
Here I have screenshots of the activation of APPR, getting closer to the airport, overshooting the airport, and landing post-airport.
Let me know if you need any more screenshots, and if you can help me out.

Vid

1 Like

UPDATE:
I tried this from London City to Heathrow, instead of Heathrow to London City (the route I have consistently been testing); and it landed in APPR at Heathrow.

It did bounce on the runway when landing, but I think that’s something I can fix.

And I just found multiple support requests specifically about London City, saying that it is terrible for APPR. So I guess my problem is solved.
Thanks so much everyone.

2 Likes

That video is very helpful. Thanks for the upload. An immediate issue is you go from zero to full flaps all at once and at too high an airspeed for full flaps. The AP would fight to descend.

And your approach speed continues to be far too high, even if you were near the runway - any contact with the runway and you would bounce right off with even a very small vertical speed.

Note in the screenshot below with your 185knts and full flaps, the FPV (small circle) is actually above your nose mark (line with the v-dip). This shows you actually have a negative AoA (angle of attack). Nearly 100% of the time during all flights the FPV will be below the nose mark (your nose slightly high compared to your flight path - nose mark above FPV).

So the little circle being above your nose mark (ballooning from coming in with too much energy) shows you are much too fast for the flap setting.

Please read my comment above about airspeed for approach. Also relates to bouncing.

I disagree.

Though the video you uploaded is excellent info.

The flollowing shows the fundamental problem that caused your topic.

The first shot you are 185kts with zero flaps; the second shot (a few seconds later) you are 185kts but went to full flaps.

Notice the FPV (small circle) compared to the nose mark (line with the v dip).

In the first shot your nose is high above your FPV, which means you are getting quite slow for the 0 flaps.

In the second shot your nose is actually below the FPV, which is way too fast (negative AoA is trying to destroy lift).


above: no flaps


above: full flaps

So you can use the FPV to nose angle (when their movement settles down), as a quick rough guide to whether you are way too slow or way too fast.

Also, notice here (which you can see dramatically in your video), relative to the horizon, your nose very aggressively pitches down to deal with the sudden dumping of flaps.

APPR wasn’t designed to deal with these extremes.

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.