Well, there is no LPV data block produced if there is no LPV 
AFAIK all these “DIY ILS” procedures are done by drawing a straight line from FAF to MAP. That is what GPS-ILS does (which is why it probably never matches a real ILS if you fly it at an ILS airport).
The reason is that it is the only readily usable data which is published openly. The design of a real LPV or a real ILS trajectory involves more complications – search here for TERPS or PAN-OPS. NCyankee has written some great posts on the topic.
Peter wrote:
AFAIK all these “DIY ILS” procedures are done by drawing a straight line from FAF to MAP.
Actually to a TCH of 50’, not the MAP. It should be 40’ for short runways, but I think it’s always 50.
The Garmin Visual Approach also takes into account terrain and obstacles.
I wonder what is in a FAS Data block that exceeds how a Visual Approach is calculated? Which element is not taken into consideration? I honestly don’t know, and am genuinely interested.
As far as I can tell, there is nothing magic about a FAS Data Block, and the calculations are not complicated. I suspect, though I am not certain, that every element of the FAS DB is calculated “on the fly” in real time when you select an approach. There is not, nor cannot be, anything in the Jepp database directly pertaining to the approach, but every required element (runway azimuth, runway length, terrain, obstacles etc etc) is in there. HAL and VAL are presumably constants.
It would be very interesting to know how a FAS DB would make any difference to the actual performance.
Please someone, educate me.
The LPV hex data block is published in the AIP.
The LPV hex data block is published in the AIP.
Yes, indeed. Does that address the points I made?
Every element of the FAS DB is either published separately in the AIP (eg threshold co-ordinates, azimuth and length), available (by calculation) from the terrain and obstacle databases, standard (eg VAL, HAL) or standardised by Garmin (eg slope).
Obviously I don’t know how the software works, but, if I were designing it, I would use the same module as the LPV, and calculate a hex DB that looked exactly the same as one derived from the AIP as input parameters.
There is even a tiny argument that the Visual FAS DB has the benefit over the AIP FAS DB in that the obstacles are updated every eight weeks rather than annually/biennially.
The very big disadvantage of the Visual approach, and that Garmin will surely address in later versions, is that the slope does not match the PAPI/VASIs but is set to 3°. I guess that that is because PAPI angle is not in the Jepp database in its own right, but at the very least they could allow us to in increase it. If that increase were then to allow more slopes to be activated because they exceeded obstacles/terrain by a greater margin, then even better.
On rereading this, I see a possible source of confusion.
On an LPV approach, of course the GTN (and any other 146() navigator) will use the database FAS DB.
I am only talking about probable emulation when creating a Visual Approach from AIP/Jepp DB data in the absence of a published FAS DB.
To get back to the original post, is the answer “all LNAV/VNAV approaches do not work in the UK”?
Peter wrote:
Welcome to EuroGA, TonesTaxis
Thank you
Timothy wrote:
If you go to other places in the UK, eg Cranfield, Gloucester which have LNAV approaches, you’ll almost certainly get LNAV+V, and if you go to Alderney you’ll get LPV. If you go to somewhere in France with LNAV/VNAV, you’ll also get a slope.
Timothy, thanks – this really clears things up. I had no idea that if there is only an LNAV minimum then LNAV+V would be there, as I only checked EGSC and EGSS (both with LNAV/VNAV minima) before giving up. As you say, Cranfield does indeed show LNAV+V in the PROC pages, so I’m now convinced that the GTN is set up correctly.
Timothy wrote:
This is all down to typical CAA arse-covering, where they promote a tiny issue (the possibility that SBAS VNAV may not exactly match Baro-VNAV) above the much bigger issue of turning a 3D approach into a 2D one.
It does seem ridiculous that if an approach has been certified to LNAV/VNAV minima, then the GTN actually gives less vertical guidance than that of an approach certified to LNAV minima. Classic CAA I suppose – I just wonder how long it will be until they see some sense?
Incidentally, I assume it’s coding within the GTN database (which I understand is created by Jeppesen) that prevents LNAV/VNAV showing in the UK on the GTN? That is to say, if the CAA finally come round to allowing these approaches with SBAS instead of Baro Aided information, it could be updated in the database and the feature would be available in the next cycle?
Peter wrote:
To get back to the original post, is the answer “all LNAV/VNAV approaches do not work in the UK”?
As far as I understand it, if you’re in the UK and look at the approach plate minima you will get the following on the GTN;
If you’re in the EU, then all bets are off but I understand the difference would be;
Only an LPV is a 3D precision approach, with the data block sufficiently robust that the GNSS system is sniffing down the final approach track like a truffle hound. The unit is also monitoring for 3D LPV Loss of Integrity.
Only an LPV is a 3D precision approach, with the data block sufficiently robust that the GNSS system is sniffing down the final approach track like a truffle hound. The unit is also monitoring for 3D LPV Loss of Integrity.
Do we know, one way or another, whether that’s true of a Visual Approach?
It may just “come up with the rations” if they re-use LPV code.
It’s part of IFR procedures that an IFR approach has to be loaded from an IFR current database, but then you knew that :)
I doubt, but don’t know, if they load the LPV data block, but the LOI logic wouldn’t work because it never announced you were on an LPV in the first place. You may get a loss of GPS signal, but this applies to 2D approaches as well.
