Re: [Flightgear-devel] hsi.xml now responds to serviceable flag (or lack thereof)
John Denker wrote On 01/31/2007 05:59 PM, AJ MacLeod wrote: Please correct me if I'm wrong, but I suspect you're only looking at aircraft which use old fashioned simple XML electrical systems. Most vaguely recent aircraft which have had any significant attention paid to their electrical system will be using a nasal based one... Well, I'm only smart enough to find ones that refer to DG by the name DG. This includes one with an electrical.nas. If you know of others, or a way to find others, please share. find . | xargs grep -I '[/]DG' ./Aircraft/Spitfire/Systems/electrical.xml: prop/systems/electrical/outputs/DG/prop ./Aircraft/E3B/Systems/electrical.xml: prop/systems/electrical/outputs/DG/prop ./Aircraft/KC135/Systems/electrical.xml: prop/systems/electrical/outputs/DG/prop ./Aircraft/SeaVixen/Systems/seavixen-electrical.nas:DG = Output.new (DG, Hmm. There's some terminological inexactitude that has crept in here. In the Sea Vixen Pilot's notes what we might now call the hsi but was then called the compass indicator is the instrument on the panel. It has its own power supply and serviceability status. It is fed by the Master Reference Gyro (normal) or a Directional Gyro (Standby) each with its own power supply and serviceability status. I have modeled the MRG to reflect the data I have available, but have yet to do fast erection. The DG is probably less well modeled right now. The fluxgate compass is a different device which I added as an alternative to the then existing vacuum-driven item. And yes the Spitfire etc. electrical systems need updating to the latest nasal script standard. Vivian - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] hsi.xml now responds to serviceable flag (or lack thereof)
On Wednesday 31 January 2007 23:47, John Denker wrote: Well, I'm only smart enough to find ones that refer to DG by the name DG. This includes one with an electrical.nas. ./Aircraft/SeaVixen/Systems/seavixen-electrical.nas:DG = Output.new (DG, I notice the Sea Vixen suddenly slipped onto the end of the list there ;-) If you know of others, or a way to find others, please share. Aside from the Sea Vixen (which was the main one I was thinking of), the other one is the Lightning... but having just checked, that change is one that hasn't made it into CVS yet so you can be forgiven for not knowing about it :-) Cheers, AJ - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] hsi.xml now responds to serviceable flag (or lack thereof)
The hsi now responds correctly to simulated failure as commanded by the heading indicator item on the instrument failure popup. My handiwork can be found at http://www.av8n.com/fly/fgfs/hsi.xml.htm http://www.av8n.com/fly/fgfs/hsi.diff I have not checked other hsi-like instruments to see if they suffer from the same bug. Somebody else should do this, please. Hi John, I just checked you patch to hsi.xml where you tied the rotation of the compass rose to the heading of the heading-indicator. This leads to a drift of the compass rose due to precession and internal errors as one can see in Instrumentation/heading_indicator.cxx This is ok for a standard directional gyro, but the hsi implemented here is a slaved gyro since there is no way to correct the compass rose. I agree, that the hsi does not respond to the serviceable flag from the heading indicator and there is no way to fail the 2d instrument, but I think your patch make things worse, since it makes the instrument unusable after some time. This is unrealistic. A better solution might be to wrap the transformation into a condition that checks the servicable flag and leave the driving property at the original value. I suggest to not commit the patch since it is not a bug but a missing feature. Torsten - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] hsi.xml now responds to serviceable flag (or lack thereof)
Did you /observe/ such drift, or is it just a theory? Observation. I see no evidence of this. I do: - starting fg with a c182 - opening property browser - browsing to /instrumentation/heading-indicator - observing properties indicated-heading-deg and offset-deg - opening second property browser - browsing to /orientation - observing property heading-magnetic-deg One can see, that offset-deg is constantly decreasing/getting more negative showing that the indicated-heading-deg is showing heading with an offset. The same happens with c310u3a. I agree, that the property binding should change from /orientation/heading-magnetic-deg to another property but that's only one piece of the action. Just renaming it in the hsi.xml introduces a drifting gyro where it should not. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] hsi.xml now responds to serviceable flag (or lack thereof)
On 01/31/2007 11:53 AM, Torsten Dreyer wrote: - starting fg with a c182 - opening property browser - browsing to /instrumentation/heading-indicator - observing properties indicated-heading-deg and offset-deg - opening second property browser - browsing to /orientation - observing property heading-magnetic-deg OK, I think I see what is going on. For a properly-slaved DG or HSI or similar instrument, we shouldn't be looking at /instrumentation/heading-indicator/*. That's wrong. However, it is also wrong to look at /orientation/*. There is a third way, the correct way: /instrumentation/heading-indicator-fg/ especially /instrumentation/heading-indicator-fg/indicated-heading-deg To make all this work correctly requires more per-aircraft fussing than I had hoped would be necessary ... but it's all fairly straightforward. If you would like me to explain any of it, I'll be happy to oblige. (I'm told it is detestable to put explanatory comments in the code.) I believe the following patch suffices to bring the c182 and c182rg up to full performance. http://www.av8n.com/fly/fgfs/hsi-etc.diff One thing that I have *not* done but which might make sense as a migration strategy would be to create a new hsi+.xml file in parallel with the old hsi.xml file, since there are about a dozen aircraft that depend on hsi.xml and would break if they were forced to switch from heading-indicator to heading-indicator-fg without proper preparation. Then, once the preparation is made (such as providing proper power to the HSI), we can deprecate the old hsi.xml. Or does somebody have a better migration strategy? - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] hsi.xml now responds to serviceable flag (or lack thereof)
Am Mittwoch, 31. Januar 2007 20:13 schrieb John Denker: For a properly-slaved DG or HSI or similar instrument, we shouldn't be looking at /instrumentation/heading-indicator/*. That's wrong. However, it is also wrong to look at /orientation/*. d'accord There is a third way, the correct way: /instrumentation/heading-indicator-fg/ especially /instrumentation/heading-indicator-fg/indicated-heading-deg sounds plausible though the HeadingIndicatorFG lacks some realism, too. It has no way to fail the flux gate or manually switch from slave to free mode and use a manual adjust. I believe the following patch suffices to bring the c182 and c182rg up to full performance. http://www.av8n.com/fly/fgfs/hsi-etc.diff As you said - this one needs patching of all aircraft that uses the hsi. It should be thoroughly tested. One thing that I have *not* done but which might make sense as a migration strategy would be to create a new hsi+.xml file in parallel with the old hsi.xml file, since there are about a dozen aircraft that depend on hsi.xml and would break if they were forced to switch from heading-indicator to heading-indicator-fg without proper preparation. Then, once the preparation is made (such as providing proper power to the HSI), we can deprecate the old hsi.xml. Or does somebody have a better migration strategy? Not me - maybe anyone else? - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] hsi.xml now responds to serviceable flag (or lack thereof)
On 01/31/2007 05:18 PM, I wrote: Another migration strategy: The only aircraft that would require fiddling are ... It's even easier than I thought. The three that presently provide power to the so-called DG also provide power to the hsi, so AFAICT the patch can be dropped in with no per-aircraft fiddling required. http://www.av8n.com/fly/fgfs/hsi-etc.diff - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] hsi.xml now responds to serviceable flag (or lack thereof)
On Wednesday 31 January 2007 22:18, John Denker wrote: the new hsi.xml with no per-aircraft fiddling. The only aircraft that would require flag day fiddling are the three that already provide power to the so-called DG, namely Spitfire, E3B, and KC135 ... unless I'm overlooking something somewhere. Please correct me if I'm wrong, but I suspect you're only looking at aircraft which use old fashioned simple XML electrical systems. Most vaguely recent aircraft which have had any significant attention paid to their electrical system will be using a nasal based one... Cheers, AJ - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] hsi.xml now responds to serviceable flag (or lack thereof)
The hsi now responds correctly to simulated failure as commanded by the heading indicator item on the instrument failure popup. My handiwork can be found at http://www.av8n.com/fly/fgfs/hsi.xml.htm http://www.av8n.com/fly/fgfs/hsi.diff I have not checked other hsi-like instruments to see if they suffer from the same bug. Somebody else should do this, please. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
