Well, then indeed...you're going to have to implement a textbox-style warning to the user that there may be a potential conflict at those airports. You're correct about there being an issue with making the back-course reverse sensing, when the published approach plates indicate that it shouldn't be. That would be a problem. But remember that precision approaches need to have a specified LOC width at the approach end of a runway--thus the LOC antennas are located off the departure end of the runway the required distance (as practical) to fulfill that requirement. Of course the LOC beam width can be adjusted to accommodate this, to some degree. That begs another question then though--is this accounted for in FG at present? I haven't tested it, but maybe John has.
I still think an acceptable solution is to hit the user with a textbox message, advising them of the potential conflict. While Elite has apparently gone away from having it on the pilot's screen (and thus interrupting program execution) in their current software, the new "improved" way provides for the feature on the instructor's screen in the enterprise-level software. But I don't see how you'll get around program interruption in the case when the pilot is using the software independently--who else is going to make the choice? And as for an automatic choice, based upon aircraft position, heading, or bearing from the station--this will be problematic as John mentioned. Pilot's are often required to tune NAV frequencies well before arriving at the initial approach fix (often the outer marker), and thus there's no way sufficient generalizations can safely be made regarding the approach they intend to use. For example, suppose an aircraft is approaching an airport from the south, but needs to use the ILS RWY 18. If RWY 36 uses a "reversible ILS" (weird term, and I still don't think I've ever heard it before...) and they tune to that frequency, then the only way for them to know which approach they were actually tuned in to would be the morse identifier (as John suggested). So John, are these 202 runways world-wide (I saw EGPH on the list, but the rest were in the US); and do you know if all of the ILS approaches on those runways are currently supported in FG? I suppose you could just fail to support the ILS for one half of those runways, although it wouldn't be a very popular decision with the users I'll bet. So if you must support the approach and cannot employ sufficient logic to make decisions as to which runway to (automatically) select when one of those frequencies is selected--then about the only option you have left is to ask the pilot which runway they intend to use... It might just be crazy enough to work. TB On Sep 15, 2009, at 10:17 PM, John Denker wrote: > Hi Folks -- > > Of the 3050 ILSs in section four of my copy of nav.dat, > 404 of them, i.e. more than 13% of them, are reversible. > That's 202 pairs, if you want to count by pairs. > -- In all such pairs, both ends use the same frequency. > -- In all such pairs, the two ends have different IDENT > codes. > -- In all such pairs, the localizers face in opposite > directions. > -- In all such pairs, with two dubious exceptions, the > localizers are documented to be more than 1km apart. > > Here are a few examples > Airport freq LOC-LOC distance > EGPH: IVG 06 == ITH 24 (108.90) 1.817 nm > KJFK: IHIQ 04L == IIWY 22L (110.90) 1.646 nm > KJFK: ITLK 13L == IRTH 31R (111.50) 1.953 nm > KLAX: IGPE 06R == IHQB 24L (111.70) 2.044 nm > KLAX: IUWU 06L == IOSS 24R (108.50) 2.099 nm > KLAX: IMKZ 07R == ILAX 25L (109.90) 2.270 nm > KLAX: IIAS 07L == ICFN 25R (111.10) 2.263 nm > KPHL: IPHL 09R == IGLC 27L (109.30) 2.065 nm > KPHL: IVII 09L == IPDP 27R (108.95) 1.898 nm > > The whole list can be found at > http://www.av8n.com/fly/reversible.txt > > There are several reasons why the two ends of such a > pair must be considered _different_ ILSs, and cannot > be operated simultaneously: > 1) First of all, you have to ask where the localizer > transmitter sits. The rule is that they sit a little > ways beyond the departure end of the runway. If you > tried to use a transmitter at the departure end of > runway 6 to serve approaches to runway 24, the LOC > course width would go to zero long before you reached > the threshold of runway 24. There is no way this > would go unnoticed. Also, locating the localizer > transmitter at mid-field is out of the question. > 2) Secondly, if you tried to serve two reciprocal > runways with the same localizer, one or the other of > them would be reverse sensing. There is no way this > would go unnoticed. > 3) If you tried to operate two transmitters at the > same time, they would interfere. In particular, the > outbound (missed approach) segment of one would ruin > the inbound (final) segment of the other. Also there > would be no way to make sense of the IDENT. > > And FWIW, I have experienced this first-hand. Sometimes > a student is capable of forming an unshakable expectation > that he will be using runway 6 right. He has the > approach plate already out. He listens to the ATIS, but > ignores the part about "landing and departing runway two > seven left". He IDENTifies the ILS, hears "some" code, > and assumes it is the right code, even though it's not. > I tell him to double-check the IDENT, whereupon he > double-checks the frequency, and sure enough the frequency > is right. He has a real hard time getting established > on the localizer, because it is reverse sensing ... not > to mention various other problems. I explain to the > long-suffering controller that my student got out the > wrong approach plate, and we need to go hold somewhere > and sort things out. The student overhears this, and > still doesn't understand what went wrong, because he > is absolutely sure that there is no such thing as a > reversible ILS. > > In contrast, a skillful instrument pilot does not really > need to know or care about reversible ILSs, because the > wording of the ATIS and the wording of the clearance > suffice to tell him which approach plate to use. > > I remark that section 4-7-13 of FAA 7110.65P, which > specifies the duties of air traffic controllers, briefly > mentions some procedures for "Switching ILS/MLS Runways". > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart > your > developing skills, take BlackBerry mobile applications to market and > stay > ahead of the curve. Join us from November 9-12, 2009. Register > now! > http://p.sf.net/sfu/devconf > _______________________________________________ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
