Re: [Flightgear-devel] Bug: nav[12] selected radial
Hi Curt are you, or someone else, working on integrating the new apt.dat format as of x-plane 9? --- On Sat, 3/20/10, Curtis Olson curtol...@gmail.com wrote: From: Curtis Olson curtol...@gmail.com Subject: Re: [Flightgear-devel] Bug: nav[12] selected radial To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Date: Saturday, March 20, 2010, 11:19 PM Hmmm, the nav database had the actual radial alignment of the station relative to true north and I remember sorting that out so that when you fly off a chart, everything would be in chart-agreement when you flew to radial intersection points. Bummer if that got broke along the way ... I haven't checked it recently. Curt. On Sat, Mar 20, 2010 at 5: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. We used to have this right in FlightGear, but it's gotten messed up over the last 3-4 years. I'd like to fix it, but I'm worried about how many places we've hardcoded this assumption. How hard will it be to correct this? How many of you have designed radios, autopilots, etc. counting on this bug? Thanks, David -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/ -Inline Attachment Follows- -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -Inline Attachment Follows- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug: nav[12] selected radial
On Tue, Mar 23, 2010 at 1:15 AM, Michael Sgier wrote: Hi Curt are you, or someone else, working on integrating the new apt.dat format as of x-plane 9? A few of us have been in correspondence with Ben Supnik from time to time, but as far as I know, no one within FlightGear has tackled the new x-plane 9 apt and navaid data formats. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug: nav[12] selected radial
On Tue, 23 Mar 2010, Curtis Olson wrote: On Tue, Mar 23, 2010 at 1:15 AM, Michael Sgier wrote: Hi Curt are you, or someone else, working on integrating the new apt.dat format as of x-plane 9? A few of us have been in correspondence with Ben Supnik from time to time, but as far as I know, no one within FlightGear has tackled the new x-plane 9 apt and navaid data formats. Is the 850 spec considered the new apt.dat format? g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.simpits.org/geneb - The Me-109F/X Project ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug: nav[12] selected radial
* Curtis Olson -- Tuesday 23 March 2010: A few of us have been in correspondence with Ben Supnik from time to time, but as far as I know, no one within FlightGear has tackled the new x-plane 9 apt and navaid data formats. The parts of the new format that I have designed (with some input from Ben) should be functional. m. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug: nav[12] selected radial
Curtis Olson wrote: On Tue, Mar 23, 2010 at 1:15 AM, Michael Sgier wrote: are you, or someone else, working on integrating the new apt.dat format as of x-plane 9? A few of us have been in correspondence with Ben Supnik from time to time, but as far as I know, no one within FlightGear has tackled the new x-plane 9 apt and navaid data formats. Fred has modified FlightGear's internal parser accordingly: http://mapserver.flightgear.org/git/gitweb.pl?p=flightgear;a=commit;h=e2c5b0ae5f60fd67a2b5d714a69bf96dce4bb9fa I didn't check if he's supporting linear features as well or 'just' the pavement. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug: nav[12] selected radial
Gene Buckle wrote: Is the 850 spec considered the new apt.dat format? Yup, at least it's the most recent public spec. See: http://data.x-plane.com/designers.html#Formats Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug: nav[12] selected radial
On Tue, 23 Mar 2010, Martin Spott wrote: Gene Buckle wrote: Is the 850 spec considered the new apt.dat format? Yup, at least it's the most recent public spec. See: http://data.x-plane.com/designers.html#Formats Thanks Martin, that's what I thought. g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.simpits.org/geneb - The Me-109F/X Project ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug: nav[12] selected radial
On 20 Mar 2010, at 23:36, Curtis Olson wrote: The nav radio does not work in magnetic headings. It works in which ever alignment the station was setup in. In the 60's when GEP was installed, it was aligned with magnetic north at that time. In the subsequent years, the actual magnetic north has shifted several degrees, but the FAA does not go in and adjust the orientation of the station radials every few months. This would cause all kinds of cascading changes with radials, victor highways, intersection points, etc. Instead, they just leave it where it is. So it's key to align the vor station with the defined offset, not the current magnetic offset ... Sorry, yes, I was aware of this, it's the 'twist' parameter, which comes from the dreaded 'multiuse' column in the nav.dat data. navradio.cxx *does* reference /environment/magnetic-variation-deg, but only as part of the nav-slaved-to-gps option which I will be attacking soon. Form looking at the navradio code, I do *think* the alignment/twist logic is ok: nav[n]/heading-deg is the true heading to the station, computed by wgs84_inverse, and nav[n]/radials/actual-deg is computed as the true heading minus the twist as specified in degrees in nav.data. As ever, I am not a pilot, so I am happy to be corrected, but the above description does fit with my understanding of the real-world situation, and Curt's description above. James -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug: nav[12] selected radial
On Sat, Mar 20, 2010 at 9:41 PM, John Denker j...@av8n.com wrote: 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. Perhaps not, but try this: fgfs --ndb=YRR --altitude=3000 --vc=100 --nav1=340:114.6 When it starts, the radial on the nav1 indicator will be set not to 340 but to the true equivalent (around 326). When you start at an airport, the radial will be aligned with the runway no matter what you put on the command line -- that's probably the GPS bug. All the best, David -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Bug: nav[12] selected radial
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. We used to have this right in FlightGear, but it's gotten messed up over the last 3-4 years. I'd like to fix it, but I'm worried about how many places we've hardcoded this assumption. How hard will it be to correct this? How many of you have designed radios, autopilots, etc. counting on this bug? Thanks, David -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug: nav[12] selected radial
Hmmm, the nav database had the actual radial alignment of the station relative to true north and I remember sorting that out so that when you fly off a chart, everything would be in chart-agreement when you flew to radial intersection points. Bummer if that got broke along the way ... I haven't checked it recently. Curt. On Sat, Mar 20, 2010 at 5: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. We used to have this right in FlightGear, but it's gotten messed up over the last 3-4 years. I'd like to fix it, but I'm worried about how many places we've hardcoded this assumption. How hard will it be to correct this? How many of you have designed radios, autopilots, etc. counting on this bug? Thanks, David -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug: nav[12] selected radial
It's actually even more confusing than that: the initial value seems to depend on whether the --vor option is selected, what the heading is, etc. All the best, David On Sat, Mar 20, 2010 at 6:09 PM, David Megginson david.meggin...@gmail.com 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. We used to have this right in FlightGear, but it's gotten messed up over the last 3-4 years. I'd like to fix it, but I'm worried about how many places we've hardcoded this assumption. How hard will it be to correct this? How many of you have designed radios, autopilots, etc. counting on this bug? Thanks, David -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug: nav[12] selected radial
On Sat, Mar 20, 2010 at 6:19 PM, Curtis Olson curtol...@gmail.com wrote: Hmmm, the nav database had the actual radial alignment of the station relative to true north and I remember sorting that out so that when you fly off a chart, everything would be in chart-agreement when you flew to radial intersection points. Bummer if that got broke along the way ... I haven't checked it recently. It would take hours to sort out the code to see what's actually happening. The new init functions make things even more confusing, by including strange side effects (for example, setting the heading now sets the azimuth to a VOR or airport, and may also set the selected radial on a VOR). I used to help a lot with this stuff, but I don't think I have the energy now. All the best, David Curt. On Sat, Mar 20, 2010 at 5: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. We used to have this right in FlightGear, but it's gotten messed up over the last 3-4 years. I'd like to fix it, but I'm worried about how many places we've hardcoded this assumption. How hard will it be to correct this? How many of you have designed radios, autopilots, etc. counting on this bug? Thanks, David -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug: nav[12] selected radial
On 20 Mar 2010, at 22:24, David Megginson wrote: It would take hours to sort out the code to see what's actually happening. The new init functions make things even more confusing, by including strange side effects (for example, setting the heading now sets the azimuth to a VOR or airport, and may also set the selected radial on a VOR). I used to help a lot with this stuff, but I don't think I have the energy now. There's another bug (in 2.0.0) to do with the GPS interaction with the nav[0] selected radial - I must say I've assumed all problems with --nav1 options misbehaving are ultimately caused by this bug, but it sounds as if you think there's worse things going on. It would help to explicitly define what the desired behaviour of the options is - and obviously, the nav-radio should work entirely in magnetic headings. As the person most recently hacking the navradio code, I think that's still more-or-less the case, but some bugs have presumably crept in along the way. (I tend to test around my home airport, EGPH, where the magnetic variation is not very noticeable compared to many other parts of the world) James -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug: nav[12] selected radial
Hi James, The nav radio does not work in magnetic headings. It works in which ever alignment the station was setup in. In the 60's when GEP was installed, it was aligned with magnetic north at that time. In the subsequent years, the actual magnetic north has shifted several degrees, but the FAA does not go in and adjust the orientation of the station radials every few months. This would cause all kinds of cascading changes with radials, victor highways, intersection points, etc. Instead, they just leave it where it is. So it's key to align the vor station with the defined offset, not the current magnetic offset ... Regards, Curt. On Sat, Mar 20, 2010 at 6:22 PM, James Turner wrote: On 20 Mar 2010, at 22:24, David Megginson wrote: It would take hours to sort out the code to see what's actually happening. The new init functions make things even more confusing, by including strange side effects (for example, setting the heading now sets the azimuth to a VOR or airport, and may also set the selected radial on a VOR). I used to help a lot with this stuff, but I don't think I have the energy now. There's another bug (in 2.0.0) to do with the GPS interaction with the nav[0] selected radial - I must say I've assumed all problems with --nav1 options misbehaving are ultimately caused by this bug, but it sounds as if you think there's worse things going on. It would help to explicitly define what the desired behaviour of the options is - and obviously, the nav-radio should work entirely in magnetic headings. As the person most recently hacking the navradio code, I think that's still more-or-less the case, but some bugs have presumably crept in along the way. (I tend to test around my home airport, EGPH, where the magnetic variation is not very noticeable compared to many other parts of the world) James -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug: nav[12] selected radial
On Sat, Mar 20, 2010 at 7:22 PM, James Turner zakal...@mac.com wrote: There's another bug (in 2.0.0) to do with the GPS interaction with the nav[0] selected radial - I must say I've assumed all problems with --nav1 options misbehaving are ultimately caused by this bug, but it sounds as if you think there's worse things going on. Actually, I think that might be it. It's hard to experiment right now, because I'm in Lucid with the slow open source driver until the ATI proprietary drivers come out, so start-up time takes forever. (I tend to test around my home airport, EGPH, where the magnetic variation is not very noticeable compared to many other parts of the world) We're around 14W here -- just enough to notice. All the best, David -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug: nav[12] selected radial
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. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug: nav[12] selected radial
SInce this is related , I'll ask here . I've got a 2 pointer RMI well under way , and according to the few documents I found , the RMI gets its input from the ADF and Nav receiver ... it doesn't do the calculations itself. So is better to NOT to use the /nav/heading-deg ? Cheers -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
