Has anyone done this?
I do like the "MFD" concept and the permanent map display on it, with the option to view stormscope / TCAS data on the MFD and not on the GPS.
The EX600 seems a good improvement over the EX500.
How sunlight-readable is it? Some of the newer Avidyne MFDs do have poor sunlight readability, from what I saw on a demo stand, but I don't recall which one it was.
... over the EX500.
I have flown some hours with an EX500 and that was already a great piece of kit. About sunlight readability I don't know much because it was mainly night freight that we did then. What I liked about it was the uncluttered display - you had the option to display one screen after the other at the press of the relevant button (topo map, weather radar, navigation map, terrain, traffic (was not installed in our aircraft), waypoint list with distances and times, jeppesen charts). Other than that kind of screen that displays everything at once to a point where the whole thing becomes unreadable/uninterpretable (but maybe that is also the preference of some users to set it up that way?).
BTW: This is what professionals must live with in terms of multifuntion displays (here from a 747)
At least it's in COLOR ;-)
Who remembers the "symbol generator" from the ATPL curriculum? Their explanations of how glass cockpits work and the questions around it were hilarious for an IT professional.
Yeah, I remember the symbol generator too.
The sad thing is that neither the teachers nor the ATPL cadets passing through the FTO sausage machine ever get to know any better.
But... if you buy a pre-G1000 TBM, you get the EFIS40 system which does have a box which is the symbol generator.
The average King Air is full of these old boxes. What I find fascinating is the operating temp range; down to -55C. That is actually hard to do and you have to compromise massively, using all kinds of old crap parts which are rated down there.
I guess it is late 1980s. The EFIS40 install manual I have shows Issue 1 in 1992. Less than a decade later, it shrunk to this.
Re my original post, I am particularly interested in whether there is total compatibility. For example, if I replace the KLN94 with a GTN or GNS box, I lose the correct depiction of the OBS mode on the KMD550.
A lot of pilots live with that kind of stuff (especially if it's presented as a fait accompli after they paid for the job) but currently I have a completely integrated cockpit. There are just 2 things it doesn't do: LPV & PRNAV.
if I replace the KLN94 with a GTN or GNS box, I lose the correct depiction of the OBS mode on the KMD550.
Are you sure? With my GTN650/Aspen setup I get a suitable magenta line on the Aspen when in OBS mode. Surely the Aspen and KLN units use the same data broadcast from the GTN?
Who remembers the "symbol generator" from the ATPL curriculum?
Me, because at work I sit behind a couple of those :-) We have a lot of little buttons and knobs and CBs by which we can select all kinds of "reversionary modes" should one symbol generator or other component fail.
... hilarious for an IT professional.
Well, I don't know. Hilarious? It's a matter of system architecture and interface definition and bus design with a goal of maximum redundancy and comparison monitoring capabilities throughout. Not unclever at all, especially bearing in mind that this all started in the early 70ies with the Space Shuttle in mind (but I'm a little biased because as aerospace engineer I have worked in aerospace related IT for almost two decades - not in avionics however). If a fully integrated system like a Garmin 1000 fails, it fails. You stay where you are until you get a replacement unit installed. When we have a failure within our Honeywell system built around "symbol generators", there will be a switch setting for almost 95 percent of failure modes which lets you fly home in the evening. It is even permissible, should one PFD screen fail, to mechanically replace it with the central MFD screen (can be done by the pilots themselves in less than 10 minutes) and dispatch.
Anyway, Cessna/Honeywell (no idea about other manufacturers) don't call their symbol generators symbol generators any more but "IAC" for integrated avionics computer - but the function is exactly that of the symbol generator in the ATPL textbook and the CBs are still labelled SG1 and SG2... :-)
... hilarious for an IT professional.
It's not so much the architecture (at the end of the day, the Symbol Generators are what you or I would call a Computer, and the canonical architecture just has switchable screens attached to this Computer) as the naming conventions and the textbook description: the signal generator is described as little more than a thing which magically (in some way not far removed from an analogue instrument) moves symbols around a screen.
The truth of course is that it is a reasonably complex piece of software which runs on a general purpose computer with a whole lot of special purpose serial interfaces. Beyond the ridiculous paperwork requirements, there is nothing particularly special about this software (apart from the almost universally atrocious UIs).
If you were to take my Aspen PFD apart, you would no doubt find an ARM derivative chip and some RAM. This corresponds to the Signal Generator. It also (along with some sensors) fulfils the task of ADAHRS and does some basic sanity checking between different data sources (rather like the ICU in the textbook). On the front there are a number of switches (the "Control Panel") and a screen (both ADI and HSI).
Sure, if any part of that fails the whole lot is useless - but I have backup gyro instruments that will get me back on the ground quite safely.
What suprises me is how long these things have lasted.
I started with the early microprocessors, in late 1970s i.e. a few years after they came out in 1975. Even back then, you would never make a box called a "symbol generator" because all it does is take in serial data containing x,y or radius/angle kind of data, and it generates a raster image, or a vector data stream, in which some hard coded symbols (e.g. the little polygons showing on a TCAS screen) are placed at the right location. It's a function too trivial to put in a standalone box, with massive milspec circular connectors and hundreds of wires going in and out.
The people who designed this stuff in the 1970s were almost certainly ex Gemini, later ex Apollo people, where stuff like sin/cos and x/y/z/400Hz heading interfaces were defined. They could not see better ways of doing it which became very obviously available in 1975. Even 10 years later they were designing stuff using mid-1960s 74 series logic etc. It was great stuff (I loved the ceramic and gold plated hermetically sealed packages) but 15 years out of date even by the time I was doing it.
In 1976, the entire EFIS40 symbol generator could have been done on a 4MHz Z80, on one PCB.
Nowadays an entire system like a G1000 could be done with one half decent processor - if you didn't need modularity for other reasons.
With my GTN650/Aspen setup I get a suitable magenta line on the Aspen when in OBS mode. Surely the Aspen and KLN units use the same data broadcast from the GTN?
I am not suprised the Aspen works with a GTN, because they had to make it work.
I would think the Avidyne MFDs probably work with the GNS boxes, for the same reason. But Avidyne refuse to confirm this (multiple times) re the KLN94 (whose data stream is not same as Garmin's) which doesn't suprise me because the indications I get from various places is that they have no engineers left and contract out most or all R&D now (as do Honeywell/King). I can't settle it short of buying one and doing a bench test, which is actually a whole lot of wiring.
If, hypothetically, you were to wire up a GTN to a KMD550, which data outputs would you use?
As far as I can see, there is only one source of flightplan data which will send either the full flightplan, or an OBS track as appropriate. The only issue would be if the KMD550 didn't support the right leg types (would CF be used for OBS mode?).