WRT "mixing" baro and inertial.
Regarding the concept of "mixing" baro and inertial (as posted above).
I would suggest, that such an idea, in a unreliable baro situation,
(which has caused the AP to disconnect in the first place), is,
stupidity personified.
You need to read what I said again, which was not suggesting that a
faulty source continues to be used, but that tracking the two sources
on a continuous basis provides a more accurate view of the overall
situation, a potentially earlier warning of developing problems and
fallback in the event of a single source failure. Perhaps i'm not very
good at decribing what i'm trying to get across ?.
If you have an ivsi on the panel, then you are already using baro /
inertial mixing, though not in a particularly complex way.
Why "contaminate" a supposedly "good" source of reliable data (inertial) with "known" or "suspect" baro data ?
All you end up with is a new layer of "uncertainty", on top of the one you already have, which you then have to troubleshoot.
Why make an uncertain situation even more uncertain and harder to troubleshoot ?
Such a situation is self defeating.
In a crisis, you need "crystal clear deliniation" of what is "good" from what is "suspect", or "bad".
The system should clearly "split" the two data sets by source.
Baro says "this", inertial says "that".
Separate functions, yes, but cross check between the two to improve
validity and consistency of data.
That can be done very simply.
Upon AP disconnect, the system should automatically, and instantly, modify the PFD to show all good inertial data, and remove the suspect data, as follows:
(a) remove FD bars if they were on, and
(b) put up the "inertial" FPV (bird) [with the inertial GS (not CAS or TAS or MN - they are baro) in the circle], and
(c) on the right of the bird - display the "actual" AOA, ("baro-ish" - but - we need it) and
(d) on the left of the bird - display the "target" AOA (for altitude, weight and speed from database - should be the same as the QRH - UAS tables).
(e) on the right - below the bird - display the "actual" N1's
(f) on the left - below the bird - display the "target" N1's (for altitude, weight and speed from database - should be the same as the QRH - UAS tables).
(g) in the left lower corner of the PFD - display a circular "traditional steam gauge" altimeter with a moving hand driven by inertial data, and
(h) in the right lower corner of the PFD - display a circular "traditional steam gauge" variometer with moving hand driven by inertial data.
PF should then just simply fly the bloody aeroplane.
That's high level detail and not really my area. No argument
about the last line though :-)...