CNS-80 VNAV

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---

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.

"John R. Copeland" wrote:

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---

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---

John R. Copeland wrote:
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.

I'll admit I'm guessing here, and I'd like to know exactly how the baro input is
incorporated in the navigation solution, but I suspect the baro altitude is
incorporated into the solution in a similar way to having another satellite in view.

IOW, with 5 satellites in view plus baro input, the navigation solution has 6
equations with 4 unknowns (3 dimensional space plus time). If that's the case,
the baro input participates in the lateral position determination as well as the
vertical. I suppose they could "weight" the effect of the baro input since its
precision/accuracy are different from the satellite inputs.

In TSOC129 units that use baro-aiding, there's no vertical guidance, yet the
baro input is incorporated in the navigation solution somehow.

DGB

---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.

"John R. Copeland" wrote:


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---



--
Dave Butler, software engineer 919-392-4367

If nobody else runs the test before I get a chance, I'll report back =
when I do.
I think you're too deep into speculation mode when you suggest baro =
input
might contribute to determination of lateral position.
Until I see some test results, I lean more toward thinking the CNX-80
may be relying on WAAS-augmented geometry for VNAV guidance.
It might be very ILS-like in that instance, where the baro setting
affects the DH(DA), but not the glide path.
---JRC---

"Dave Butler" wrote in message =
...
John R. Copeland wrote:
=20
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.
=20
I'll admit I'm guessing here, and I'd like to know exactly how the =
baro input is=20
incorporated in the navigation solution, but I suspect the baro =
altitude is=20
incorporated into the solution in a similar way to having another =
satellite in view.
=20
IOW, with 5 satellites in view plus baro input, the navigation =
solution has 6=20
equations with 4 unknowns (3 dimensional space plus time). If that's =
the case,=20
the baro input participates in the lateral position determination as =
well as the=20
vertical. I suppose they could "weight" the effect of the baro input =
since its=20
precision/accuracy are different from the satellite inputs.
=20
In TSOC129 units that use baro-aiding, there's no vertical guidance, =
yet the=20
baro input is incorporated in the navigation solution somehow.
=20
DGB

John R. Copeland wrote:
If nobody else runs the test before I get a chance, I'll report back when I do.
I think you're too deep into speculation mode when you suggest baro input
might contribute to determination of lateral position.

Certainly deep into speculation, since AFAIK all the navigation algorithms are
proprietary, ... or maybe they are published as part of some certification
process, anyway, I've never seen them.

However it seems clear that baro-aiding is incorporated into TSO C129
navigators, which offer no vertical guidance. It's hard to imagine why they'd go
to the (considerable) trouble to have a baro-aiding interface if the baro-aiding
didn't add to the navigation solution.

Until I see some test results, I lean more toward thinking the CNX-80
may be relying on WAAS-augmented geometry for VNAV guidance.
It might be very ILS-like in that instance, where the baro setting
affects the DH(DA), but not the glide path.
---JRC---

"Dave Butler" wrote in message ...

John R. Copeland wrote:

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.

I'll admit I'm guessing here, and I'd like to know exactly how the baro input is
incorporated in the navigation solution, but I suspect the baro altitude is
incorporated into the solution in a similar way to having another satellite in view.

IOW, with 5 satellites in view plus baro input, the navigation solution has 6
equations with 4 unknowns (3 dimensional space plus time). If that's the case,
the baro input participates in the lateral position determination as well as the
vertical. I suppose they could "weight" the effect of the baro input since its
precision/accuracy are different from the satellite inputs.

In TSOC129 units that use baro-aiding, there's no vertical guidance, yet the
baro input is incorporated in the navigation solution somehow.