On 09/11/09 06:48, dave perry wrote: > I have not flown the patch yet. In this patch, does the region of > reliable signal satisfy Figure 1-1-6 on page 503 of the 2008 AIM? That > figure shows valid signals for two over lapped archs. Arch 1: +\-35 deg > out to 10 nm. Arch 2: +\- 10 deg out to 18 nm. In real IFR flying, you > are always looking for two events as you are intercepting the LOC. #1: > the needle to "come live" with a valid morris code for the LOC, and #2 > the needle to break away from the case (i.e.un-peg). #1 occurs well > before #2 and relates to the AIM figure 1-1-6. #2 relates to the beam > width. It would be great to have both well modelled.
I agree it would be great to have a good model of the localizer signal. There is a market segment that cares about this a lot. As for the details: a) The code I wrote does not closely conform to AIM figure 1-1-6 ... nor should it. Remember the purpose of the AIM is to provide guidance to pilots, to keep them "inside the envelope". The service volume diagram in the AIM is a very aggressively simplified approximation that is _inside_ the envelope but does not define the actual limits of the actual signal envelope. In mathematical lingo, the AIM provides a sufficient (but not necessary) condition for validity of the signal. b) The AIM mentions (but does not diagram) the existence of "extended service volumes". In the real world, this is quite important, because some procedures require you to intercept the localizer more than 18 miles out ... sometimes closer to 50 miles. There is a field in nav.dat that tells the size of the service volume. Navradio.cxx should respect this, rather than making assumptions based on some non- authoritative AIM diagram. The code I wrote respects the nav.dat service volume. c) In the real world, even if you observe that the localizer is alive and IDENTified and not pegged and not flagged, it is _NOT SAFE_ to assume you are within the service volume. There exist _false localizer courses_. There is a maxim that says "trust the instruments" but you shouldn't trust them too much. You can trust an approved instrument approach procedure (IAP) to get you within the service volume before asking you to intercept the localizer, but if you try to "salvage" or "improvise" an approach, the localizer CDI can lead you seriously astray. Having a good model of false localizer courses is an excellent selling point for FGFS. It is good for an instrument student to try following a false localizer course at least once, to gain some appreciation for the threat it poses. Sometimes the instructor can let this happen in the real aircraft, but sometimes it's a lot safer in the simulator. The code I wrote includes an implementation of false localizer courses. d) As for the _range_ of detectability _off axis_, in the real world, that is highly variable, depending on terrain, on the proximity of interfering stations, the quality of your receiver, the quality of your alternator, et cetera. Approximating the range as independent of azimuth should be good enough for now, which is what my code does. If somebody wants to do something fancier, that's fine with me, but perhaps it should wait a week or two, since James wants to "serialize" the flurry of changes. On 09/11/09 09:24, James Turner wrote: >> (I worry that any 'accurate' model will be of fearful complexity, >> especially if it's physically based - clearly we can do line-of-sight >> checks from the aircraft to the navid, but I don't know how much >> beyond that might be necessary. e) An _approximate_ physics model probably wouldn't be very complicated. By way of analogy, note that the physics-based model of the atmosphere is shorter, simpler, and vastly better behaved than the ad_hoc model. OTOH I agree that a detailed first-principles physics model for localizers is out of the question, because of the dependence details that we will never know. In practice the FAA installs the things and then tunes them empirically to optimize the signal. So we shouldn't be ashamed to have a model that is partly physical and partly empirical. ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
