Any idea why the approach plates are rendered as PDF files, instead of displaying vectorized data? Same with GNS 750.
My guess would be that Jepp didn’t want to release the code for rendering their charts – not even under an NDA.
The data is easily available, on both downloaded and DVD-delivered Jepp products, and if the code escaped into the wild, anybody could produce a program to render their terminal charts, without a license having to be paid for.
I think the Avidyne stuff is all based on an “embedded” version of Windows NT, so rendering PDFs is easy enough. A bit slow perhaps but they can use a decent CPU these days.
I do know that Jepp use not just vectors to draw their charts but also fonts. For example, they might use a dot (a full stop in English, a period in US-English) to draw a solid-filled circle. You discover this when something goes wrong with the fonts on your PC and then the Jepp charts don’t render properly. The text on them is the first thing that goes haywire. It’s a bit of a flakey system which (via the use of fonts) ends up being too-tightly integrated into the operating system. They should have stuck to simple geometric objects for everything.
For my particular requirements, and within the centre stack height limitation, two IFD540s would deliver a much neater solution than one GTN750, so I am keenly waiting for this product to get shaken down by a few thousand American pilots first 
Any idea why the approach plates are rendered as PDF files, instead of displaying vectorized data? Same with GNS 750.
PDF can contain vector data and the Jeppesen approach plates are vector data. There is nothing wrong with PDF and I would most likely use it as well if I was to design an IFD540 like device.
Both, GNS 750 and IFD540 appear not to take advantage of any vector data (if they exist in the PDF). I.e. no de-clutter, font unreadable when zooming out, no rotation of labels when overlaying approach plate on map.
Jepp have never released their terminal charts in a layered form, and I very much doubt they even design them in layers.
To create a terminal chart which is capable of rotation (of text labels, etc) would be a massively complex task and I would say bordering on impossible. Just take a look at a chart like this
and try to work out how to lay out the text so it can be redrawn and be readable when rotated. It would be a huge “artificial intelligence” challenge.
The only way i can see of doing it would be to design two layouts for every chart: one upright and one 90deg rotated CW (e.g.). They would have to redesign all charts for about 10k airports i.e. probably about 100k charts. It isn’t going to happen.
Programs which auto-rotate text labels suffer from this issue to various degrees. The Jepp-FD Ipad products auto rotate the text labels on enroute charts but the result is often crap because the rotated label covers up something else, or moves something out of the way to a place where it looks wrong.
On enroute charts you can get away with it because people expect some level of auto declutter and resulting missing detail, but on a terminal chart nothing can be removed.
It now appears confirmed that the IFD540 contains wifi and bluetooth hardware and that this will be enabled at some unspecified future firmware release. Additional certification will be required. No news about the functionality i.e. a browser or a dedicated app?
Work on European (EASA) STCs has only just started so they could be a long time, especially if EASA’s “performance” on GTN firmware updates is anything to go by.
The smaller IFD440 is claimed to be done end 2014.
EASA were very quick to certify the DFC90 autopilot, it was only a few weeks after FAA certification.
So I wonder what Garmin did to upset them? Maybe they took the EASA official to a bar in Cologne where the entertainment was not sufficiently, ahem, “inclusive”?
But they must have taken him to just the right kind of bar before that, because nobody had ever managed to any any AML STC out of EASA before that. That was an astonishing coup.
On the DFC90, Avidyne prob99 had a parallel process going in Europe. I wonder if Straubing were involved, because there is business there for them.
FWIW: the IFD540 cannot act as a GPS position source for the Garmin transponders to make them radiate ADS-B. The protocol is Garmin proprietary.
Not surprising that Garmin crippled it thus. Even the GTX330 ARINC429 pressure altitude cannot feed the Avidyne TAS boxes and that issue has been around for close to 10 years.
If I install the IFD540 (which I won’t do for about a year, to allow bugs to be worked out) I won’t bother about ADS-B because in Europe it does nothing for me or anybody else.
Even aircraft with TAS systems cannot, in most cases, receive ADS-B. My Avidyne TAS605 is “capable” with a “firmware upgrade” but we know what Avidyne are like on this stuff, and Avidyne have most of the European GA TAS market.
Of all the fish to fry in GA, radiating ADS-B is a very small one.
I spoke to TRIG this year about this and they think the very earliest that ADS-B OUT might be mandated is about 2020-2022.
