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. c) There is a good outroduction strategy which we can discuss later. ------------------------------------------------------------------------------ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
