David Megginson writes: > [moving to the list] > > Curtis L. Olson writes: > > > This makes it difficult to just define the power source for the > > navcom in the instrument panel config file. We need to kill the > > audio when the power goes out and not have the autopilot continue > > to track something that is alledgedly off. > > Right -- the autopilot has to take its input from the nav radio, not > from the actual /position and /orientation properties. That's > important not only to deal with power-out situations, but to model > VORs realistically. The autopilot doesn't have to know where the nav > radio is drawing its power from, though, as long as it knows when the > nav radio is supplying information.
Related to the electrical system there are other non-panel things though to be concerned about as well. For instance, if electrical bus #1 isn't powered, the flaps won't move and the fuel pump won't work. This has flight model implications. Likewise, if the master-bat switch is off and the master-alt switch is off (or the engine is not running) and there is no external power, then the starter motor won't engage. > > I could hardcode the bus property names provided by the c172 > > electrical system, but this hoses us for other aircraft. Yes, this is out, I was just throwing it in there for contrast. > They should be parameterized in the XML instrument config file so that > the aircraft file can plug the right instrument into the right bus. > Note how some instruments are already parameterized to use different > engines or receivers. I never quite got the hang of your xml parameters ... > > Another solution that I am favoring at the moment is to allow an > > arbitrary list of property names for a node. This way avionics-bus-1 > > could advertise to: > > > > /systems/electrical/outputs/avionics-fan-power > > /systems/electrical/outputs/gps-mfd-power > > /systems/electrical/outputs/hsi-power > > /systems/electrical/outputs/navcom-power[0] > > /systems/electrical/outputs/audio-panel-power[0] > > I prefer that the GPS connect itself to avionics-bus-1, or more > specifically, that the aircraft config file connect the GPS to > avionics-bus-1. That's nice for designers, because it will feel a > little like actually building an aircraft. Some of this is a bit arbitrary and up to the aircraft designer. The line between the electrical system and instrument panel can be a bit fuzzy. In my case I am also trying to interface some real cockpit hardware, so that makes me lean towards pushing more of this into the electrical system model and less into the instruments/instrument panel. I'm also supporting all those little switches and circuit breakers. It's nice to be able to do this in a generalized electrical system model. It does complicate the electrical system config file, but this is just moving complexity from some where else ... and it would be even worse to have these things hard coded someplace. Essentially this is the difference between the electrical system deciding which buses power which items vs. the instruments deciding which bus they plug into. I.e. when we build the aircraft, do we run the wires from the buses to the instruments or do we run the wires from the instruments to the buses. The end result is really the same (although you might end up with the wire backwards) and since everything is based on the property system, it's more of an aircraft designer choice than a coder choice. The code as it stands would work either way ... it's a matter of modifying the <instruments>.xml and <electrical-system>.xml config files. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities [EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
