Do you mean that my CNX-80 is performing an illegal act when it drives
my VDI during an LNAV/VNAV approach?

The only "complicated" hookup which I have is that my altitude encoder
reading is known by my CNX-80, as well as the current baro setting,
which it prompts me to confirm from time to time.
The way the approaches fly, though, it feels like the VNAV guidance
is computed from three-dimensional GPS position.

I could test that by setting a grossly inaccurate Baro reading,
and watching the actual altitudes it steers me toward.
I think I'll try that next time I get a chance.
---JRC---

wrote in message =
...
It would seem that would be legal for LPV but not for VNAV minimums. =
VNAV
is actually Baro VNAV, which requires a lot of hookups and =
computational
fussing with the air data system.
=20
"John R. Copeland" wrote:
=20
After upgrading to software version 2, the CNS-80 offers a new
display page, resembling an HSI with a VDI pointer at its left.
The unit's computed VDI presentation is active for many GPS
approaches, as well as for all LNAV and LPV approaches.

However, I have not (yet) found in the pilot's manual any
explanation of when VDI drive is withheld from an external HSI.
By flying several different kinds of approaches, I seem to see
that the external VDI will be active *only* when VNAV minima apply.
Only on precision approaches having DH instead of MDA,
my autopilot could arm and capture the glideslope,
exactly the same as an ILS.
On non-precision approaches my external VDI needle remained
driven out of view, even though its glide-slope flag was pulled,
and as a result I could not arm the glide slope for automatic =
capture.

(Unexplainably, the CNS-80 annunciated LNAV/VNAV
on approaches which actually were non-precision LNAV.)

I'm guessing that the external VDI drive was withheld precisely to
prevent glideslope capture on coupled non-precision approaches.
I don't know the reason behind this, or even if that's the rule.

Of course, LNAV coupling works for all approaches, as expected.
---JRC---