From: John D. <js...@av...> - 2010-03-21 01:41:47
|
On 03/20/2010 03:09 PM, David Megginson wrote: > There's a bug in the /instrumentation/nav/radials/selected-deg > property: the code mistakenly assumes that the selected radial is in > true degrees, but isn't a bearing -- it's just a number. You could > design a VOR where radial 180 was north of the VOR, if you wanted to > (though usually it's close to a bearing in *magnetic* degrees). The > bug affects the --nav1 and --nav2 option in particular, since > > --nav1=340:114.6 > > will no longer start FlightGear with the Nav1 indicator dialed to the > 340 radial, unless the local magnetic variation happens to be 0. At > CYRO, for example, the actual radial ends up being closer to 326, > which is counterintuitive. Nav radios and indicators know nothing > about magnetic variation. I am unable to reproduce this issue in the default c172p. I just did an in-flight VOR receiver check, using standard pilot procedures in accordance with FAR 91.171. I went to SUTRO intersection, dialed up the 287 radial of the SFO VOR, and verified that the needle was (a) properly centered and (b) properly sensitive to OBS changes. I used: --fix=STINS --nav1=287:115.8 --nav2=287:115.8 and I verified that the OBS cards did in fact get set to 287. > We used to have this right in FlightGear, but it's gotten messed up > over the last 3-4 years. There was a bug reported under the Subject: [Flightgear-devel] Setting OBS on command line/.fgfsrc a couple of weeks ago ... but it only affected nav1 IIRC. And it had nothing to do with magnetic variation IIRC. There are some creepy bugs associated with navradio.cxx and with command-line processing ... but this magnetic variation issue is not easily reproducible chez moi. This is with freshly pulled and compiled sources from a few minutes ago. The issue was equally non-observed using sources from two weeks ago. |