From: "Ampere K. Hardraade" <[EMAIL PROTECTED]> > Why should the electrical system be made generic?
It shouldn't. There is a whole class of physical systems that act as a network with two valued paths. Voltage/Current, Pressure/Velocity, Density/Massflow, some aerodynamics, etc etc. All of these systems need to be solved as a network in order to capture interactions, without hard coding solution paths. > All these system are basically different forms of moving something > from point A, through medium B, to point C. The problem with that approach is that you have to allow for (a) the amount of thing being used at B varying when C turns off, (b) sometimes, stuff can be flowing from C to A and to B, etc. > implementation can be as simple as *b = &a; (in C's terms). I don't think so ... one of the reasons I gave up on FGFS as a failure modelling simulation for training purposes is that the various buses do not manage combinatorial failures and side effects right. You can hard code the stuff, but it may not cover all cases. From: "Curtis L. Olson" <[EMAIL PROTECTED]> > 3a. The system is very complex with a lot of subtle interactions and > side effects. It's unclear for someone new coming into the project > exactly how it works and what you have to do to build a successful > electrical system model. I think the most important thing is to capture the network that drives the interactions for the general case, so we have confidence that the model will be correct for any situation, and then leave it to a dedicated "solver" to infer what the decision tree is at any time. > 4a. What we really need is someone who actually understands all this > stuff to build a better data driven electrical system model using a > better, more flexible approach. I am told that SPICE is a good example > of doing this right, but I'm a computer scientist with very little EE > knowledge or ability. Circuits strike fear into my heart. If the developers want to do it using a circuit solver, which I think is probably the right way to go, I'd be happy to provide an object oriented definition of what we need to have in the property tree. Separately to that, I can write up what the circuit solver has to do. It isn't particularly complicated, providing you're not trying to cover all the things that can happen to semiconductors/transistors when designing logic chips that run reliably at gigahertz speeds. It's that high end stuff that makes a SPICE codebase complicated. > 4b. An alternate approach would be to write a "procedural" electrical > system model for each specific aircraft using nasal. But is there a way > to have a "default" nasal function that can be overwritten by an > aircraft specific function? I am almost favoring the nasal approach > here for many of these aircraft specific subsystems. I don't have an opinion about this, having not used nasal seriously. Can it be used to write a modular solver that propagates both ways? > I realize this expands the discussion rather than focussing it, but I'm > getting really frustrated with the inabilities of the current electrical > system to do things like model battery charging (without trying to > charge itself and other goofy things), model ammeter gauges (i.e. > measure current flow between two different points in the "network"), do > load balancing between multiple alternators and a host of more complex > things. I like the idea of a v2.0 electrical system that is similar to > the current system, but designed by someone who knows what the > H-E-double toothpicks they are doing (obviously not me.) But in the > mean time, nasal would be a quick and dirty approach to getting a fairly > functional electrical system up and running pretty quickly. A final thought that might help y'all decide what to do ... As I see it, the _most_ important thing is to ensure that the method used to describe how the model works will be understandable to aircraft mechanics who have no programming experience. Those are the people who really know what the electrical system wiring looks like and what has to be added into a model. If they cannot read the computer parsable description in the aircraft file, they will be unable to find mistakes. Now: _if_ you decide that this should be the driving consideration and there are no technical obstacles that inherently for the decision for us, please build two versions of the same electrical system and I'll collaborate with the FAA to get the local avionics shops to let us know which they can understand better. They should be interested in supporting us because it's in their interests to have a good training tool. Both their techs (who can look through our files) and for their pilot customers (who persist in operating stuff wrongly). I suggest the C172 electrical system, with _all_ switches, breakers, interior lights, and all avionics loading their respective bus. C172s have a really simple system; fits on a single sheet of paper. It's a handy test case before trying to do the 747 or similar. _______________________________________________ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
