Re: [Flightgear-devel] GS sensitivity - especially for aircraft / panel developers
On 9 Sep 2009, at 22:55, John Denker wrote: > If you really want to rip out the old outputs, in the > name of "internal cleanliness" or whatever, that can wait With apologies to Dave Perry, I think upon reflection (and converting some aircraft over myself), that waiting a bit longer here does make sense (hopefully not as much as a year), so I'l leave the current property alone for the moment and add a gs-needle-deflection-deg property alongside (and clamped). I'll still carry on fixing up aircraft in CVS, but this way we won't automatically break aircraft outside CVS when the next version is released. Equally, it's very clear that most aircraft developers copy-and-paste logic widely, so having CVS reflect best practice (or at least, correct practice) in this area seems wise. > As a > separate issue, there really needs to be a "valid" > flag, closely analogous to the To/Off/From flag > on theCDI. And I'll add a gs-valid prop too, which for the moment will simply be (has-gs && in-range), but which can be extended internally (when some of John Denker's fixes get merged) to drive instruments. As far as I can see, any instrument that needs to implement specialised parking behaviour can do it pretty easily using nodes - in the worst case of instruments that display the GS needle centred with no valid signal, that's still achievable. Torsten, do you agree that's a reasonable solution? > The code I wrote in 2007 and rebased > in January 2009 has all these features. Great minds think alike! 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] GS sensitivity - especially for aircraft / panel developers
On 09/09/2009 07:06 PM, John Denker wrote: > On 09/09/09 06:16, Tim Moore wrote: > Yes, the 2009 code is different from the 2007 code. The 2009 features and bugfixes are a superset of the 2007 features and bugfixes. Also the 2009 commits were rebased so that they applied cleanly to the FGFS release that was current at the time. >>> That's great! What's the url for the repository that has these changes? >>> Unless I'm doing something wrong, it seems like >>> http://www.av8n.com/repo/fgs/.git >>> and http://www.av8n.com/repo/sg/.git haven't been updated in some >>> time. > > I updated that site just now. I had stopped using > it more than two years ago, because it is just a > fileserver (lots of network connectivity, without > much CPU capacity) ... meaning it didn't support > gitweb. I thought it would be more convenient > for folks to evaluate my patches if I put my FGFS > stuff on a gitweb-enabled host. It turned out it > didn't make much difference. I find gitweb a poor substitute for cloning the repository and using gitk and the command line tools to poke around. But why don't you put your repositories on a well-known git hosting site that supports gitweb and more? Most convenient would be to fork my repositories on repo.or.cz and base your sportmodel on those. James Turner looked > at a couple of my patches using gitweb, but the > only folks who actually downloaded and tested the > patches were folks without commit authority. My > FGFS gitweb host died a while back. I didn't > bother to replace it, since it wasn't seeing any > traffic. ... > On 09/09/09 07:08, James Turner wrote: ... >> simply >> that either I need to be able to convince myself that a specific >> change is correct Otherwise, I'll leave any >> functional changes to to others. > > What others? As of January, I was under the impression > that you, James, were the one and only maintainer of > navradio.cxx. Are you suggesting that there is someone He is now :) > with commit authority who was interested and/or > qualified to judge the correctness of my code? I > was quite unaware of this back in January. Has the > situation changed somehow? > > Several people did try out my code ... just nobody with > commit authority. Evidently this kind of testing doesn't > count. > > Is the criterion that I have to prove that my patches > are absolutely correct? I don't see how it would ever > be possible to do that. The code had tons of bugs > before I touched it, and it has tons of bugs now. It > seems safe to say that accepting my patches would have > resulted in a better feature set and _far fewer_ bugs, > to say the least. No one wants a formal proof, but some comments might be in order. For whatever reason your patches tend to be controversial. Anyway, I committed your changes to simgear. I'm sorry that the author info got lost in the CVS commit; I'll use the -a flag on git cvsexportcommit in the future. When I look at your sportmodel branch with my software engineer hat on (no pilot helmet here), I see features that would be great to have, but also a lot of code that we already know won't merge cleanly. So, I propose to pick apart sportmodel as much as possible into patch series that don't depend on each other. There are a lot of changes to navradio.[ch]xx, but you and James are in heated discussion, so I'm not touching that. Instead, it looks like "Two-parameter physics-based model of atmosphere up to 262,467 ft i.e. the top of the mesosphere. Correctly exhibits the HALT phenomenon." would be awesome to have and is relatively independent of the rest of sportmodel. So, I have split out just that changeset and merged it to my next branch (basically CVS HEAD). I've pushed the result to the jsd/environment branch in git://repo.or.cz/flightgear.git. Could you take a look and see if this merge is correct, especially with respect to the live_update stuff that was introduced since you made your changes? Before this is checked in to CVS I'd like to see if Unpack.hxx can be replaced with Boost tuples, but otherwise the code looks good. Thanks, Tim -- 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/09/09 14:31, James Turner wrote: > In practice, all the instruments I've seen so far handle 'parking' the > GS needle in two ways: either masking layer above the needle, at the > extremities of the range, or an interpolation table where the extreme > values map to a particular hidden position. As with so many things, that is sometimes true and sometimes not. Some instruments park the GS needle in plain sight, in the middle of the range. You could argue that this is a poor user-interface design, so poor that it couldn't get certified today ... but it *is* what some real-world instruments do. It is a Bad Idea for the back-end (navradio.cxx) to make assumptions that conflict with what the front-end (instrument.xml) needs to do. The best procedure, which considerably simplifies the xml, is to allow the _instrument_ to tell navradio.cxx where to park the needle, not the other way around. The instrument.xml file knows how the needle is supposed to behave. As a separate issue, there really needs to be a "valid" flag, closely analogous to the To/Off/From flag on theCDI. The code I wrote in 2007 and rebased in January 2009 has all these features. -- 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 9 Sep 2009, at 21:47, Torsten Dreyer wrote: > I don't think clamping the deviation to +/-0.7 degrees and the > normalized > value to +/- 1.0 is a good idea. Instruments like the KI525 HSI move > the > glide slope needle out of sight when the glideslope signal is not > valid or > you are way above or below glideslope. > If you clamp the values, this information is lost for the instrument. This is a fair point - the problem is it's a situation the current property also handles incorrectly - it acts as if the sensing area for the GS is much 'thicker' than it actually is - so rather than reporting invalid, we just report extremely large 'valid' values. What needs to happen is to communicate the absence of a valid GS signal (for whatever reason) some meaningful way. (This, btw, is why the Mk-VIII has the -ncd flags for each input/ output property) The two solutions I can think of: - use - (or similar) to indicate an invalid signal OR - use the (existing) has-gs flag to indicate it (or a new flag, like gs-valid) The second seems much more sensible to me, in terms of minimal changes to existing instruments. Note that right now, the has-gs flag is not quite useful for this purpose, because we don't update it based on radio reception - I'd need to audit current users to see if it could be modified that way, or whether a new property is safer. (the first solution needs special handling by every existing instrument and script, I think, though it is a method used elsewhere in the code) In practice, all the instruments I've seen so far handle 'parking' the GS needle in two ways: either masking layer above the needle, at the extremities of the range, or an interpolation table where the extreme values map to a particular hidden position. Also, all the instruments I've changed so far have implemented a clamp themselves, either via an interpolation table, or min/max values on the animation element - I'm not creating any 'new' clamping, that I've seen so far. So, I think clamping is correct (and matches what we do for the heading needle) - what's needed is a flag property, and for panel / instrument authors to use that flag to implement a parking behaviour if they wish. 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] GS sensitivity - especially for aircraft / panel developers
> 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. Hi James I really appreciate your work on this topic! I don't think clamping the deviation to +/-0.7 degrees and the normalized value to +/- 1.0 is a good idea. Instruments like the KI525 HSI move the glide slope needle out of sight when the glideslope signal is not valid or you are way above or below glideslope. If you clamp the values, this information is lost for the instrument. Cheers, 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] GS sensitivity - especially for aircraft / panel developers
On 09/09/09 06:16, Tim Moore wrote: >>> Yes, the 2009 code is different from the 2007 code. >>> The 2009 features and bugfixes are a superset of the >>> 2007 features and bugfixes. Also the 2009 commits >>> were rebased so that they applied cleanly to the FGFS >>> release that was current at the time. >>> >> That's great! What's the url for the repository that has these changes? >> Unless I'm doing something wrong, it seems like >> http://www.av8n.com/repo/fgs/.git >> and http://www.av8n.com/repo/sg/.git haven't been updated in some >> time. I updated that site just now. I had stopped using it more than two years ago, because it is just a fileserver (lots of network connectivity, without much CPU capacity) ... meaning it didn't support gitweb. I thought it would be more convenient for folks to evaluate my patches if I put my FGFS stuff on a gitweb-enabled host. It turned out it didn't make much difference. James Turner looked at a couple of my patches using gitweb, but the only folks who actually downloaded and tested the patches were folks without commit authority. My FGFS gitweb host died a while back. I didn't bother to replace it, since it wasn't seeing any traffic. Consider the following two lists: A) -- nice looking livery -- nice looking vegetation -- nice looking panel layout -- et cetera B) -- realistic localizer -- realistic glideslope -- realistic DME -- realistic status flags -- realistic IDENT -- realistic altimeter and atmosphere -- realistic ATIS -- et cetera For the vast majority of FGFS users, the things on list (A) are important. Things on list (B) don't matter at all. They are harmless but irrelevant. In contrast, real-world instrument flying demands close attention to things on list (B). Things on list (A) don't matter at all. They are harmless but irrelevant, unless they impair the frame rate; you can't see the vegetation at night, or when you are solid in cloud. Everybody agrees that features on list (B) would be nice to have, but years of experience indicate that nobody with commit authority is interested in working on such things. To some extent this is a chicken-and-egg situation. So long as FGFS emphasizes gamer features (list A) it will attract gamers as users. If/when FGFS implements pilot features (list B) it will attract pilots as users. I emphasize that it is _not necessary_ to choose between gamer features and pilot features. FGFS should implement both. There is no reason not to. I guarantee you that a gamer who did not notice the absence of a working status flag will not notice the presence of a working status flag. Everybody says these features are "great". If somebody wants these features enough to actually allow them to be committed, please say so. On 09/09/09 07:08, James Turner wrote: >>> Yes, the 2009 code is different from the 2007 code. >>> The 2009 features and bugfixes are a superset of the >>> 2007 features and bugfixes. Also the 2009 commits >>> were rebased so that they applied cleanly to the FGFS >>> release that was current at the time. > With apologies, I should note that my recent re-factoring work in > navradio will likely mean these patches do not apply cleanly to > current trunk. That's ironic. If the aforementioned patches had been applied back in January 2009, many of the "new" features (such as normalized outputs) would already be in place and well tested. > My issue back in January was, and remains, that I don't feel qualified > to commit major functional changes to the radio code, since radio > modelling is far from my areas of expertise. That's not meant as an > obstacle to incorporating any particular change or bug-fix I'm glad to hear it was not intended as an obstacle. On this list I've heard lots of euphemisms for "none of your code is going to be committed" but at the end of the day they all mean "none of your code is going to be committed". Are not the recent changes "major" changes? Changing the semantics of the outputs, so as to a require a change in every instrument ... that seems kinda major to me. I still think it is a Bad Idea to change navradio.cxx in such a way as to change the semantics of the existing outputs. I recommend leaving the existing outputs alone, and simply _adding_ whatever normalized outputs are desired, under new names. This preserves 100% backward compatibility, so that panel designers are free to update their instruments _or not_, if/when/however they please. This is how my code handled things back in January 2009. If you really want to rip out the old outputs, in the name of "internal cleanliness" or whatever, that can wait a year or two. It is always wise to look at things from the users' point of view. Users care about bugs they can see and features they can see. If/when "internal cleanliness" contributes to reliability, that's fine, but in this case it makes a negative contribution. At the very least, it distract
Re: [Flightgear-devel] GS sensitivity - especially for aircraft / panel developers
On 9 Sep 2009, at 17:04, dave perry wrote: > I have updated and tested the vor.xml, vor2.xml in Instruments-3D/vor > as well as the century3.nas in Aircraft/Generic and the corresponding > PID controllers. I will do the same for the AltimaticIIIC used in the > SenecaII as I wrote the CenturyIII and AltimaticIIIC nasal and PID's > which are very similar to the CenturyIII. I think we will have to > change all the nasal GS arm entries. I agree, sadly. For some devices it's clear what arming sensitivity is used (eg the KAP-140 manual says '2 to 3 dots') but for others I'm having to make a sensible guess. > I also am familiar with the kap140 > nasal, so I will update that also. I have found that the parameters > in > the PID controllers need to be optimised for each aircraft as the > plant > changes with a change in flight model optimisation. I am not using > the > normalized property. This made increasing the proportional gain > by > 5x a very good starting point for re-optimization. I will re-optimize > the Cessna 172 PID file. Okay - I don't have a strong feeling on whether using the normalised or degree property is more readable / understandable / maintainable in Nasal scripts or autopilot gains - for the KAP-140 arm logic I used the -norm property and a 50% threshold (i.e 2.5 dots), but that's partly because I wanted to test and commit now, and don't want to edit the files again when I remove the 5x factor (see your second email) I'm going to do the big jets (777, 747, 787, the airbuses, and Concorde) next. The b1900 is also mostly done, I just want to test the autopilot more before committing. 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
On 9 Sep 2009, at 17:22, dave perry wrote: >> - 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. >> > I just looked at the latest navradio.cxx in CVS. You added the > normalised _gsNeedleDeflectionNorm > but did not remove the 5x from > _gsNeedleDeflection. > > This is to avoid breaking the clients that have not been updated, > right? > > Am I safe to assume that once most of the client updates are done, the > 5x will be removed. That is, is it OK to do the nas and xml updates > and > optimisation using degrees and not the normalized values. Correct - I want to wait another couple of days before removing the 5x hack, because once I do, every existing aircraft will definitely be wrong. Since it seems that most of the animation nodes are easier fixed by using the -norm property, I can safely update those now without upsetting anyone. -- 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: > - 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. > I just looked at the latest navradio.cxx in CVS. You added the normalised _gsNeedleDeflectionNorm but did not remove the 5x from _gsNeedleDeflection. This is to avoid breaking the clients that have not been updated, right? Am I safe to assume that once most of the client updates are done, the 5x will be removed. That is, is it OK to do the nas and xml updates and optimisation using degrees and not the normalized values. 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
Re: [Flightgear-devel] GS sensitivity - especially for aircraft / panel developers
James Turner wrote: > On 9 Sep 2009, at 03:01, dave perry wrote: > > >> 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. >> > > I've already changed various aircraft locally, for testing: > > - the generic 2D and 3D instruments > - the Seneca, B1900d, 747-400, C172P and Aerostar > - the Primus-1000 suite > > I don't claim to have done this 100% correctly yet - especially, I > need to convince myself the that GS-ARM modes of the various > autopilots (eg, the KAP-140 in the default C172) are behaving > correctly, since this is generally implemented as Nasal scripts > testing the GS needle deflection. > > One area I do need help with is the autopilot PID laws: eg, here's the > relevant chunk for the B1900d: > > > Glideslop Hold > > instrumentation/nav/gs-needle-deflection-norm > > > 0 > > > autopilot/settings/target-pitch-deg > > > -1.5 > 1.0 > 0.1 > 0.0 > 10.0 > 0.0 > > -10 > > > 5 > > > > > Since I've switched the input to be the normalised prop, we've gone > from a unclamped input (swinging from sometimes -60 to 60!) to one > which is much 'smaller' in magnitude and clamped to [-1 .. 1]. I > *guess* the fix will be to increase the gain on the PID, otherwise GS > hold will tend to lag, but that's about the total of my knowledge of > tweaking the PIDs. > > > I have updated and tested the vor.xml, vor2.xml in Instruments-3D/vor as well as the century3.nas in Aircraft/Generic and the corresponding PID controllers. I will do the same for the AltimaticIIIC used in the SenecaII as I wrote the CenturyIII and AltimaticIIIC nasal and PID's which are very similar to the CenturyIII. I think we will have to change all the nasal GS arm entries. I also am familiar with the kap140 nasal, so I will update that also. I have found that the parameters in the PID controllers need to be optimised for each aircraft as the plant changes with a change in flight model optimisation. I am not using the normalized property. This made increasing the proportional gain by 5x a very good starting point for re-optimization. I will re-optimize the Cessna 172 PID file. None of the above has been committed to CVS. Shall I send the diffs to you James for committing. 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
Re: [Flightgear-devel] GS sensitivity - especially for aircraft / panel developers
On 9 Sep 2009, at 14:16, Tim Moore wrote: >> Yes, the 2009 code is different from the 2007 code. >> The 2009 features and bugfixes are a superset of the >> 2007 features and bugfixes. Also the 2009 commits >> were rebased so that they applied cleanly to the FGFS >> release that was current at the time. >> > That's great! What's the url for the repository that has these > changes? > Unless I'm doing something wrong, it seems like > http://www.av8n.com/repo/fgs/.git > and http://www.av8n.com/repo/sg/.git haven't been updated in some > time. With apologies, I should note that my recent re-factoring work in navradio will likely mean these patches do not apply cleanly to current trunk. My issue back in January was, and remains, that I don't feel qualified to commit major functional changes to the radio code, since radio modelling is far from my areas of expertise. That's not meant as an obstacle to incorporating any particular change or bug-fix - simply that either I need to be able to convince myself that a specific change is correct (which generally means it needs to be pretty small, targeting a single bug or feature). Otherwise, I'll leave any functional changes to to others. In general I'd be much more comfortable with a series (even if it's 20) of smaller changes to the code, with some time for testing and settling of the code between each batch. That said, I would also love to see an improved LOC/GS reception model (false lobes, back courses, etc). Hopefully, with the fixes to the aircraft I'm currently making, one area of confusion will disappear from the equation, and the focus can be on generating 'good' values for the sim properties. 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] GS sensitivity - especially for aircraft / panel developers
On 09/09/2009 02:57 PM, John Denker wrote: > On 09/08/09 23:10, Tim Moore wrote: > >> Is this different from this commit in sportmodel?: >> commit 77a6f88082a74e3187268c9fde4cee49539cae43 >> Author: John Denker >> Date: Sun Jun 24 19:11:34 2007 -0400 >> >> Fix the azimuthal dependence of localizer service volume ... >> false localizer courses and all that. >> Not yet perfect, but waaay better than no azimuth-dependence, > > > Yes, the 2009 code is different from the 2007 code. > The 2009 features and bugfixes are a superset of the > 2007 features and bugfixes. Also the 2009 commits > were rebased so that they applied cleanly to the FGFS > release that was current at the time. > That's great! What's the url for the repository that has these changes? Unless I'm doing something wrong, it seems like http://www.av8n.com/repo/fgs/.git and http://www.av8n.com/repo/sg/.git haven't been updated in some time. > Specifically I am referring to commits such as: > > commit 85733b769251aca1c2e8cb0f70c723180d6b24f7 > Author: John Denker > Date: Sun Jan 11 15:47:43 2009 -0700 > > Localizer sensitivity depends on runway; > false LOC courses; LOC extended service volume, > false glideslopes, proper GS flag > > commit f14f10d642d478d922f9eb6cb7af4ef54d37420e > Author: John Denker > Date: Sun Jan 11 15:50:19 2009 -0700 > > Fix ADF bugs ... including still driving the needle when power off. > > commit c5d29402fae8b63bf5922ef3609b10cb3ef85622 > Author: John Denker > Date: Sun Jan 11 15:57:30 2009 -0700 > > Many fixes to navradio.cxx: > Localizer sensitivity depends on runway length as it should. > Localizer range varies from place to place as specified in nav.dat > Localizer has appropriate false localizer courses. > Glideslope range varies from place to place as specified in nav.dat > Glideslope has appropriate false glideslope signals. > Glideslope "inrange" flag distinct from localizer "inrange" flag. > GS needle parks where specified, not necessarily at mid-scale. > > commit 0b6990bba43b2298ebede9225c1fd48f74fa4a7a > Author: John Denker > Date: Sun Jan 11 15:58:27 2009 -0700 > > Better calculation of glideslope, using projection operators. > Gets rid of various bugs including asin(1.001) bugs. > > commit e67d9c9ae1dce21e030f3d84a317a22487833bc6 > Author: John Denker > Date: Mon Jan 12 03:29:29 2009 -0700 > > When selecting a VOR, NDB, or fix by name, prefer the one > nearest a given position. Specify position on command-line > via --vicinity=airport or --vicinity=lat,lon. > > commit be90d4f1b1145c21bd1c07b86a04d49271e7ad48 > Author: John Denker > Date: Wed Jan 28 12:43:13 2009 -0700 > > navradio: fix various range and IDENT bugs, including DME IDENT. > > > > > et cetera. > > -- > 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 23:10, Tim Moore wrote: > Is this different from this commit in sportmodel?: > commit 77a6f88082a74e3187268c9fde4cee49539cae43 > Author: John Denker > Date: Sun Jun 24 19:11:34 2007 -0400 > > Fix the azimuthal dependence of localizer service volume ... > false localizer courses and all that. > Not yet perfect, but waaay better than no azimuth-dependence, Yes, the 2009 code is different from the 2007 code. The 2009 features and bugfixes are a superset of the 2007 features and bugfixes. Also the 2009 commits were rebased so that they applied cleanly to the FGFS release that was current at the time. Specifically I am referring to commits such as: commit 85733b769251aca1c2e8cb0f70c723180d6b24f7 Author: John Denker Date: Sun Jan 11 15:47:43 2009 -0700 Localizer sensitivity depends on runway; false LOC courses; LOC extended service volume, false glideslopes, proper GS flag commit f14f10d642d478d922f9eb6cb7af4ef54d37420e Author: John Denker Date: Sun Jan 11 15:50:19 2009 -0700 Fix ADF bugs ... including still driving the needle when power off. commit c5d29402fae8b63bf5922ef3609b10cb3ef85622 Author: John Denker Date: Sun Jan 11 15:57:30 2009 -0700 Many fixes to navradio.cxx: Localizer sensitivity depends on runway length as it should. Localizer range varies from place to place as specified in nav.dat Localizer has appropriate false localizer courses. Glideslope range varies from place to place as specified in nav.dat Glideslope has appropriate false glideslope signals. Glideslope "inrange" flag distinct from localizer "inrange" flag. GS needle parks where specified, not necessarily at mid-scale. commit 0b6990bba43b2298ebede9225c1fd48f74fa4a7a Author: John Denker Date: Sun Jan 11 15:58:27 2009 -0700 Better calculation of glideslope, using projection operators. Gets rid of various bugs including asin(1.001) bugs. commit e67d9c9ae1dce21e030f3d84a317a22487833bc6 Author: John Denker Date: Mon Jan 12 03:29:29 2009 -0700 When selecting a VOR, NDB, or fix by name, prefer the one nearest a given position. Specify position on command-line via --vicinity=airport or --vicinity=lat,lon. commit be90d4f1b1145c21bd1c07b86a04d49271e7ad48 Author: John Denker Date: Wed Jan 28 12:43:13 2009 -0700 navradio: fix various range and IDENT bugs, including DME IDENT. et cetera. -- 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 9 Sep 2009, at 03:01, dave perry wrote: > 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. I've already changed various aircraft locally, for testing: - the generic 2D and 3D instruments - the Seneca, B1900d, 747-400, C172P and Aerostar - the Primus-1000 suite I don't claim to have done this 100% correctly yet - especially, I need to convince myself the that GS-ARM modes of the various autopilots (eg, the KAP-140 in the default C172) are behaving correctly, since this is generally implemented as Nasal scripts testing the GS needle deflection. One area I do need help with is the autopilot PID laws: eg, here's the relevant chunk for the B1900d: Glideslop Hold instrumentation/nav/gs-needle-deflection-norm 0 autopilot/settings/target-pitch-deg -1.5 1.0 0.1 0.0 10.0 0.0 -10 5 Since I've switched the input to be the normalised prop, we've gone from a unclamped input (swinging from sometimes -60 to 60!) to one which is much 'smaller' in magnitude and clamped to [-1 .. 1]. I *guess* the fix will be to increase the gain on the PID, otherwise GS hold will tend to lag, but that's about the total of my knowledge of tweaking the PIDs. 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
On 09/09/2009 01:37 AM, John Denker wrote: > 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. Are you referring to this: http://www.av8n.com/fly/fgfs/servol.diff ? (from http://article.gmane.org/gmane.games.flightgear.devel/52522) I get a 404 when trying to download it. Is this different from this commit in sportmodel?: commit 77a6f88082a74e3187268c9fde4cee49539cae43 Author: John Denker Date: Sun Jun 24 19:11:34 2007 -0400 Fix the azimuthal dependence of localizer service volume ... false localizer courses and all that. Not yet perfect, but waaay better than no azimuth-dependence, Tim -- 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
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
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: translate GS-pointer instrumentation/nav/gs-needle-deflection-norm -1.0-0.0108 1.00.0108 (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 -10.0-0.0108 10.00.0108 (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
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" : > 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] 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
