Hi James, Your note below caused me to ask if the LOC needle deflection is scaled differently than the VOR needle deflection in navradio.cxx. It is and the comment that it is 4x more sensitive is correct according to notes from Instrument Ground School. From a pilot point of view, what we need to achieve is 2 deg per dot for VOR and 1/2 deg per dot for the LOC and that should remain the responsibility of the AC and instrument modeler doing the animation. Also, the same ground school instructor indicated that the actual instrument deflection range might vary as long as the deg per dot target was achieved.
The vor.xml and the vor2.xml in Instruments-3D already are correct to the above description assuming degrees for units and the 4X LOC scaling now in navradio.cxx. I don't think it is a good idea to go to a normalized value in a blanket edit of other's instruments as the needle deflection in the animation SHOULD be scaled to achieve the 2 deg per dot for VOR and the 1/2 degree per dot for the LOC. If the navradio.cxx maintains the 4x factor and clamps the heading-needle-deflection to +/- 10 deg, the modeler can use the same scalar for both the VOR and LOC. This scalar will likely vary from instrument to instrument to get the propper dot performance. +/- 0.7 is correct for the glide slope and again the scaling in the instrument will vary depending on the display. Dave P James Turner wrote: > As part of cleaning-up the nav-radio code, I need to make a painful > change: fixing the confusion over GS maximum needle deflection. > > I'm aware that there's problems with the radio reception model, but > I'm not going to attempt to address that at all - what I need to fix > in the short term is a much 'simpler' problem - the confusion over the > range of /instrumentation/nav/gs-needle-deflection. > > Some aircraft (eg, the default C172, and the Primus 1000 suite) are > assuming the range is -10 to +10 degrees (matching the CDI deflection) > - others assume 3.5 degrees (1), or other things again. The Connie is > scaling the property by 1.4, and clamping to +/- 6, for example - > which just about makes sense given the actual range, but no sense at > all if the range is +/-10. > > Hence, this is not about 'fixing' the code in navradio, more picking a > single definition and then fixing panels to follow that definition. > > Here is what I'm going to do: > - change gs-needle-deflection to report the GS deviation *in degrees* > - add a gs-needle-deflection-norm property, reporting the > deflection as the range +/- 1.0 (I'll probably do that for the CDI as > well). 1.0 will be on the peg, 0.0 will be centred - no surprises > here, I hope. > - clamp the GS deviation to +/- 0.7 degrees in the nav-radio code (as > we clamp the CDI deflection to +/-10 degrees). This is significant, > because many panels currently work due to the value *not* being > clamped to any range. I.e there will be a peg at the sim level, not > just a a peg defined at the animation / panel level. > - update ALL the references to the property in the data directory > (that's 273 references, according to 'grep'!) to be consistent with > this. > > For most cases, I'll probably switch to using the normalised property, > to avoid any future confusion (I hope) - and to avoid many scalars in > XML files based upon the 0.7-degree limit. The major benefit of all > this, apart from increased sanity in the code, will be much more > precise GS reporting in many aircraft, I hope. This may lead to end- > users reporting that flying glide-slopes has become 'harder' in some > aircraft (such as the C172) since the sensitivity will have increased > by a factor of three. > > If anyone has a major objection to this, please let me know. If anyone > wants to help with fixing up panels, then *definitely* let me know. > > Regards, > James > > (1) - 3.5 degrees is the value you'd arrive at by examining the source > code - there is the 'magic 5' multiplier that scales the actual > deviation, +/- 0.7 degrees, by 5, in the nav radio code. As far as I > know (and based on comments in the code), no one is really sure why > the multiplier is present. > > ------------------------------------------------------------------------------ > 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 > > ------------------------------------------------------------------------------ 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
