ILS/OM, MM, IM at beach airports.

[Lump Jockey]

Are there OM/MM/IM for runways where the extended centre line is out at sea, such as Saint Maarten or Raratonga? And does the ILS work in the same way?
LJ.

[HEATHROW DIRECTOR]

Marker beacons at many ILS facilities have been withdrawn with the advent of DME associated with ILS installations. Speaking for Heathrow, it must be well over 15 years since the markers were withdrawn.

I flew into Raratonga last year and saw no sign of any marker beacons on the sea.... mind you, I was distracted by certain more interesting sights!

I expect someone more knowledgeable will answer..

[604guy]

Stand to be corrected but not aware of ever being IM's in Canada. MM's disappeared in the early '80's and OM's in the early '90's. I remember a bit of a fuss when the MM's were being withdrawn. This happened a few years after most ILS DH's being lowered from 300' to 200' in this country. The fuss was associated with some of the older generation flight directors (FD 108? comes to mind) that utilized a feature G/S EXT, glideslope extension, that was triggered by the MM flashing that "dampened" (things are bit fuzzy of the specifics) the F/D cues when going through 300' AGL. Things could get a bit aggressive otherwise.

To answer your original query though......no markers .....nill effect on ILS function.

[411A]

FD105 had the problem referred to...don't believe the FD108 was affected.

And yes, the old timers about had a fit.:p

[tiermonde]

St Marteen just has a VOR-DME approach but others such as Vancouver which has ILS approches over open water use DME instead of a beacon to fix the FAF.

[alf5071h]

Where an ILS approach has no outer marker or where the marker has been deliberately replaced by DME, what procedures are there for an ‘outer marker’ check height?
Do the charts indicate a specific checkpoint and/or altitude, or is this left up to operators?
Do the new charts have tables of range vs altitude for these types of approach?
Are there similar problems for self-constructed VNAV non-precision approaches; is an ‘outer maker’ concept used or is the range/altitude continuously monitored during the approach?

[HEATHROW DIRECTOR]

alf5071h by "check height" I imagine you are referring to aircrew matters, but just in case - for ATC where no markers exist pilots are asked to report at a particular DME range - 4DME is about where the old OMs used to be.

[OzExpat]

The ILS charts here identify an altimeter checkpoint at a specific DME distance. Additionally, there is a tabulation of DME distance and altitude for each NM from the Final Approach Point. This helps pilots to monitor glideslope accuracy all the way through the precision approach segment.

[alf5071h]

HD, my interest is to avoid CFIT incidents / accidents, and the requirement for crew to have and use a check height. ATC assistance is always welcome; however, range calls, particularly on Non Precision Approaches (NPA) could give crews a false sense of security unless there is a corresponding check of altitude.

OZEx, thanks for the ILS info, this is as I had hoped, however the hazards of NPAs remain particularly for those procedures without DME.
In addition, there could be a further hazard when the crew defines a continuous descent path using VNAV, i.e. an error in waypoint entry, and they commence the descent early. The EFIS display of VNAV path is very ‘ILS like’ and thus very compelling; maybe some crews fly a VNAV approach like an ILS. Yet apparently there are no other means checking the progress of a VNAV NPA other than at MDA, it is an open loop procedure.
In extreme circumstances with a very early descent, the flight path could be below an intermediate platform/check altitude defined in the originating NPA. Thus, it appears many of the benefits of a continuous descent are lost, but of course this is applies to most procedures when human error is considered. Therefore, perhaps crews should use a double check procedure when manually entering VNAV waypoints, or only use database procedures.

