Why did I write a nasal replacement for the built-in Flightgear system? The default Flightgear electrical system was created by Curt Olson, written in C, and hard-coded into Flightgear. Curt later abandoned development in favor of a new nasal-based system that more deeply models electrical details, including system loads. Syd Adams later embellished this system and used it in many of his aircraft models. These are excellent efforts, but they are difficult to port and customize for other aircraft models. Also, they have features that are beyond what I typically need or care about.

My interest is providing the ability to work through normal procedures and checklists. I'm not interested in modeling emergency procedures or component failures. While these are real possibilities, they are by design rare, and modeling them correctly is beyond my time and ability. Curt's original idea was a simpler scheme that concerned itself only with voltage propagation. The basic strategy is sufficient for most things I wanted to do, but in experimenting with it I found it has a few bugs, and since it's hard-coded into Flightgear, it doesn't give the ability to customize certain handlers. I decided to depart from it, and try developing the same idea independently in nasal. This way I can build exactly what I want, shake out the bugs, and make it extensible for the future. A nasal solution is less efficient than a built-in C solution, so I've tried to keep the system lightweight while maintaining useful functionality.

There are several significant differences between my system and the built-in Flightgear system. The built-in system defines suppliers, buses, components and connectors; my system has only components and connectors. A supplier is a component sub-type, and a bus is just a basic output component used in a bus context. My system offers advantages in switching and output handling. With a little thought, it's fairly easy to convert a configuration file for the default system over to my system.

The system works by first constructing a set of nasal data structures from your configuration data. These lists let the system access many data elements without going to the property tree, and make for fast look-ups. After the initialization stage, the system updates voltages 3 times a second (unless you change the update frequency) by first updating the status of souce components, and then sequentially working through each connector. This is why order of connectors is important. Whenever possible, I try to bypass non-essential routines to reduce unnecessary processing.

I've used this system successfully on several small aircraft projects. It's very easy to set up and get going. I have not tried it with a large and complex aircraft like an airliner, but I plan on trying it with my MD-80 project. When I do so, I'll report on my progress.

I've been pleased to find several developers either trying or using this system in their efforts. I welcome feedback, and would be happy to take ideas for enhancements.

-Buck