John Denker wrote: > Hi -- > > On 01/01/2009 01:17 PM, Torsten Dreyer wrote: > > >> Please find attached a patch as a proof of concept that has been in my head >> for a while now. Here is a short description of what it does: >> >> Check if /systems/electrical/outputs/dme exists (but don't create) >> If yes: use this node's value for guessing if power is available (for b.c.) >> If not: check if /instrumentation/dme/supply-voltage-norm exists >> If yes: check if this node's value is greater than the value >> of /instrumentation/dme/supply-voltage-min >> If no: assume power is available. >> >> It's now the responsibility of the electrical system (or the aircraft config >> file) to provide a value to the /instrumentation/dme/supply-voltage-norm >> node. It is independent of the absolute voltage of the system itself or the >> operating voltage of the instrument. >> >> I'd be happy to refine this concept and provide a patch for the Instruments >> using the old /systems/electrical/output properties if the community agrees >> on that idea. >> > > Possible refinements to consider: > > a) Define dme/supply-voltage-norm so that 1.0 is _nominal_. > On a typical aircraft with a 24-volt electrical system 24 real > volts would correspond to dme/supply-voltage-norm = 1.0 and > this is about what we expect to see with the engine off. We > would see normed voltage = 1.17 with the engine on. Just to > be clear, this is a significant change from what is suggested > in the Subject: line, because most RW instruments operate OK > from voltages far less than nominal. I reckon if the SW > instrument is making a yes/no decision, it should check for > supply-voltage-norm > 0.8 or even 0.5. > > Tangential remark: In Real Life, if the voltage gets low, > the DME effective range might go down, due to a lack of > transmitter power ... but I am not suggesting that we model > that level of detail, not now anyway. There are far more > serious issues that need attention. The property should > be analog, but using it in a nontrivially analog way should > be "reserved for the future". > > b) If the most important thing is compatibility with old > features, the second-most important thing is to have a good > introduction strategy for the new features. It is equally > necessary to have an outroduction strategy for the old stuff; > otherwise we wind up dragging around a huge legacy tail, > forever. > > There's a network effect here: There's no advantage to > upgrading the instruments until at least some important > aircraft are updated, and vice versa. > > Therefore I suggest flipping the order of the check mentioned > above: Instruments should check for the new thing first, > and if it exists, they should ignore the old thing. The > reason is simple: This allows aircraft implementors to > "get out in front" if they want. They can implement both > properties, with 100% confidence that a hitherto unknown > property will not cause old instruments to fail. Then > the aircraft implementor can go do something else, with > the expectation that his aircraft will automatically > improve as the library instruments improve. > > We can even provide a nasal script that automatically and > systematically clones old-style voltage to make new-style > properties. > > The converse is unchanged: From an instrument implementor's > point of view, checking for both properties (in either > order!) allows the instrument to "get out ahead". The > only reason for checking the new thing first is because > it works better from the aircraft perspective. > Is this really different that what Torsten is suggesting? From the instrument authors pont of view, he has to allow the instrument to operate if either condition is true. > c) There is a good outroduction strategy which we can > discuss later. >
There is a 2nd issue that leads to local copies of the instruments for various AC. That is emulating instrument lights via material animations. One of the reasons I made local copies of the radios for the pa24 is that the lighting for the instruments in the RW AC is from the red light in the ceiling panel, so it is really just illumination from between the heads of the front seat passengers. That means the bodies of the radios are also illuminated. But I doubt that having such illumination would not be desirable for some other AC like the seneca. Once we have better light simulation from osg, this issue will not reside in the instrument model any more. - Dave P. ------------------------------------------------------------------------------ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