The draft JAA Notice of Proposed Amendment NPA-OPS 20 (http://www.jaa.nl/catalogue/npas.html) relates to the introduction of continuous descent approaches, it will require operators to have procedures to circumvent errors such as above. The obvious procedure is to use distance to waypoint to check altitude, but of course, a waypoint error could be the source of any flight path error and thus not show any offset. I am seeking some safety defences.

[OzExpat]

I've never even toyed with VNAV alf, so I can't answer your question directly. Best I can offer is that, as part of our GNSS Implementation program, I'll be investigating the viability of Baro-VNAV procedures. These procedures will undoubtedly incorporate coded waypoints in the database that have been derived from survey data and verified by flight checks. Thus, the resultant procedure will provide a tabulation of altitude versus distance that can be used for continuously monitoring the descent.

As for NPA procedures where DME is not available, I'll go out on a bit of a limb here and say that - subject to a few considerations - it should be possible to fly the NPA as a CANPA. Had we not decided to go with GNSS implementation here, I would've gone to CANPA using a GPS reference point. I justify this on the basis of a thorough RAIM study conducted here, some years ago, by the Volpe Institute and a study done in Australia (and a few other places), which showed conclusively that the fix tolerance for a GPS-derived distance fits well within the final approach protection area for a Pans Ops designed NPA.

Therefore, a FAF could be fixed at a distance from the reference waypoint and, again, a "altitude versus distance" tabulation could be provided for pilots to monitor the descent.

I think it would be most unwise for pilots to try their own version of CANPA on a NPA without DME, unless the specific State's regulator has done their homework in the same way as we have. And then, they'd have to provide a formal approval process of some sort. Without any of that, pilots have little choice other than to use "dive and drive" on a single navaid NPA because they will never really know exactly how many track miles are available for descent on final approach.

[alf5071h]

OzExpat thanks, in general I agree, but I would never to go back to dive and drive as the last resort.
Unfortunately, some states allow operators to build their own VNAV approaches based on non-precision approaches; JAR-OPS apparently will allow open VS or FPA descents from FAF waypoints.
A key safety procedure, which you allude to, is the provision of "altitude versus distance" tabulation, but unless the distance information is independent of the VNAV construction and/or the crew use this information (human error), then VNAV CANPA is no better (safer) than any other form of approach. Of course crews should calculate the required VS and expected time to MDA/MAP, they don’t? Human error.

I suggest that a specific check of altitude / distance at a named point should be introduced for these procedures to force the crew to take note of range and altitude. This follows the concept of the OM check, which the crew would be familiar with and is something that should catch gross errors i.e ILS false beams, radio interference, etc. GNSS VNAV may not suffer from these problems, but there are many old errors and possibly some new ones to catch the unwary.

[OzExpat]

We're probably getting a bit far off the topic here alf in respect of single navaid non-precision approaches. However, as you have raised the issue of not to "drive and drive", I'd suggest that there's not always a lot of alternative. Classic case from this part of the world is a VOR or NDB at the wrong end of the aerodrome for the only possible straight-in approach.

The base turn procedure is longer than normal because of the need to provide a reasonable length for the final approach segment. Sure, you make a reasonable calculation of time and ROD to work out a profile descent but, in absence of a FAF, you'll never really know how the profile is actually working out. There are, of course, three possible scenarios here.

Everything works out exactly right, with nothing to worry about. I don't know about you but, for me, this is really more like a "hit or miss" type of scenario. I've seldom seen this work in practice because there are too many things that can go wrong.

Descent profile is wrong and you end up too high to reach the MDA before the MAPt (let alone before the VDP!). The implication here is too obvious.

Descent profile is wrong and you end up at MDA in level flight to the MAPt, or VDP. This is, of course, the "dive and drive" scenario.

And, of course, you'll never know your VDP without some sort of distance reference.

Like most pilots around here, I use GPS as a backup for distance. I select the relevant navaid from the database and base all my calculations on that, making due allowance for the approximate distance from the navaid to the threshold. It's pretty rough and ready but normally works out reasonably well here because we don't get a lot of wind effect.

However, you need a lot of confidence in the distance information from the GPS (bearing in mind that it's operating in enroute mode at the time). You also need some caution and a fair bit of good gut instinct. Without all of that, I'd suggest that there are places in the world where a single navaid procedure can only be flown as "dive and drive".

As for Baro-VNAV, this is closer to the topic because these procedures have a Decision Altitude. This is because they have a glideslope. For these reasons, a check altitude is always needed for these procedures.

It is even more important to catch glidepath errors in a Baro-VNAV procedure because the glidepath is generated barometrically. This introduces a complication that doesn't exist in a precision procedure, but is catered for in the design of the procedure and the specification of a temperature range within which the procedure is usable.

There is, of course, no OM, MM or IM associated with this type of approach, but there is a distance reference, so I guess that brings us back on topic. At least for a while! :D