It is the “trading” I am talking about, using the possibly more technical term of Crossfill.
Does the GNS drive Flightstream? I see the advantages for GNS as greater than for GTN (though still great for the GTN, particularly the 650 with its relatively small screen.)
Garmin crossfill sends over just the route, which is one reason both ends need to have the same database version.
Timothy wrote:
Does the GNS drive Flightstream? I see the advantages for GNS as greater than for GTN (though still great for the GTN, particularly the 650 with its relatively small screen.)
I’m told it works with the W versions of the 430/530.
The vertical profile, minima and notes are missing, of course, but that is what i see as the future for EFBs, at which point the concept of the plate becomes moot.
I think I get your drift, but I can’t see this changing in our lifetimes.
The publication of “plates” is a very legalese thing. The invariant presentation has a strong legal and “quality assurance” basis. It’s like asking for metars and tafs to be in plain english.
The plates also trace back to the national AIP plates which are in most cases useless in the cockpit (a UK CAA guy told me this is deliberate, to avoid competing with commercial providers i.e. Jepp!) but which fulfil the ICAO-mandated data publication requirement.
It is actually the case that Jepp plates are vector data, not raster data, but Jepp have never released the rendering code for their data (and AFAIK nobody has ever bothered to reverse engineer it, and IMHO it would be hellishly messy and a total fool’s errand because they often use text fonts for symbols!) so the end result is effectively a raster image.
Whereas if you wrote code which renders the same data with the necessary stuff like auto-rotated text labels, you get into really hard software to de-clutter and de-overlap stuff, and impossible to be sure that on some display device and flying on some heading or track some vital piece of info will end up de-cluttered and kill somebody.
Jepp design their plates with great skill, going back to 800×600 displays and they are 100% legible back then. There is huge human-intelligence skill involved in making a plate readable and still carry so much info and so many notes and warnings.
For enroute data this is different, which is why the synthetic presentations like PFMS and SD and GP etc are popular. But “nobody” will get killed enroute, above the MSA or SSA or whatever, and if they do they sure can’t sue the map provider.
I just don’t think any data provider would have the balls to generate a rotatable vector version of approach plates.
@Timothy wrote:
Firstly, that is exactly what I wanted to know, thank you…so Flightstream does crossfill the SID, STAR and Approach back to GP as you put in the procedures when cleared.
No, sadly it doesn’t work like that yet. We can add a SID or STAR but not an approach to a GP flight plan and send it through the FlightStream Bluetooth gateway to a GTN/GNS. If we then look at the SID on the GTN map, it is depicted correctly. If we look at it on the GP map, it is shown as a straight line from the ARP to the first waypoint in GP’s database. So in the example above, GP’s map shows Prestwick’s NGY1L departure as a straight line from the middle of runway 12/30 to NGY.
Loading the SID in the GTN and sending it to GP doesn’t help; GP still can’t depict it correctly. The same goes for an approach. We can load it into the GTN’s flight plan, but if we send that flight plan to GP the approach is “lost in translation”.
It seems that whereas a GTN will automatically create user waypoints for any waypoints of a GP flight plan which are not in the current GTN database, it doesn’t work for procedures in the other direction. Procedures are defined in a GTN flight plan in such a way that GP can not always display them correctly, not least because it doesn’t do curves and it has no idea where IKK-D4 is, for instance.
For people with a GNS system, the EFB actually acts, effectively, as their MFD.
That’s exactly how I use it with my GTN 650. It’s a sort of poor Galloway farmer’s MFD, notwithstanding the above deficiencies.
Dave_Phillips wrote:
I’m told it works with the W versions of the 430/530.
The Flight Stream 210 works with the GNS430W/530W as well as the GTN and some G1000 systems. The GNS series do not support airways, so they are broken up into waypoints. Up to 99 waypoints are supported in a flightplan. The FS210 connects to the panel via a serial port and to the iPad or other device via Bluetooth. With ForeFlight, there is a setting that allows airways to only be defined by turn points or alternately with all waypoints on the airway. When sending an airway to the GTN or G1000 series, the airway is defined by the entry waypoint, airway name, and exit point. With the GNS system they are sent as a series of individual waypoints that make up the airway, so if you send the route from the ipad to the panel and then back the other way, the airway designation will be lost on the iPad, although the route is the same, just defined differently. User waypoints are converted to latitude and longitudes and are renamed on the panel using a specified naming convention. The name of the user waypoint is lost in translation going either direction. SIDs, STARs and in the case of ForeFlight, Approaches are defined by the name of the procedure, entry or exit point, and if required by the runway designation. Each unit expands the SID, STAR, or Approach based on its internal database specification.
Sending a route to the panel or retrieving the one from the panel is child’s play.
That is all great information, thank you.
It sounds like GP has a way to go to catch up with Foreflight.
NCYankee wrote:
When sending an airway to the GTN or G1000 series, the airway is defined by the entry waypoint, airway name, and exit point. With the GNS system they are sent as a series of individual waypoints that make up the airway, so if you send the route from the ipad to the panel and then back the other way, the airway designation will be lost on the iPad, although the route is the same,
As a side note to this topic, when you include an airway in the route in SD it will automatically break it down into its component waypoints which is very useful, in Europe at least because of the incremental nature of clearances (instead of whole route clearance you get in the US). You very often get cleared to some distant waypoint which may or may not be an intersection or airway turning point.
As a side note to this topic, when you include an airway in the route in SD it will automatically break it down into its component waypoints which is very useful, in Europe at least because of the incremental nature of clearances (instead of whole route clearance you get in the US). You very often get cleared to some distant waypoint which may or may not be an intersection or airway turning point.
Indeed, but “since for ever” people with GPSs which don’t support airways (e.g. my KLN94) have been flying with a proper printed plog which contains all the broken down waypoints, and you keep an eye on it during the flight. This has no electronics to overheat, no batteries to charge, and has an infinite MTBF 
When I used EuroFPL for filing IFR flight plans, they used to send via SMS the decomposed waypoint list, so I had it on my phone. Sometimes, doing an unplanned flight, this was very handy.
And then ATC often give you a waypoint which is off route… That is IME a totally normal thing in Belgium which discards the autorouter-generated route and issues something like KOK-LNO (from vague memory) which is a standard route most of the way across Belgium.
GP has a way to go to catch up with Foreflight
Both have some way to go for Europe and FF probably a lot further.
Some time ago I got contacted by a FF developer (in the UK, oddly enough) who wanted to meet up to get feedback, so I sent him to EuroGA, saying I don’t use these products for IFR anyway. I suspect they find the whole European mapdata generation business just too much work.
Peter wrote:
Indeed, but “since for ever” people with GPSs which don’t support airways (e.g. my KLN94) have been flying with a proper printed plog which contains all the broken down waypoints, and you keep an eye on it during the flight.
“Since forever” I have entirely eschewed paper from my cockpit, even when using a GNS.
The most common reclearance on airways is to a waypoint further down your route, typically on the next FIR boundary (in other words, you fly your planned route as you cross the FIR, but with straight lines between). If I am using a GNS with only turning points loaded, I look on the SD plog for the waypoint, turn roughly towards it, then insert it in the GNS flightplan and DCT to it.
If the waypoint is not on the original route, it makes no odds whether the full route is in the GPS, SD, on paper or anywhere, because you are left searching for it. So I search and do a DCT, then look on SD to see where it most sensible sits in the route and then insert it there on the GPS.
