Re: [Flightgear-devel] [Simgear-cvslogs] CVS: SimGear/simgear/math SGGeod.cxx, 1.1, 1.2 SGGeod.hxx, 1.10, 1.11 SGQuat.hxx, 1.16, 1.17 SGVec2.hxx, 1.7, 1.8 SGVec3.hxx, 1.20, 1.21 SGVec4.hxx, 1.14, 1.15
On 8 Sep 2009, at 03:59, Tatsuhiro Nishioka wrote: I've tried, on my Mac OS 10.5/Xcode 3.1.1, FG/SG as of both Sep-06 and Sep-07 (without -DNO_OPENSCENEGRAPH_INTERFACE option) and all have worked fine so far. The issue went away following further CVS updates - I guess it was the updates for Mathias to the rest of FG. That still doesn't explain the underlying problem, sadly. (I have the NVIDA HW patch applied to my OSG locally, and a stack trace would be useless since it's difference each time - depending on exactly how the corruption occurs) I'll hope the issue stays dead, since right now there's not much else I can do - thanks for the suggestions though. James -- 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
Re: [Flightgear-devel] FSWeekend: Lelystad, November 7, and 8, 2008
Count me in! Jorg -- 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
Re: [Flightgear-devel] navradio
On 7 Sep 2009, at 14:36, dave perry wrote: I was wrong about the height being correct. Thought it might be a scope problem for nav_elev so I tried moving the declaration back to navradio.hxx and moving the assignment of a value back into the search. The search is never called??? I'll also keep looking at this and let you know if I find the problem. I've just committed at least one fix - the problem actually predates my navradio change, but it also my fault. I broke the elevation data for ILS/LOC navids when I cleaned up the 'align localiser with runway centerline' logic. The problem is that runways don't have an elevation specified (in apt.dat). I've actually fixed this in two ways: - alignLocaliserWithRunway uses the original, specified elevation for the navid - runways (and taxiways) are initialised with the airport elevation instead of a zero elevation in the apt_loader. This is still a poor substitute for correct values, but in the absence of source for the actual runway elevation profile, it's much better than assuming zero. Regards, James -- 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
Re: [Flightgear-devel] navradio
James Turner wrote: - runways (and taxiways) are initialised with the airport elevation instead of a zero elevation in the apt_loader. This is still a poor substitute for correct values, but in the absence of source for the actual runway elevation profile, it's much better than assuming zero. Does it help to add the actual threshold elevation from our current Scenery and to store that in the respective .threshold.xml file in the same way as we're storing the elevation for each ILS ? Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- 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
[Flightgear-devel] GS sensitivity - especially for aircraft / panel developers
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
Re: [Flightgear-devel] navradio
Hi! Is it possible to fix another bug in navradio (?) system? If runway or the region has two (or more) NDBs with same frequency, then FG shows only one of them _everytime_. In real life (as far as i know) NDBs of working runway are turned on and other NDBs with same freqs are turned off. In MSFS: ADF is showing the direction to the nearest NDB with selected frequency (the easiest way i think). Let's fix this and make FG's radio-subsystem more realistic :) Thanks, Daniyar -- 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
Re: [Flightgear-devel] GS sensitivity - especially for aircraft / panel developers
Hi! Just want to ask developers: is it possible to make ILS/LOC establishing radius more realistic? What we have now in FG? You can establish ILS/LOC anywere you are if you are in n-kilometers over airport. In real life ATC asks pilots: Report localizer established because in real life you can establish it only when you are on base/final. Best, Daniyar 08.09.09, 19:00, James Turner zakal...@mac.com: As part of cleaning-up the nav-radio code, I need to make a painful change: fixing the confusion over GS maximum needle deflection. .. 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 -- 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
[Flightgear-devel] Patch to fix a Keypad problem on Mac OS X
Hi there, On Mac OS X, FG doesn't handle number keys on Keypad properly. Attached is a patch for solving this problem (on src/Main/FGEventHandler.cxx), so please commit it. Here is the brief problem statement. FGEventHandler::handleKey converts KEY_KP_Insert ... KEY_KP_PageUp keys to '0' ... '9' when num-lock modifier is on However, Apple keyboard don't have Num-lock key so num-lock modifier never becomes true. As a result, Number keys on Keypad is ignored. My patch makes handleKey ignore num-lock modifier on Macs, which converts KEY_KP_XXX to '0'..'9' all the time. It works fine on my Mac and it doesn't affect other platforms. Best, Tat FGEventHandler.diff Description: Binary data -- 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
Re: [Flightgear-devel] navradio
This: Just want to ask developers: is it possible to make ILS/LOC establishing radius more realistic? What we have now in FG? You can establish ILS/LOC anywere you are if you are in n-kilometers over airport. In real life ATC asks pilots: Report localizer established because in real life you can establish it only when you are on base/final. and this: On 8 Sep 2009, at 17:55, Atadjanov Daniyar wrote: Is it possible to fix another bug in navradio (?) system? If runway or the region has two (or more) NDBs with same frequency, then FG shows only one of them _everytime_. In real life (as far as i know) NDBs of working runway are turned on and other NDBs with same freqs are turned off. In MSFS: ADF is showing the direction to the nearest NDB with selected frequency (the easiest way i think). Both come under the category of 'problems with the nav radio code'. The second in particular I hope to work on 'soon' - I don't know nearly enough about modelling radio reception to improve the code (or make judgements about its quality) to address the first issue. You may notice I've been careful in my emails to state the areas I'm working on, precisely because there's many overlapping problems. The GS needle indications are wrong in the aircraft - no amount of improvements or advanced modelling in the navradio code will matter, if the panels aren't handling the output deflection sanely. Similarly, I've been cleaning up the code so that changes to the behaviour are hopefully cleaner and easier in the future. BTW, for NDBs, FlightGear *should* be picking the closest NDB with the matching frequency - exactly as MSFS. If that's not what you're seeing, that's a bug, and likely my fault. Please let me know a suitable test location and NDB frequencies / idents to reproduce the problem, and I'll take a look. Regards, James -- 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
Re: [Flightgear-devel] Patch to fix a Keypad problem on Mac OS X
Hi there, On Mac OS X, FG doesn't handle number keys on Keypad properly. Attached is a patch for solving this problem (on src/Main/FGEventHandler.cxx), so please commit it. Here is the brief problem statement. FGEventHandler::handleKey converts KEY_KP_Insert ... KEY_KP_PageUp keys to '0' ... '9' when num-lock modifier is on However, Apple keyboard don't have Num-lock key so num-lock modifier never becomes true. As a result, Number keys on Keypad is ignored. My patch makes handleKey ignore num-lock modifier on Macs, which converts KEY_KP_XXX to '0'..'9' all the time. It works fine on my Mac and it doesn't affect other platforms. Best, Tat Commited, Thanks. Torsten -- 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
Re: [Flightgear-devel] navradio
One thing I would like, if it's not already avaliable: Being able to tune a DME to a NDB-DME. I can't do that in FG, although Atlas reports some NDBs as having DME capability. -- 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
Re: [Flightgear-devel] navradio
One thing I would like, if it's not already avaliable: Being able to tune a DME to a NDB-DME. I can't do that in FG, although Atlas reports some NDBs as having DME capability. Huh? As far as I know there are only DME paired to VOR but not NDB. There are places where DME and NDB might be at the same place, but I think you have to tune boths frequencies individually. Torsten -- 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
Re: [Flightgear-devel] navradio
Then it's my fault :D I don't know how to get DME frequencies, Atlas doesn't tell me that... Thanks for the information! One thing I would like, if it's not already avaliable: Being able to tune a DME to a NDB-DME. I can't do that in FG, although Atlas reports some NDBs as having DME capability. Huh? As far as I know there are only DME paired to VOR but not NDB. There are places where DME and NDB might be at the same place, but I think you have to tune boths frequencies individually. Torsten -- 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
Re: [Flightgear-devel] navradio
2009/9/8 Torsten Dreyer tors...@t3r.de: NDB-DME There ara a lot NDB-DME in /data/Navaids/nav.dat ... 2 -42.72933900 170.95621900146 310 1000.0 HK HOKITIKA NDB-DME ... http://wikimapia.org/9701833/Hokitika-NDB-DME -- --- WBR, Vadym. -- 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
Re: [Flightgear-devel] navradio
2009/9/8 Torsten Dreyer tors...@t3r.de: NDB-DME There ara a lot NDB-DME in /data/Navaids/nav.dat ... 2 -42.72933900 170.95621900146 310 1000.0 HK HOKITIKA NDB-DME ... http://wikimapia.org/9701833/Hokitika-NDB-DME No doubt about this. But I don't know of any NDB receiver (which is also known as ADF) that automatically tunes the DME frequency. Most modern receiver for VOR do this, like the KX165, but that is due to a link between the DME-receiver and the NAV-receiver. As far as i know, you have to tune the DME part of your NDB-DME manually and the cited line of nav.dat is unusable for the DME part, because the DME channel is missing. Torsten -- 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
Re: [Flightgear-devel] navradio
Do I have to do so with NAV1/2? I don't seem to find any way to tune the KI226 DME without using the radio dialog/using the NAV radios. -- 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
[Flightgear-devel] multiple ai aircraft
i was just flying around kpdx when i ran into one of the ai aircraft. what made it strange is that instead of being just one plane there were about five or so aircrfat stacked on top of each other. you can see a picture at: http://caliban.lbl.gov/fgfs-weird.jpg not really sure where this is coming from. this happened with the latest cvs for both flightgear and simgear (and the data). --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | -- 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
Re: [Flightgear-devel] navradio
On Tue, 8 Sep 2009, James Turner wrote: This: Just want to ask developers: is it possible to make ILS/LOC establishing radius more realistic? What we have now in FG? You can establish ILS/LOC anywere you are if you are in n-kilometers over airport. In real life ATC asks pilots: Report localizer established because in real life you can establish it only when you are on base/final. and this: On 8 Sep 2009, at 17:55, Atadjanov Daniyar wrote: Is it possible to fix another bug in navradio (?) system? If runway or the region has two (or more) NDBs with same frequency, then FG shows only one of them _everytime_. In real life (as far as i know) NDBs of working runway are turned on and other NDBs with same freqs are turned off. In MSFS: ADF is showing the direction to the nearest NDB with selected frequency (the easiest way i think). Both come under the category of 'problems with the nav radio code'. The second in particular I hope to work on 'soon' - I don't know nearly enough about modelling radio reception to improve the code (or make judgements about its quality) to address the first issue. James, this patent (and those it references) may be an assistance to you: http://www.freepatentsonline.com/3663734.html Note that the listed patent and those it refers to are now expired and are now in the public domain. g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! -- 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
Re: [Flightgear-devel] GS sensitivity - especially for aircraft / panel developers
On 8 Sep 2009, at 23:18, dave perry wrote: 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. Okay, there's some misunderstandings here: - firstly I'm not changing the CDI deflection, which is [-10 .. 10] and will remain so, at all, for the reason you said - we have the 4x scale for localisers, and everyone is happy. (I might add the -norm version alongside, see point 3) - secondly, I'm changing (or will) the glideslope deviation to be 'correct' degrees: [-0.7 .. 0.7], i.e removing the spurious 5x scalar that has somehow crept in, and fixing many clients which assumed the range was [-10 .. 10], or something else again. This is in keeping with your flight instructor, I believe. - thirdly, providing normalised properties *as well* *does* make sense for panel authors, because of how animations are typically built. As you point out, the actual physical movement - whether in arc of a electo-mechanical needle, pixels on a digital cockpit display, or whatever, is up to the panel. In practice, it's achieved with some kind of animation node, scaling the deflection property. For example: animation typetranslate/type object-nameGS-pointer/object-name propertyinstrumentation/nav/gs-needle-deflection-norm/ property interpolation entryind-1.0/inddep-0.0108/dep/entry entryind1.0/inddep0.0108/dep/entry /interpolation (from the b1900d) Actually because of the clamped, normalised property, the entire table could go away, but that's another refinement. The point is the '0.0108' values are magic, and decided by the panel author - and I'm not going to touch them, for any panel (except to remove spurious 5x scaling factors). All I'm doing is simplifying the left hand-side of the interpolation table, which previously used to like entryind-10.0/inddep-0.0108/dep/entry entryind10.0/inddep0.0108/dep/entry (actually it looked worse, due to the lack of clamping) - fourthly, and most importantly, I'm not doing a blanket edit - I wish I could! I'm going to have to go through each aircraft, make the changes, and then test that aircraft. I'm sure I'l miss some things, but I still believe it's worth it to kill off the dreaded 5x multiplier, and fix all the aircraft who've been assuming the range is [-10..10] - or anything else. Hopefully that's clearer. James -- 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
Re: [Flightgear-devel] GS sensitivity - especially for aircraft / panel developers
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
Re: [Flightgear-devel] navradio
http://en.wikipedia.org/wiki/Distance_measuring_equipment I know , it's wikipedia , but it gives a short explanation of the VOR -DME pairing ... On Tue, Sep 8, 2009 at 1:01 PM, James Turner zakal...@mac.com wrote: On 8 Sep 2009, at 20:01, Torsten Dreyer wrote: There ara a lot NDB-DME in /data/Navaids/nav.dat ... 2 -42.72933900 170.95621900146 310 1000.0 HK HOKITIKA NDB-DME ... http://wikimapia.org/9701833/Hokitika-NDB-DME No doubt about this. But I don't know of any NDB receiver (which is also known as ADF) that automatically tunes the DME frequency. Most modern receiver for VOR do this, like the KX165, but that is due to a link between the DME-receiver and the NAV-receiver. As far as i know, you have to tune the DME part of your NDB-DME manually and the cited line of nav.dat is unusable for the DME part, because the DME channel is missing. There's also this entry: 13 -42.72933900 170.95621900146 11750 1000.0 HK HOKITIKA NDB-DME which is the DME part of the NDB-DME. As Torsten notes, none of the receivers in FG at present do pairing of NDB-DME frequencies, and I have no idea if any real world equipment can do this - or if there's even a defined pairing scheme. You can happily tune your ADF to 310KHz, and a DME receiver to 117.5MHz, and either/both should work, but there's no link between the two other than their geographical co-location. Again, if anyone with more knowledge of such facilities wants to comment, please do. James -- 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
Re: [Flightgear-devel] GS sensitivity - especially for aircraft / panel developers
On 09/08/09 15:18, dave perry wrote: [The] 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. 1) This was discussed in detail back in January 2009. 2) Yes, I know many ground-school instructors teach the half degree per dot rule ... but it is only a rough rule of thumb. Real world localizers adhere to the ICAO (and FAA) standard, which specifies that the localizer course shall be 210 meters (700 feet) wide at the threshold. That is the full side-to-side width. Some numerical examples are given below. Note that there are additional quirks that apply to exceptionally short runways. 3) The existing FGFS convention is perfectly reasonable, i.e. scaling the outputs of the nav receiver so that both the VOR and LOC deflections are represented the same way on the wire from the receiver to the CDI. 4) Back in January I wrote the code to implement correct ICAO localizer behavior. This includes the important service volume issues that Atadjanov Daniyar reminded us about recently, i.e. 09/08/09 09:30. This also includes false localizer courses, which are quite significant for real-world instrument flying. This also includes correct GS behavior, including false glideslopes. This also includes comments with references to the relevant standards, and why the output levels are as they are. Every rated pilot who tried out this code agreed that it behaved significantly better than the half degree per dot approximation. The code was never committed to CVS. No believable reason for rejecting it was ever given. 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 I strongly agree! There is nothing wrong with the existing FGFS convention for CDI deflections. Indeed this is a rather realistic model of how real-world receivers interact with analog CDIs. On 01/01/09 04:32, I wrote in part: some rather extreme examples include: At Kennedy: IMOH localizer axis: 4771.2 m == +- 1.28109 full scale or 0.256217 degrees per dot At Robert J. Miller: IMJX localizer axis: 1964.73 m == +- 3.11101 full scale or 0.622203 degrees per dot -- 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
[Flightgear-devel] property tree
I'm a new kid on the block but I want to raise and issue. *The Property Tree Documentation* Its taken a while to kinda figure out and research/mind shift as to where its all as there in conflicting information from /src mini-docs with regard to purpose and my intermittent time of research. Where it has led me is to the wiki and even there its kind of a lash/hash/mish/mash up. I'm a web developer by nature and not a compiler. I'd like to feedback and correct/make/edit wiki documentation and make it THE source of reference so It's easy to find; as another newbie like me is trying to find node etc it would be clear which path to follow to interface with FG internally or externally on sockets telnet etc. Now I've taken an initiative (ducks) and created the namespace of PropertyTree: as follows, but need advice before do it proper. PropertyTree: http://wiki.flightgear.org/index.php/PropertyTree What we want Out of that Tree has differenct objetives, eg internal, external, motion sim, cabin light switch and fader level et all Current wiki pages are. http://wiki.flightgear.org/index.php/Property_Tree_Intro http://wiki.flightgear.org/index.php/Property_Tree http://wiki.flightgear.org/index.php/Property_Tree_Servers ( I edited this hence --props above) from http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg21190.html http://wiki.flightgear.org/index.php/Property_Tree_Reorganization http://wiki.flightgear.org/index.php/Recommended_Property_Tree_Enhancements http://wiki.flightgear.org/index.php/Howto:Working_with_the_Property_Tree_API http://wiki.flightgear.org/index.php/Property_browser http://wiki.flightgear.org/index.php/Special:Search?search=propertygo=Go http://wiki.flightgear.org/index.php/Special:Search?search=treego=Go The only reliable one maybe is http://cvs.flightgear.org/viewvc/source/docs-mini/README.properties?view=markup ==Reference== Need to have the generic always there tree Reference ie constants of somewhat eg position, flaps, and a clear definition and the nodes of whats changeable and sim stuff.. reference here. Most Basic make users aware of how to browse properties and where the target areas are? I believe this is the way to go, its pretty clear in my mind as a newbie. Just need to consolidate it and make it cool and clear, no matter what level. First Major Desicion === --props= /dev/null http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg09152.html So two years later can on irc [23:59] vivian #vivian --props is a method of setting properties remotely Heard that --props is abandoned (is that for real) can someone confirm? [23:58] ac001 #ac001 so what is the difference between a --telnet and --props [23:59] Jester #Jester nothing so Can that be nuked from references http://wiki.flightgear.org/index.php/Command_Line_Parameters#IO_Options See what happens.. regards Pete ac001 -- 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
Re: [Flightgear-devel] GS sensitivity - especially for aircraft / panel developers
James Turner wrote: - fourthly, and most importantly, I'm not doing a blanket edit - I wish I could! I'm going to have to go through each aircraft, make the changes, and then test that aircraft. I'm sure I'l miss some things, but I still believe it's worth it to kill off the dreaded 5x multiplier, and fix all the aircraft who've been assuming the range is [-10..10] - or anything else. Hopefully that's clearer. James Sorry, I misunderstood you concerning the animation edits. I will be glad to help with the xml edits and testing. Getting rid of the spurious 5x for the glide scope and adding the clamps is a good idea and adding the normalized CDI and GS could make the animators job easier. I will start by changing the vor.xml and vor2.xml in Instruments-3D that are used in the pa24 and pa28 and perhaps several other AC. Dave P -- 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
