LGIO RNP Z 32 - vertical profile, and how can avionics fly this?

Snoopy wrote:

It must be a GPS-approved approach.
There must be a non-zero vertical angle for the approach.
A valid geoid height for the runway must exist.
The approach does not contain LNAV/VNAV or LPV service levels.
Additionally, the unit must have a SBAS (WAAS, EGNOS, GAGAN or MSAS) signal of sufficient integrity. This means the GPS Status page must show “3D Diff Nav”.

I agree with most of this on the GNS and GTN, except at the most current software version the GTN does not require to be in an SBAS service volume. The GTN and the Avidyne 540 will provide LNAV+V when outside the SBAS service volume where adequate vertical integrity is not available, Hawaii has several approaches that used to not provide +V because the WAAS integrity was not adequate, but now these procedures will show +V on the GTN. After all, +V is just advisory and almost any path between the FAF and the MDA will be safe. This is incorporated as an option in the latest version of the C146 TSO. On the GTN you can even disable the SBAS and it will still provide +V. With the GTNxi, the approach can be a VOR approach and still get +V in the current software.

The US coded about 70 procedures with a VDA of zero degrees and they would not provide +V, but all of these procedures have been updated and the database no longer has entries with a zero degree VDA.

The approach does not contain LNAV/VNAV or LPV service levels

How one can guess this for LGIO RNP32 using GTN?

It is shown as LNAV(Z) & LPV(Y) selection in navigator but has LNAV & LNAV/VNAV minima in plates !

I know it’s bonker as Garmin needs to rename it RNP32 in DB selection while the annunciations (possible choices are LNAV, LNAV+V, L/VNAV, LPV, LOI) need to be used in conjunction with plates minima (only LNAV/VNAV, LNAV are listed)

PS: edit, I figure it out, missed and circling are different: CTL it is not allowed with RNP Y but it seems ok for RNP Z, maybe the reason why they split for two pages of plates?

+V is Garmin stuff:

Why am I receiving a glide path on a GPS LNAV Lateral Navigation (LNAV+V) approach?

The glide path that is generated is based on the information that is used for the Localizer Performance with Vertical guidance (LPV) and Lateral Navigation / Vertical Navigation (LNAV/VNAV) procedures. It uses a specified decent angle that is centered at the MAWP (Missed Approach Waypoint) and at the TCH (Threshold Crossing Height). If this information is included in the electronic database for the approach, the 400W/500W series, G1000 with WAAS, and GTN 600/700 series will generate a glide path.

What are the criteria to “upgrade” an approach from LNAV to LNAV+V?

Most LNAV approaches are eligible for upgrade to LNAV+V. The criteria for being included in the database are:

It must be a GPS-approved approach.
There must be a non-zero vertical angle for the approach.
A valid geoid height for the runway must exist.
The approach does not contain LNAV/VNAV or LPV service levels.
Additionally, the unit must have a SBAS (WAAS, EGNOS, GAGAN or MSAS) signal of sufficient integrity. This means the GPS Status page must show “3D Diff Nav”.

If all these requirements are met, the Garmin navigator will automatically upgrade the approach from LNAV to LNAV+V.

Ibra wrote:

Talking about GPS SBAS where indeed +V does not move in space for (unlike in Baro-Nav)

Assuming Garmin does check +V against obstacles in true GPS altitude, then flying +V all the way you will be clear of them but you may not have the required “baro MOC” depending on the days?

Does Garmin really check +V against obstacles in true GPS altitude? I had the impression obstacles in many databases are in baro altitude, does Garmin do a similar conversion (or temperature corrections) before checking that +V hits obstacles?

The VDA path for +V extends on a straight line from the FAF or a stepdown fix inside the FAF at the crossing altitude to the TCH above the threshold. The VDA choses the highest angle as long as it does not exceed the maximum angle permitted for the category of approach. Obstacles are only protected for from the FAF to the MDA and not below the MDA. The VDA for a given procedure is part of the database entry and is chosen by the procedure designer, not Garmin. The WAAS integrity limit for vertical 99.99999%, is +/- 50 meters. The latest versions of the WAAS TSO allow for advisory vertical guidance when not in an SBAS service volume. This is safe because any altitude is allowed on the FAC for an LNAV procedure down to the MDA which is still always determined by the altimeter indication and not the GPS height.

I agree with your statement regarding that the altimeter indication when following the SBAS VDA +V, may be above or below the charted minimum. Pilots are not authorized to follow the +V below the relevant crossing altitude indication depicted on the chart.

In most GPS, if there is an obstacle database, GPS altitude above the WGS84 datum (aka geometric altitude) is used in the database to specify the obstacle height and it is evaluated against the GPS geometric altitude. GPS altitude is going to be well within the system maximum specifications of +/- 33 meters 95% accuracy for uncorrected GPS and WAAS performance is better than +/- 3 meters. Baro altitude is another matter and varies greatly with temperature and at 10,000 MSL can vary by as much as +/- 1000 feet, so if you don’t want to hit the rocks, if you are using MSL, better have a very large buffer.

Peter wrote:

I don’t understand how BARO VNAV works. A GPS generating “VNAV” of any sort should be using GPS altitude.

My GTN can generate vertical paths for an approach using an ILS GS or a SBAS based GP, and enroute or terminal descents using a Baro-VNAV computer with altitude as an input. Some FMS can use Baro VNAV for approaches as well, but not my GTN.

Baro-VNAV is found mostly in FMS type systems, but now is available in G1000 and GTN installations. It is a computer based vertical path using a barometric altimeter input. The altitude is corrected to MSL by the altimeter setting. An along track position is used by the computer to determine the associated MSL altitude to maintain the GP and an appropriate VDI indication is displayed to the pilot for a final approach segment (if approaches are supported) or to an autopilot using a digital interface. In my aircraft with a GTN750/G500TXi/Stec 60-2, there are three GP type of indications to the left of the altitude tape on my G500TXi, a solid green diamond for ILS GS, a solid magenta diamond for LPV and +V vertical guidance, and a open magenta diamond for VNAV.using the Baro-VNAV. Only the solid diamonds are connected to the analog signals to the autopilot. I would need to replace the Stec 60-2 with an autopilot that supports the baro-VNAV guidance which is used for enroute and approach procedure descents up to the FAF. So I can hand fly the Baro-vnav vertical guidance on my PFD, but not use the autopilot to do these descents.

NCYankee wrote:

This does not use SBAS for vertical guidance and is not connected to the vertical CDI

It is if you use a G5 (or other Garmin EHSI’s, I guess). But I also think it correct that the analog vertical deviation outputs from the GTN are not activated by a VNAV profile.

arj1 wrote:

on Garmin you can drive a GPS “glideslope” (VNAV for LPV or +V) from a GTN and many autopilots support it.
But GTN could also do “enroute VNAV” where you put the VNAV constraints for the normal route and it should bring you down as needed.

So my question was just to clarify which case you meant in your statement.

The latter. Except that in this case you don’t put in the constraints yourself – they’re included in the procedure.

I wouldn’t call the former “VNAV” at all. It is a glideslope.

Peter wrote:

I don’t understand how BARO VNAV works. A GPS generating “VNAV” of any sort should be using GPS altitude.

AFAIK Baro VNAV requires a source of Baro altitude, for example in form of GIA63/64 on G1000 or an ADC connected to, say GTN.