Airborne_Again wrote:
(I really don’t see why as non-SBAS boxes are perfectly capable of RNAV 1 and RNAV APCH.)
The early GPS systems had a CDI for enroute of +/- 5 NM. The GNS 430 was developed in the late 1990’s and the C129 TSO was non specific on many items that got clarified in the C145/146 TSO. Even so, the early GPS systems are approved to fly RNAV 2 routes.
Ibra wrote:
Yes, VNV or VPATH is from one baro altitude to another baro altitude but unless you have Baro-VNAV inputs the calculated TOD/PIT/ROD your navigator will fly rely on GPS position & altitude as well as it’s quality of signal? derivative or guidance comes from GPS while the final or target state is BARO
A requirement of VNV or VPATH from the pilot guide is:
4.3.3.1 VNAV Requirements
• Enablement by the installer
• A baro-corrected altitude source
So there isn’t any VNV based on GPS altitude as there is no way to correlate GPS altitude with Baro corrected altitude. The vertical guidance is a form of Baro-VNAV and not GPS-VNAV. Too bad that there isn’t an approval for the GTN series to use Baro-VNAV on the FAS when the procedure supports LNAV/VNAV, but outside of a SBAS service volume. The GTN has added +V which is based on GPS vertical guidance and can be used outside of an SBAS service volume, but only for an LNAV MDA and not a LNAV/VNAV DA. The GTN Xi has extended the +V to support conventional procedures such as VOR to a MDA.
Airborne_Again wrote:
LNAV/VNAV, yes. “Enroute” VNAV – I don’t think so. At least I see no reason why.
No technical reason, but the Baro-VNAV VNV function with vertical altitude constraints in the database was only recently introduced in the Garmin GTN 750 at software version 6.50. So outside of FMS type equipment used on corporate business aircraft and Air Carrier, it is not available in any non WAAS navigators I know of.
Peter wrote:
Out of interest, how is autopilot driven VNAV implemented? Does it use VS mode with an altitude preset and fake the VS selection button input, or does it use ILS mode and fake a GS input?
It is currently only implemented in the Garmin system if you have a Garmin G500/600 autopilot. I have a GTX 750 with VNV and a G500 TXi, but my autopilot is an Stec 60-2 and will not follow the VNV guidance, I can hand fly the VNV guidance, but no automation.
Edit: The Stec 3100 has VNV capability, but unless there is an announcement at Oshkosh, it does not support the Garmin VNV. If it did, I might upgrade my 60-2.
That is really interesting. Sooo close and yet sooo far away, and there was me thinking that in the 20th century (whoops this is the 21st I think) there is this thing called “software” 
Clearly it hasn’t penetrated to the the GA avionics business, yet.
20 years ago, the KFC225 could accept ARINC429 roll steering instructions, giving it the roll angle to tip the wings to. But 20 years later, the same thing for pitch does not exist… except with another totally proprietary system, which most people can’t upgrade to, and those who can are looking at a few tens of k.
OK it is announced that the Stec 3100 will support the GTN/G500TXi with VNV sometime in 2021 Q3, that means the earliest possible date is Sept 30, at 11:59 PM, 2021.
New Features:
GPS enroute VNAV – S-TEC 3100s with Version 1.4 software and new bezel with VNAV button will allow coupled VNAV flight when interfaced with a compatible GPS source and EFIS Currently, only the Garmin GTNTM Navigators and TXiTM displays will allow VNAV. (available late Q3 2021)
Peter wrote:
20 years ago, the KFC225 could accept ARINC429 roll steering instructions, giving it the roll angle to tip the wings to. But 20 years later, the same thing for pitch does not exist… except with another totally proprietary system, which most people can’t upgrade to, and those who can are looking at a few tens of k.
Well, you will surely agree that vertical guidance has a lot of practical implications that lateral does not…however once you are capable of displaying a stable glideslope signal, there is no reason other than commercial not to be able to couple it, like you can do with, for example, the fake G/S on a visual approach. My bet is purely commercial: so you buy Garmin displays and autopilot to go with your GTN…
Peter wrote:
20 years ago, the KFC225 could accept ARINC429 roll steering instructions, giving it the roll angle to tip the wings to. But 20 years later, the same thing for pitch does not exist… except with another totally proprietary system, which most people can’t upgrade to, and those who can are looking at a few tens of k.
What would be the benefit of giving pitch instructions rather than deviation information?
Roll steering has the advantage that the navigator can do turn anticipation, fly holds, RF legs etc. with the correct turn rate. What would the advantage be of “pitch steering”? That you could move the vertical mode functions such as IAS hold into the navigator?
Well, you have to do it somehow…
Roll steering is a bit of a bodge. The GPS implements a sort of proportional (PID probably without the D and with a little bit of I for removing steady state tracking errors) control loop for computing the required roll angle.
The primary setpoint on an AP is a heading, in all phases of flight, except when ARINC429 roll steering when it is the roll angle. I don’t know whether ARINC429 roll steering is used enroute; it obviously could be.
For altitude, the primary setpoint is the pitch angle, and the error is tweaked to achieve alt hold. This is so because an AP has pitch and roll input. The AP implements this internally.
So, for a VS, the primary setpoint would still have to be pitch. The difference is that for ALT hold the steady state pitch would typically be +2.5 deg, whereas for say -500fpm it might be -2deg. The AP does know the VS because it has a direct baro input (not just the gray code from an encoder; that is used only for capturing the preset altitude, and then as a very slow background loop to hold it).
I would think any real implementation would have to start quite slowly, in a descent.
The bigger problem is that autopilot-VNAV has a risk of stalling the plane if you select a climb, so a) you need a system with envelope protection and b) the programmed VNAV step may not be achievable (in fact, is not achievable in typical SEP flying in the European IFR system, where one is pitch-limited in most climbs, and non-turbo pistons cannot do +500fpm above FL100). This is not fully solved even on big jets (which normally have loads of spare power); their APs do VNAV but AIUI you cannot program a profile of multiple steps. Only the immediate step can be programmed (this came out re MH370).
Roll Steering is a superior method of interfacing to an autopilot for navigation guidance from a navigation system. It has been around for some time in the FMS world.
Standard navigation guidance in the legacy autopilots is based on CDI deviations and if course information is available, the OBS course setting, which limits the navigation guidance to following straight line courses. Wind correction is determined by deviations in the CDI and the rate of the deviation. This is always reactive, that is the assumed course is set and it takes a significant amount of drift and deviation to recognize wind effects and then a correction to intercept the original course and once centered, adjust the wind correction. This is an iterative process and takes some time and S turns are common.
With roll steering, the navigator provides a bank angle for the autopilot to fly. This allows for curved paths such as holds, procedure turns, DME arcs, RF turns and course changes with turn anticipation. The CDI deflections are not used, nor is the OBS setting. The navigator can always determine actual track and actual ground speed. With air data and heading input, airspeed and heading are known. Wind corrections are near instant because the navigator knows the desired track to hold the course and long before there is any indication on even a half a needle width on the CDI, the course can be smoothly corrected with an appropriate bank angle to maintain the desired track in the center of the course. With legacy autopilots that don’t directly support a roll steering input, a roll steering to heading error converter is used to achieve the same result in heading mode. Roll steering provides for course intercept and for turn anticipation for course changes.
