From: Torsten D. <To...@t3...> - 2007-01-31 15:04:18
|
> 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 |
From: John D. <sf...@av...> - 2007-01-31 16:14:28
|
On 01/31/2007 10:04 AM, Torsten Dreyer wrote: > 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. Did you /observe/ such drift, or is it just a theory? Any such theory is inconsistent with my observations. I have performed the following check in the c182rg, and I suggest that others should do a similar check. 0) Apply my patch to hsi.xml 1) Initialize the aircraft on a taxiway or runway and start the engine. 2) Observe that the HSI indication agrees with the compass. 3) Fail the instrument using the popup menu. 4) Turn the aircraft by some good-sized angle. 5) Observe that the HSI indication no longer agrees with the compass. 6) Unfail the instrument. 7) Observe that it rapidly re-orients itself to agree with the compass ... as you would expect for a properly slaved HSI (although perhaps a bit too rapidly for 100% realism). > 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, Agreed (unless/until my patch has been applied). > but I think > your patch make things worse, since it makes the instrument unusable after > some time. This is unrealistic. I see no evidence of this. If you have actual evidence of this, please explain. > 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. There is no missing feature here. The slaving feature is not missing, and the serviceability-flag feature is not missing. If your HSI is supposed to be slaved but is not, then you have *two* bugs. My patch fixes one of the bugs, without making the other better or worse. Note that in the c++ code, there are two backends: *) heading_indicator_dg *) heading_indicator_fg The latter is slaved, while the former is not. In all aircraft I have checked, the HSI is mated to the slaved version. If that is not true for your aircraft, then that's your problem ... and any such problem (or lack thereof) should be completely orthogonal to my hsi.xml serviceable patch. |
From: Torsten D. <To...@t3...> - 2007-01-31 16:53:25
|
> 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. |
From: John D. <sf...@av...> - 2007-01-31 19:14:16
|
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? |
From: Torsten D. <To...@t3...> - 2007-01-31 21:03:19
|
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? |
From: AJ M. <aj-...@ad...> - 2007-01-31 22:44:48
|
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 |
From: Martin S. <Mar...@mg...> - 2007-02-04 21:37:33
|
Torsten Dreyer wrote: > As you said - this one needs patching of all aircraft that uses the hsi. It > should be thoroughly tested. Personally I'd certainly consider patching all involved aircraft as a valid option - as long as this serves the goal of getting a 'clean' solution and the involved parties agree on how it should be done, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -------------------------------------------------------------------------- |
From: John D. <sf...@av...> - 2007-02-04 23:44:31
|
Torsten Dreyer wrote in part: >> .... this one needs patching of all aircraft that uses the hsi. I believe that is no longer true. AFAIK, no aircraft require patching to use the new hsi. More particularly, it is my /goal/ to make the new hsi upward-compatible with the old hsi. If that goal is not met, please let me know and I'll try to fix it. >> It should be thoroughly tested. As always, thorough testing is a good thing. On 02/04/2007 04:37 PM, Martin Spott wrote: > Personally I'd certainly consider patching all involved aircraft as a > valid option - as long as this serves the goal of getting a 'clean' > solution and the involved parties agree on how it should be done, I appreciate the sentiment. Yes, we should keep per-aircraft patching on the list of options ... but let's keep that as Plan B for now. Plan A is to make the new hsi fully backward compatible. If that goal is not being met, please let me know. Two-step instructions can be found at: http://www.av8n.com/fly/fgfs/hsi-etc.diff |
From: John D. <sf...@av...> - 2007-01-31 22:18:22
|
Another migration strategy: According to preliminary indications, if we go into heading_indicator_fg.cxx and declare that "DG" is slang and should be replaced by "hsi" on general principles, then all but three of the aircraft can be migrated to 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. Of course the same applies to heading_indicator_dg.cxx. New and improved patches: http://www.av8n.com/fly/fgfs/hsi-etc.diff On 01/31/2007 04:03 PM, Torsten Dreyer wrote: >> /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. Those would be good things to put on the creeping features list. In the same vein, all the instruments in this family are lacking in realism as to the way they come /out/ of failure. They just miraculously hop to the ideal heading. A real instrument would take many seconds to grind its way over to the ideal heading. Also on the list: It would be nice to have a convenient way to fail the glideslope signal without necessarily failing the localizer at the same time. This would be plenty realistic. In any case, let's keep our perspective here: especially in the context of procedures training, almost /any/ failure mode is a huge improvement over /no/ failure mode, which is what the hsi has had until now. |
From: John D. <sf...@av...> - 2007-01-31 22:35:47
|
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 |
From: John D. <sf...@av...> - 2007-01-31 23:47:19
|
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", |
From: AJ M. <aj-...@ad...> - 2007-02-01 10:02:30
|
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 |
From: Vivian M. <viv...@li...> - 2007-02-02 10:17:36
|
John Denker wrote > On 01/31/2007 05:59 PM, AJ MacLeod wrote: >=20 > > 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... >=20 > Well, I'm only smart enough to find ones that refer to DG by the name = DG. > This includes one with an electrical.nas. >=20 > If you know of others, or a way to find others, please share. >=20 > 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 =3D = Output.new > ("DG", >=20 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.=20 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.=20 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 |