Here’s a SID and a STAR on GP
That’s a good example. If we zoom in on the first leg, we see that the route (turn right to track 262 and then 268 degrees) from runway to HOL is incorrectly shown as a straight line:
In this case it looks almost OK because HOL happens to be not far off the runway heading, but elsewhere it doesn’t work out like that.
Bottom line is that if we want to follow a SID or STAR on a moving map, we need to look at the GTN/GNS screen, not the iPad.
I have clearly misunderstood Flightstream. I thought the whole point was to crossfill between GTN and GP? In which case, surely the SIDs and STARs (and indeed the approach) would appear in GP?
Timothy wrote:
I have clearly misunderstood Flightstream. I thought the whole point was to crossfill between GTN and GP? In which case, surely the SIDs and STARs (and indeed the approach) would appear in GP?
The below is based on native showing of arrivals in GP. Not flightstream. Does it show them correctly in GP?
Surely crossfill is about route transfer ie the waypoints, airway names, etc.
It won’t transfer the approach plates.
There would be some fun licensing issues with jepp plates.
Peter,
When you load a STAR and an approach into your GPS the whole route, including the STAR and approach, is described as a series of waypoints in the flightplan page, all the way to the threshold and then beyond into the MA and hold.
If that were transferred to GP, or any EFB, it would give you a magenta line incorporating all the procedures. That is what is missing from all EFBs, except Foreflight, where it works out of the box from its own database.
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’m struggling to understand the issue here. For me, I create a FPL on GP and then flight stream it over to the aircraft. I can add SIDs/STARs during FPL creation and when I press “send” this data, including SIDs/STARs etc, is transferred to the GTN750 etc via connext provided that GP has a current Jepp database subscription. It does not work without Jepp. If I keep the Flightstream link active, any change on the GTN (including route change, new/amended SID/STAR and loading of approach) is automatically transferred back to the iPad. I don’t think there is a way for iPad updates to be automatically sent to the GTN but, to me, this makes sense.
But, I’m asking myself, why would I want to be constantly flitting between avionics and my Candy Crush platform whilst in flight? I’ve created a FPL, squirted it into my very expensive NAVAID suite which is then being used as my prime source of information, sending changes to my iPad as the back-up device.
Dave,
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.
The reasons for wanting that to happen are many and varied, but essentially because the EFB carries and presents a lot more information than the PFD/EFIS/GTN and especially the GNS.
A simple example would be graphical NOTAMs, but it might also be weather (from the ADL120 for example), winds aloft and a whole bunch of stuff that you might consider Candy Crush but others might take more seriously. For people with a GNS system, the EFB actually acts, effectively, as their MFD.
So the fact that you have an expensive NAVAID suite does not help everyone; not everyone is in that position.
To clarify, the GTN system only ‘trades’ waypoints/routes, nothing else.
Taking a step into hier-end stuff, our DA62s trade all sorts of data with GP. We have GSR56/GDL88 and consequently can pull up weather, NOTAMs etc on the iPad. However, as you alluded to, this is only really replicating the MFD.
