I am confused... what the heck is a "reversible ILS"? In 25 years as an instrument pilot and over 20 as an instrument instructor--I've never of such a thing. Localizer beams are not "reversible." They are horizontally polarized, but not reversible.
Reference the FAA Instrument Flying Handbook, at this link: http://www.faa.gov/library/manuals/aviation/instrument_flying_handbook/ Check out Chapter 7, pages 7-37 thru 7-39, but let me summarize here... The localizer antenna for a given runway is located some distance ('x') off the *departure* end of that runway. This distance, x, is determined by the length of the runway, so that the width of the localizer beam (which is usually 5-degrees) is 700 feet at the approach end of the runway. But the important thing to remember here is that the beam is also directed out the other end of the runway...along the departure path. There's a diagram on page 7-38 that shows this. While I admit that I haven't read each and every post in this thread, I have read enough to see that the importance of this may not be appreciated by all in this discussion. In a nutshell--an "ILS approach" is a *precision* approach, meaning there is lateral guidance from the localizer (LOC), as well as vertical guidance from the glideslope (GS), and various approach lights that are integral to the approach. Without *any* component, then the ILS approach is no longer do-able, technically speaking. But an aircraft using the other end of the runway can still use the same localizer--they would see reverse sensing on the indicator needle in their cockpit (unless an HSI was used, and then the device could be adjusted so that it would always be normal sensing). As an example, let's say an aircraft is 5 miles out on the ILS RWY 36 approach at Oshkosh Wisconsin. With the NAV receiver tuned to 110.5 MHz, the pilot would "fly to the needle" and track the localizer inbound. When they reached the GS intercept point, they could start down, but let's say they ignored the GS and remained level at 2000 feet AGL. As the aircraft got closer & closer to the approach end of runway 36, the needle on their indicator would be more & more sensitive (as the beam is getting narrower and narrower), until the aircraft flew reached the LOC antenna, located approximately 1000 feet past the *departure* end of the runway, in most cases. But at that point, the signal persists--nothing happens other than the indicator in the cockpit indicates reverse sensing, because of the horizontal polarization inherent to the LOC signal. So the pilot simply uses reverse sensing, and now "flies the needle to the ball," instead of the ball to the needle, as on the front course. This reverse-sensing area on the "backside" of the LOC antenna is known as the "back course," while the signal directed from the LOC antenna back towards the approach end of the runway is known as the "front course." So where this concept of switching off an ILS transmitter in the tower came from, I don't know. I can assure you that in many years of flying IFR--I never had this happen. There were many times I flew into KOSH IFR after the tower was closed for the night--and ALL approach transmitters were active. When there is no wind, you're free to use whichever instrument approach you see fit, as YOU are the expert at that point. If the tower is open and there are certified meteorlogic observers on site...then you use the approach they tell you, or you request a different approach. If they can, they'll give it to you (depending upon traffic conditions). But they don't have to turn it on or off--that just doesn't happen as far as I know. I hope this long-winded post has helped to clarify some of the misconceptions that seem to be flying around here in this thread. Maybe I have entirely missed the point here, and if so then I apologize. But there is simply no "on/off" switch for an ILS that is activated by the tower--at least none that I've ever seen. Maybe they have the capability to turn the transmitter on or off from the tower-- but I have never seen them do this. In fact, all of the times I've seen the LOC go down for maintenance, a ground maintenance vehicle has to go out to the transmitter shack and turn the LOC off. But each LOC on an airfield has it's own frequency, and you simply tune your NAV receiver to it to use that particular approach. In my previous example, you could in fact shoot a LOC BC (back course) approach for RWY 18, simply by using the localizer frequency for the RWY 36 approach and using the published procedure for the LOC BC RWY 18...if there was one. Or you could tune to a *different* LOC frequency and shoot a "front course" ILS RWY 18 approach--if that was a published option at that particular airport. In that case there would be two localizers on that particular runway--one for the front course of either runway (18 or 36). This would be done if there was a need for a precision approach on both ends, versus only the need for a precision approach on the front course, and a non-precision approach on the back course end. TB On Sep 15, 2009, at 7:15 AM, John Denker wrote: > On 09/15/09 03:25, James Turner wrote: > >>> I suspect penaltyForNav is broken, probably by me - so that's >>> where I >>> shall look next. > >> This is 'fixed' now > > Thanks. > >> - except it's not. > >> penaltyForNav is basically broken - we all know it's broken >> conceptually, but it's also broken in practice, because it doesn't >> even do what it claims > > Agreed. It makes no sense. > >> (and never has, that I can see) > > Agreed. It has been broken for many years, probably > since Day One. > >> - bias to >> directional transmitters based on aircraft *heading*. The problem is >> it's biasing based on *bearing* from the aircraft to the transmitter. > > Neither of those things is realistic. In real life, > the reversible ILS transmitter is controlled by a > switch in the ATC tower, switched to match the choice > of active runway, which in turn is normally based on > the _wind_ ... not on the position or heading of any > particular aircraft. > >> The fix is sort of a work-around (but also a correctness >> improvement); > > Improved but still highly unrealistic. It is only a > very rough placeholder, pending a decent solution. > > Constructive suggestion: Seriously, unless/until we > can do a reasonable job of switching the reversible > ILS, it would be better to not switch it at all. In > particular, it would be better to just settle on one > end or the other and stick with it for the duration > of the simulation. I would initialize it randomly > during startup, and leave it alone thereafter. This > would create a 50/50 chance of having to shoot a the > ILS with a tailwind and then execute the circle-to-land > procedure ... which is good practice anyway. > > If you make the switch visible in the property tree, > on a per-navaid basis, anybody who really cares can > go in there and throw the switch the way he likes. > > Having navradio.cxx throw the switch in mid-flight, > based on completely bogus criteria, is really, really, > really not appropriate. > > ======================== > > What's worse is that all of the above is only the > tip of the iceberg. The iceberg as a whole is what > I call "nontrivial external situations". > > Here is another example of what I'm talking about: > Suppose there is a multiplayer situation where > there are N aircraft, each of which has one DME and > two ILS receivers, all tuned to the same station. > If we expect each nav radio to synthesize its own > IDENT signals, there are then 5N different IDENT > signals, all unsynchronized. This is unrealistic, > because in real life there is only IDENT signal, > synchronized across all three transmitters (LOC, > GS, and DME) ... so the received audio will be > perceived as synchronized across all 5N receivers. > > Similarly all N aircraft should receive the same > audio, synchronized, from any ATIS transmitters. > > Similarly, to return to the topic that started > this thread, all N aircraft should see ATC make > the same choice as to which end of a reversible > ILS is in use. > > Similarly, ATC should turn on the runway lights > and approach lights for the runway in use, at > night and during marginal weather. The lights > for other runways should be turned off. All > N aircraft should see the same set of lights. > > Similarly all N aircraft should see the same > "AI traffic". > > As far as I can tell, the simplest and best > way to implement this is to have, at least > conceptually, N+1 agents, i.e. N+1 processes: > one for each of the N aircraft, doing the > usual FGFS aircraft related functions, plus > one representing what's going on outside the > aircraft, including weather, ATC decisions, > IDENT signals, AI traffic, et cetera. Call > this the "external" process. > > I'm not sure about the implementation details. > In an MP situation, the external process could > be implemented on the MP server. Or all N > aircraft in a given MP session could get > together and elect one of the aircraft to > implement the external functions and serve > them to the other N-1 aircraft. Or all N > aircraft could do all of the external > calculations, redundantly, provided they > synchronize all of the relevant data so that > all copies of the calculation get identical, > synchronized answers. (Identical is easy; > synchronized maybe not so easy.) > > === > > I realize that doing a good job of implementing > the external process is not easy. > > In the meantime, though, we should try to put > in the hooks to make such a process possible > in the future. That is, low-level routines > such as navradio.cxx should not be making > high-level decisions, such as ATC decisions > about which runway is in use. > > > ------------------------------------------------------------------------------ > 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
