Re: [Flightgear-devel] New Attitude Indicator (Artificial Horizon) Behaviour
> This is why I carry 2 instrument covers in my flight bag.. Correct, I neglected to have mine handy ... a preflight error. When operating single pilot IMC in light chop (daytime thermals), with my instrument covers behind me in my flight bag on the seat behind me, I am _not_ about to stop flying the plane and spend a minute or so poking around the bag in order to retrieve them. That would be a lethal mistake. > I tried out a 3 axis sim at the AOPA Single Pilot IFR seminar here in > Chicago about a month ago. I was flying along just fine until in the dark > in IMC the instructor took away my vacumm system. I noticed about 30 > seconds after it happened and proceded to correct, but I had the hardest > time not doing what the AI showed me. It was stuck in a 20 degree bank to > the left and I continued to keep trying to correct that horizon.. now if > this ever happens to me in IMC in real life, I will just cover up the > instrument(s) and continue to work with what I have left. Yes. I find myself having the same trouble in FGFS as in real life. Users who don't have any trouble with this probably don't have a scan. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] New Attitude Indicator (Artificial Horizon) Behaviour
This is why I carry 2 instrument covers in my flight bag.. I tried out a 3 axis sim at the AOPA Single Pilot IFR seminar here in Chicago about a month ago. I was flying along just fine until in the dark in IMC the instructor took away my vacumm system. I noticed about 30 seconds after it happened and proceded to correct, but I had the hardest time not doing what the AI showed me. It was stuck in a 20 degree bank to the left and I continued to keep trying to correct that horizon.. now if this ever happens to me in IMC in real life, I will just cover up the instrument(s) and continue to work with what I have left. Ryan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Alex Perry Sent: Tuesday, September 24, 2002 2:08 PM To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] New Attitude Indicator (Artificial Horizon) Behaviour > > Hah! That's very nasty, the AI continues to operate just fine, and > > then [ever so] slowly starts to drift off center, but still reacts > > to overall aircraft motion. There are many different failure modes, that is one of them. That's what happened when I had a bearing failure (VMC). On another VMC vacuum failure, the AI simply stopped moving and continued to show straight and level irrespective of what I did. Since I was in completely smooth air, there was no indication of the failure until I tried to turn intentionally to a new heading. I was using an external horizon while VMC; had I flown into a cloud on an IFR clearance after the failure, imagine my sudden surprise ... > > I bet killing the vacuum system in a sim would be a good way to > > recalibrate a *lot* of pilot's egos. The alternative is to recalibrate their bodily shape in a real aircraft. > In real IFR it's deadly, because as you bank to keep the AI centred, > you gradually put the plane into a spiral. If you happen to notice > the increasing airspeed, decreasing altitude, or divergent TC reading Many pilots get lazy in cruise and stop doing a proper scan. In consequence, they don't notice the subtle symptoms in time. > (or glance at the vacuum pump) before you pass Vne, you might recover > in time. After that, though, you'll be dizzy, confused, and badly > disoriented, but will now have to fly IFR using the TC until you get > the plane on the ground, praying not to get an electrical failure > before then. Recently, I had a simultaneous failure of the TC and the DG, thankfully in VMC but under a real IFR clearance. It is incredibly hard to maintain IFR tolerances under those conditions and the incorrect instrument indications wasted about a third of my concentration by the distraction. I could have covered them up, using my instructor safety pilot's plastic disks. This was practice for a solo cross country and I'd forgotten to bring my own along so we completed the flight the way I'd have had to do it for-real. Had that happened in IMC, I'd have declared the emergency and required vectors to the FAF of the closest ILS. I had no redundancy remaining. > Now perhaps someone can remind me why I want to get an instrument > rating ... Because, without that training, if the same thing happens in a night or on-top or between-layers flight, you're basically beyond help. I should also point out that, visibility 3SM in haze at 9500 ft is quite legal and occurs regularly in some places. However, you're two miles above terrain, so your horizon is almost directly below you with a tiny circle of visible ground. You may be navigating and separating visually, but the instruments are not optional. > Thanks. I'm looking forward to input from Alex and other IFR pilots > on how I can make the behaviour more realistic. I'll play with it this evening, time and compiler permitting. I noticed that FGFS refused to build, as of 8am pacific this morning. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New Attitude Indicator (Artificial Horizon) Behaviour
David Megginson <[EMAIL PROTECTED]> said: > The AI now runs off the vacuum pump, though in a relatively simplistic > way. The instrument keeps track of its spin, and will slowly spin > down when there is no (or insufficient) suction available or quickly > spin up when suction becomes available. The movement isn't quite > right (especially the spin-up), but it is sufficient for some IFR > practice. To kill the AI, either disable the gauge itself by setting > /instrumentation/attitude-indicator/serviceable to false, or kill the > vacuum pump by setting /systems/vacuum/serviceable. When the engine > is running at under 1500RPM, the gauge will also be unreliable. Neat new feature. Any idea if the all attitude AI/DG like the one used in the A-4 is vacuum or electric powered? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New Attitude Indicator (Artificial Horizon)Behaviour
Alex Perry <[EMAIL PROTECTED]> writes: >> [1] The standard "T" instruments on the panel are the top 3 directly in >> front of you (airspeed, AI, altimeter), and the middle instrument of the >> bottom 3 (DG). > > Before non-pilots get confused, there are many different scan patterns and > rules to define when you switch between them to maintain safety. They all > work, but they're different even though they're equivalent. Absolutely. And that was why I specifically used the phrase "The way I was trained": > We're all trained, during instrument training, to do a complete instrument > scan. The way I was trained was to use the standard "T" instruments [1] in > my It was good for you to clarify that there are other scans, though! Cheers, Derrell ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] AI vacuum failure
Very nice. The DG doesn't appear to slow down and stop, though. Can we please dump the code from Steam to eliminate duplication ? Thank you. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New Attitude Indicator (Artificial Horizon) Behaviour
Alex Perry writes: > I was trained on the "^" "*" "O" "V" series of scans. The "V" is > different yet equivalent to the "T" in terms of its operational > purpose and use. It is usually used when in smooth air and > straight and level cruise with nothing much going on ... your main > concern is detecting a failure. For the PPL in Canada (and the US too, I assume) we have 5 hours of very basic instrument flight under the hood, together with an hour or so of ground briefing -- essentially, it's supposed to be enough to let us turn around and get back out of a cloud, though I don't know if the statistics show any benefit. In the ground briefing, my instructor emphasised thinking practically about what instruments matter in different situations: straight flight, a climb or descent, a turn, and a climbing or descending turn, and always then starting from the AI (or TC) and then moving out to those instruments, with less-frequent cross-checks on the others. Obviously, that would not be suitable for prolonged instrument flight, but it probably makes sense for VFR pilots who wouldn't have constant practice to help reinforce more formal scanning patterns. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New Attitude Indicator (Artificial Horizon) Behaviour
> [1] The standard "T" instruments on the panel are the top 3 directly in front > of you (airspeed, AI, altimeter), and the middle instrument of the bottom 3 > (DG). Before non-pilots get confused, there are many different scan patterns and rules to define when you switch between them to maintain safety. They all work, but they're different even though they're equivalent. The only danger is to use one of the wrong patterns for a given situation. I was trained on the "^" "*" "O" "V" series of scans. The "V" is different yet equivalent to the "T" in terms of its operational purpose and use. It is usually used when in smooth air and straight and level cruise with nothing much going on ... your main concern is detecting a failure. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] defaults
Curtis L. Olson wwrites:
> David Megginson writes:
> > Curtis L. Olson writes:
> >
> > > The preferences.xml file specifies the c172 as the default. It
> > > appears that even if you request a different aircraft as the default,
> > > the c172 config files get loaded first anyway, then the alternate
> > > config file is loaded with the correct aircraft. This means that if
> > > the c172 specifies any defaults such as aileron trim that isn't
> > > specified in the desired aircraft config, it will inherit the c172
> > > settings (i.e. they won't get overwritten, unless done so
> > > explicitely.)
> > >
> > > Is this what we want the behavior to be?
> >
> > No.
>
> Ok, good to know.
>
> > > I'm guessing it got this way for a reason, but I'm not sure we want
> > > things to act this way.
> >
> > It's almost certainly an initialization-order problem. We want the
> > aircraft settings to take precedence over preferences.xml and the
> > command-line options to take precedence over the aircraft settings.
> > Feel free to fix it, if you can think of a way to.
>
> I haven't actually looked into it beyond observing that an addition to
> the c172-set.xml file shows up no matter what aircraft I choose. So,
> I haven't dug into the code at all to see what is actually going on.
Hmm... maybe this would help
untested - but it 'looks' like this will fix 'this' problem,
don't thin it will cause any new ones
// Read in configuration (file and command line)
bool fgInitConfig ( int argc, char **argv ) {
// First, set some sane default values
fgSetDefaults();
// Read global preferences from $FG_ROOT/preferences.xml
SGPath props_path(globals->get_fg_root());
props_path.append("preferences.xml");
SG_LOG(SG_INPUT, SG_INFO, "Reading global preferences");
readProperties(props_path.str(), globals->get_props());
SG_LOG(SG_INPUT, SG_INFO, "Finished Reading global preferences");
// Attempt to locate and parse the various config files in order
// from least precidence to greatest precidence
// Check for $fg_root/system.fgfsrc
SGPath config( globals->get_fg_root() );
config.append( "system.fgfsrc" );
fgParseOptions(config.str());
#if defined( unix ) || defined( __CYGWIN__ )
char name[256];
// Check for $fg_root/system.fgfsrc.hostname
gethostname( name, 256 );
config.concat( "." );
config.concat( name );
fgParseOptions(config.str());
#endif
// Check for ~/.fgfsrc
char* envp = ::getenv( "HOME" );
if ( envp != NULL ) {
config.set( envp );
config.append( ".fgfsrc" );
fgParseOptions(config.str());
}
#if defined( unix ) || defined( __CYGWIN__ )
// Check for ~/.fgfsrc.hostname
gethostname( name, 256 );
config.concat( "." );
config.concat( name );
fgParseOptions(config.str());
#endif
// Parse remaining command line options
// These will override anything specified in a config file
fgParseArgs(argc, argv);
// Read the default aircraft config file.
string aircraft = fgGetString("/sim/aircraft", "");
if (aircraft.size() > 0) {
SGPath aircraft_path(globals->get_fg_root());
aircraft_path.append("Aircraft");
aircraft_path.append(aircraft);
aircraft_path.concat("-set.xml");
SG_LOG(SG_INPUT, SG_INFO, "Reading default aircraft: " << aircraft
<< " from " << aircraft_path.str());
try {
readProperties(aircraft_path.str(), globals->get_props());
} catch (const sg_exception &e) {
string message = "Error reading default aircraft: ";
message += e.getFormattedMessage();
SG_LOG(SG_INPUT, SG_ALERT, message);
exit(2);
}
} else {
SG_LOG(SG_INPUT, SG_ALERT, "No default aircraft specified");
}
return true;
}
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] defaults
Curtis L. Olson wrote:
> The preferences.xml file specifies the c172 as the default. It
> appears that even if you request a different aircraft as the default,
> the c172 config files get loaded first anyway, then the alternate
> config file is loaded with the correct aircraft.
THAT'S IT!
Dave Perry posted a few days back ("Pulling to the left trim?") that
he was seeing a out-of-roll-trim condition on all the YASim aircraft
that didn't have an explicit setting for /controls/aileron-trim. I've
looked at this in the past, and noticed that this property is always
set to (I think) 0.055 on startup.
I was never able to track it down; but that's it, clear as day. :)
[I'm back, by the way. Give me a few days to sort out the
post-wedding clean up and write thank-you notes (and read the 1000
messages in my flightgear folder), and I'll be able to start working
on things again. The top of the list currently is the jitterbug and
translating mouse clicks onto the existing "hybrid" 2D/3D virtual
panels.]
Andy
--
Andrew J. RossNextBus Information Systems
Senior Software Engineer Emeryville, CA
[EMAIL PROTECTED] http://www.nextbus.com
"Men go crazy in conflagrations. They only get better one by one."
- Sting (misquoted)
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] defaults
David Megginson writes: > Curtis L. Olson writes: > > > The preferences.xml file specifies the c172 as the default. It > > appears that even if you request a different aircraft as the default, > > the c172 config files get loaded first anyway, then the alternate > > config file is loaded with the correct aircraft. This means that if > > the c172 specifies any defaults such as aileron trim that isn't > > specified in the desired aircraft config, it will inherit the c172 > > settings (i.e. they won't get overwritten, unless done so > > explicitely.) > > > > Is this what we want the behavior to be? > > No. Ok, good to know. > > I'm guessing it got this way for a reason, but I'm not sure we want > > things to act this way. > > It's almost certainly an initialization-order problem. We want the > aircraft settings to take precedence over preferences.xml and the > command-line options to take precedence over the aircraft settings. > Feel free to fix it, if you can think of a way to. I haven't actually looked into it beyond observing that an addition to the c172-set.xml file shows up no matter what aircraft I choose. So, I haven't dug into the code at all to see what is actually going on. 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
re: [Flightgear-devel] defaults
Curtis L. Olson writes: > The preferences.xml file specifies the c172 as the default. It > appears that even if you request a different aircraft as the default, > the c172 config files get loaded first anyway, then the alternate > config file is loaded with the correct aircraft. This means that if > the c172 specifies any defaults such as aileron trim that isn't > specified in the desired aircraft config, it will inherit the c172 > settings (i.e. they won't get overwritten, unless done so > explicitely.) > > Is this what we want the behavior to be? No. > I'm guessing it got this way for a reason, but I'm not sure we want > things to act this way. It's almost certainly an initialization-order problem. We want the aircraft settings to take precedence over preferences.xml and the command-line options to take precedence over the aircraft settings. Feel free to fix it, if you can think of a way to. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] MSVC problem with electrical.hxx
Here are the compiling errors reported by MSVC. Compiling... electrical.cxx d:\FlightGear\cvs\FlightGear\src\Systems\electrical.hxx(83) : error C2248: 'FGElectricalComponent::comp_list' : cannot access private typedef declared in class 'FGElectricalComponent' d:\FlightGear\cvs\FlightGear\src\Systems\electrical.hxx(54) : see declaration of 'FGElectricalComponent::comp_list' d:\FlightGear\cvs\FlightGear\src\Systems\electrical.hxx(52) : see declaration of 'FGElectricalComponent' d:\FlightGear\cvs\FlightGear\src\Systems\electrical.hxx(104) : error C2248: 'FGElectricalComponent::comp_list' : cannot access private typedef declared in class 'FGElectricalComponent' d:\FlightGear\cvs\FlightGear\src\Systems\electrical.hxx(54) : see declaration of 'FGElectricalComponent::comp_list' d:\FlightGear\cvs\FlightGear\src\Systems\electrical.hxx(52) : see declaration of 'FGElectricalComponent' ... One cannot use in a derived class a private type declared in the base class. string_list and comp_list have to be made protected at least in class FGElectricalComponent Cheers, -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] defaults
The preferences.xml file specifies the c172 as the default. It appears that even if you request a different aircraft as the default, the c172 config files get loaded first anyway, then the alternate config file is loaded with the correct aircraft. This means that if the c172 specifies any defaults such as aileron trim that isn't specified in the desired aircraft config, it will inherit the c172 settings (i.e. they won't get overwritten, unless done so explicitely.) Is this what we want the behavior to be? I'm guessing it got this way for a reason, but I'm not sure we want things to act this way. For instance, if the default c172 has an electrical system, then the j3cub will have the same one, unless it explicitely requests a different electrical system. 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
[Flightgear-devel] RE: Caravan model
Jim Wilson wrote: > Or for just about any aircraft there's always the auctions: > http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=1565095164 Cheers, Jim. I Emailed the guy and he might consider shipping it to the UK. If he won't I could always purchase it and initially have it shipped to someone who might want to start on a caravan and or turbine FDM... I don't mind as long as it eventually lands on my doorstep ;-) Regards, Matt. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New Attitude Indicator (Artificial Horizon)Behaviour
David Megginson <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] writes: > > > And having experienced exactly this in a real airplane, in > > instrument conditions, I can tell that what you're seeing is quite > > realistic. > > A full narrative would be very welcome, if it's not too emotionally > difficult. Hmmm... Fortunately, there's not a lot to tell. I was on an instrument proficiency check, because I hadn't done any instrument flying in the previous six months. We were mostly in the clouds although we'd occasionally see ground below us. What I noticed in this case was an inconsistency between the DG and the AI. The AI said I was banking but the DG wasn't changing to indicate the turn I would expect in a bank. When I began to "correct" the bank with a little bit of aileron input, these two instruments also didn't behave as I would expect. A cross check of the turn coordinator indicated that it did not correspond with the AI. A glance at the vacuum gauge confirmed substantial loss of vacuum, i.e. it wasn't quite a complete failure, which was why the instruments appeared ok -- the AI didn't tumble or anything drastic like that -- but rather they spun down slowly, becoming more and more unreliable. I transitioned to using the magnetic compass and the turn coordinator as my primary instruments, requested a descent to below the clouds, and flew home in VFR conditions. We're all trained, during instrument training, to do a complete instrument scan. The way I was trained was to use the standard "T" instruments [1] in my primary scan, and expand to the rest of the panel every 30 seconds or so. If anything looked "funny" or didn't correspond, then crosscheck right away. I had no way of knowing how quickly I would catch a vacuum failure. It was really nice to find that I did, in fact, notice that things were awry, and transitioned to the alternate instruments properly and quickly. Doing instrument proficiency practice in a simulator (whether during initial instrument training or post rating) would do loads of good for any pilot, to reinforce the need to (and force the practice of) crosschecking the instruments. Having realistic instrument behavior in FG and adding an "instructor" station with the ability to create failures will be really nice. Cheers, Derrell [1] The standard "T" instruments on the panel are the top 3 directly in front of you (airspeed, AI, altimeter), and the middle instrument of the bottom 3 (DG). ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New Attitude Indicator (Artificial Horizon) Behaviour
> > Hah! That's very nasty, the AI continues to operate just fine, and > > then [ever so] slowly starts to drift off center, but still reacts > > to overall aircraft motion. There are many different failure modes, that is one of them. That's what happened when I had a bearing failure (VMC). On another VMC vacuum failure, the AI simply stopped moving and continued to show straight and level irrespective of what I did. Since I was in completely smooth air, there was no indication of the failure until I tried to turn intentionally to a new heading. I was using an external horizon while VMC; had I flown into a cloud on an IFR clearance after the failure, imagine my sudden surprise ... > > I bet killing the vacuum system in a sim would be a good way to > > recalibrate a *lot* of pilot's egos. The alternative is to recalibrate their bodily shape in a real aircraft. > In real IFR it's deadly, because as you bank to keep the AI centred, > you gradually put the plane into a spiral. If you happen to notice > the increasing airspeed, decreasing altitude, or divergent TC reading Many pilots get lazy in cruise and stop doing a proper scan. In consequence, they don't notice the subtle symptoms in time. > (or glance at the vacuum pump) before you pass Vne, you might recover > in time. After that, though, you'll be dizzy, confused, and badly > disoriented, but will now have to fly IFR using the TC until you get > the plane on the ground, praying not to get an electrical failure > before then. Recently, I had a simultaneous failure of the TC and the DG, thankfully in VMC but under a real IFR clearance. It is incredibly hard to maintain IFR tolerances under those conditions and the incorrect instrument indications wasted about a third of my concentration by the distraction. I could have covered them up, using my instructor safety pilot's plastic disks. This was practice for a solo cross country and I'd forgotten to bring my own along so we completed the flight the way I'd have had to do it for-real. Had that happened in IMC, I'd have declared the emergency and required vectors to the FAF of the closest ILS. I had no redundancy remaining. > Now perhaps someone can remind me why I want to get an instrument > rating ... Because, without that training, if the same thing happens in a night or on-top or between-layers flight, you're basically beyond help. I should also point out that, visibility 3SM in haze at 9500 ft is quite legal and occurs regularly in some places. However, you're two miles above terrain, so your horizon is almost directly below you with a tiny circle of visible ground. You may be navigating and separating visually, but the instruments are not optional. > Thanks. I'm looking forward to input from Alex and other IFR pilots > on how I can make the behaviour more realistic. I'll play with it this evening, time and compiler permitting. I noticed that FGFS refused to build, as of 8am pacific this morning. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] gear up in JSBsim
The gear/gear[x]/position-norm is locked at zero with the latest changes. Also the c310doesn't lift off until reaching approx 120kts. c172 and c182 seem fine. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New Attitude Indicator (Artificial Horizon)Behaviour
[EMAIL PROTECTED] writes: > And having experienced exactly this in a real airplane, in > instrument conditions, I can tell that what you're seeing is quite > realistic. A full narrative would be very welcome, if it's not too emotionally difficult. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New Attitude Indicator (Artificial Horizon) Behaviour
Curtis L. Olson writes: > Hah! That's very nasty, the AI continues to operate just fine, and > then [ever so] slowly starts to drift off center, but still reacts > to overall aircraft motion. I have never dealt with a vacuum failure, so I don't know how realistic that behaviour is, but I have had to deal with a partially-tumbled AI during instrument work under the hood. I will be implementing tumbling as soon as I have the chance. Once we have the electrical and static/pitot systems connected as well, we can add a GUI for random failures (as well as an external instructor console, of course). > I bet killing the vacuum system in a sim would be a good way to > recalibrate a *lot* of pilot's egos. In real IFR it's deadly, because as you bank to keep the AI centred, you gradually put the plane into a spiral. If you happen to notice the increasing airspeed, decreasing altitude, or divergent TC reading (or glance at the vacuum pump) before you pass Vne, you might recover in time. After that, though, you'll be dizzy, confused, and badly disoriented, but will now have to fly IFR using the TC until you get the plane on the ground, praying not to get an electrical failure before then. Now perhaps someone can remind me why I want to get an instrument rating ... > Wow! Good work. Thanks. I'm looking forward to input from Alex and other IFR pilots on how I can make the behaviour more realistic. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New Attitude Indicator (Artificial Horizon)Behaviour
"Curtis L. Olson" <[EMAIL PROTECTED]> writes: > Hah! That's very nasty, the AI continues to operate just fine, and > then [ever so] slowly starts to drift off center, but still reacts to > overall aircraft motion. I bet killing the vacuum system in a sim > would be a good way to recalibrate a *lot* of pilot's egos. And having experienced exactly this in a real airplane, in instrument conditions, I can tell that what you're seeing is quite realistic. Once the other instruments get tied in to vacuum, you'll find that you can catch a vacuum failure quickly if you're doing a full instrument scan (including comparing the vacuum instruments to the electric gyro turn coordinator), but you'll fail to catch it until quite late if you're tending to fixate on one or two instruments. Derrell ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New Attitude Indicator (Artificial Horizon) Behaviour
David Megginson writes: > The AI now runs off the vacuum pump, though in a relatively simplistic > way. The instrument keeps track of its spin, and will slowly spin > down when there is no (or insufficient) suction available or quickly > spin up when suction becomes available. The movement isn't quite > right (especially the spin-up), but it is sufficient for some IFR > practice. To kill the AI, either disable the gauge itself by setting > /instrumentation/attitude-indicator/serviceable to false, or kill the > vacuum pump by setting /systems/vacuum/serviceable. When the engine > is running at under 1500RPM, the gauge will also be unreliable. Hah! That's very nasty, the AI continues to operate just fine, and then [ever so] slowly starts to drift off center, but still reacts to overall aircraft motion. I bet killing the vacuum system in a sim would be a good way to recalibrate a *lot* of pilot's egos. Wow! Good work. 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
Re: [Flightgear-devel] Electrical systems
Once upon a time, you were sitting and writing: > The alternative method, by which every user would check its power supply at > every sim-cycle seems wastefull, especially when you have 300+ users. I agree. > AC components can have any number of suppliers, but generally only use > one at a time. DC components can use all their suppliers at the same > time. In reality, AC sources should be matched (otherwise, bad things happen). Connecting one AC source is a good idea (and easy to implement in software) If AC steady-state analysis is implemented, I believe we should employ some complex numbers (as those phasor techniques are easy to use). As for your suggestions: if I get you right, you suggest building an electro-mechanical model, where energy can "flow" from/to the engines, generators, busses suppliers etc. This looks nice, but it will take a while to implement. > 1) CSD (constant speed drive), which exists between an engine and its > generator. The CSD has one supplier, the engine, and one user, a generator. And so, it must incorperate with the engine model of the FDM. In that case, the engines should publish RPM data going to the CSD. > 2) Battery, nominally 28 Volt, which will last about 30 minutes if it is the > only power source available. It is normally supplied by the battery > charger, so if the charger is powered the battery is transparent. Is it always 28V ? > 4) APU (auxilliary power unit), which could be derived from a turbine > object, but I think that would be a waste. It supplies 115V/400Hz > electrics, and usually supplies pneumatics as well. It has a Start/On/Off > switch in the cockpit, and an EGT gauge. It burns fuel from one of the > airplanes main tanks. Another turbine engine :) In any case, all AC sources seem to behave the same > on/off. The breaker switch connects/disconnects the generator from its bus. One generator per bus, I assume. How many bus units exist within a typical Boeing 7x7? > 9) Bus, a simple component which only keeps a list of suppliers and a list > of users. AC or DC. It also has "band limit" (so not too many units could be hooked simultaniously to the bus). In any case, I love your ideas. The only thing I think should be added is the ability to simulate current "spikes", cutoffs, and more unwanted electrical phenomena (to make flight more interesting). > I'll soon draw up a diagram of a typical Boeing electrical system and send > it to whoever wants it. That would be great. I still wonder why I hated electrical engineering courses back then, and now, I really like it (if I ever teach an EE course, I'll give it as a homework question ;) ) All the best, Elady. //// (o)o) (-)-) booom ! ( ._.)(o) > < > < Elad (elady) J. Yarkoni "Elady" for friends or "Oh my God... - It's Him !" for fans (or turbofans). eMail: [EMAIL PROTECTED] WWW: http://www.ee.bgu.ac.il/~elady Dept. of ECE, BGU, Beer-Sheva, Israel, 84105. 972-8-647-2417. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] New Attitude Indicator (Artificial Horizon) Behaviour
The AI now runs off the vacuum pump, though in a relatively simplistic way. The instrument keeps track of its spin, and will slowly spin down when there is no (or insufficient) suction available or quickly spin up when suction becomes available. The movement isn't quite right (especially the spin-up), but it is sufficient for some IFR practice. To kill the AI, either disable the gauge itself by setting /instrumentation/attitude-indicator/serviceable to false, or kill the vacuum pump by setting /systems/vacuum/serviceable. When the engine is running at under 1500RPM, the gauge will also be unreliable. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RE: Electrical system
> I'm sure in these situations one would want to turn off > everything but the essential items like the radio etc. - as I'm not a pilot > (yet!) I don't know. If you grab the pilot information manual for the aircraft you're interested in, you'll find that it goes into rather depressing detail about that kind of thing. Unfortunately, even that isn't actually enough detail; they leave a lot out. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D-clouds and HUD markers
> did you recognize that some markers in the HUD display disappear when > 3D-clouds come in sight ? Shortly after takeoff, when looking at the clouds, > I see a HUD like this: > > http://document.ihg.uni-duisburg.de/bitmap/FGFS/Clouds3D_07.png > How does it go -- "Build a thousand bridges. That plus any number of other things 'wrong', but it is a work-in-progress. Ultimately, the goal is to get the all the code 'plibified' and into the main scene graph and, hopefully, problems like this will go away. At least we have a version running, so there is something to shoot at. Thanks for comment. Good hear others have been able to get it running. Regards John W ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Electrical systems
> Here are some ideas about modeling electrical systems that are general > enough to handle most airplanes. Nice list, but the only item that is relevant for light aircraft is the bus. > 2) Battery, nominally 28 Volt, which will last about 30 minutes if it is the > only power source available. It is normally supplied by the battery > charger, so if the charger is powered the battery is transparent. Light aircraft batteries are different; they use a contactor relay and also operate the field coil of the alternator (not generator) without going through a bus. The battery charger is (in this case) a regulator that has its own circuit breakers and has permission to damage the interior of avionics when the alternator output increases from zero to normal operating voltage. From memory, the battery is 24 volts, but the electrical bus is 28 volts when alternator is running. > 3) Ground Power, supplies 115 Volt, 400 cycle AC power to a "Ground Power > Bus". This is plugged into the side of the airplane, and is either there or > it isn't. A light in the cockpit advises if its there. Ground power on a light aircraft is the same as alternator power. > 9) Bus, a simple component which only keeps a list of suppliers and a list > of users. AC or DC. The biggest problem with a bus is managing the list of circuit breakers, knowing how to trip them automatically and whether the pilot can manually trip them. Some cannot be tripped manually (inconvenient). ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Electrical systems
Here are some ideas about modeling electrical systems that are general enough to handle most airplanes. The base object will probably need to keep a list of suppliers and another list of users. If the state of any component changes it will then be resposible for notifying all of its users. The alternative method, by which every user would check its power supply at every sim-cycle seems wastefull, especially when you have 300+ users. AC components can have any number of suppliers, but generally only use one at a time. DC components can use all their suppliers at the same time. Here are some objects to be derived from the base object: 1) CSD (constant speed drive), which exists between an engine and its generator. The CSD has one supplier, the engine, and one user, a generator. The CSD's function is to spin the generator at a set speed regardless of engine rpm. CSD parameters to monitor are Oil Quantity, Oil Temperature going in from the cooler, and Oil Temperature going out to the cooler. The measure of the CSD's health is the oil temperature Rise (out - in). The CSD has a cockpit switch which can physically disconnect it from the engine in order to protect the engine. The switch is for emergency use only, as once it is used the CSD clutch can only be engaged by a mechanic. 2) Battery, nominally 28 Volt, which will last about 30 minutes if it is the only power source available. It is normally supplied by the battery charger, so if the charger is powered the battery is transparent. 3) Ground Power, supplies 115 Volt, 400 cycle AC power to a "Ground Power Bus". This is plugged into the side of the airplane, and is either there or it isn't. A light in the cockpit advises if its there. 4) APU (auxilliary power unit), which could be derived from a turbine object, but I think that would be a waste. It supplies 115V/400Hz electrics, and usually supplies pneumatics as well. It has a Start/On/Off switch in the cockpit, and an EGT gauge. It burns fuel from one of the airplanes main tanks. 5) EPU, similar to an APU except that it only works (automatically) when regular electrical sources fail. The F-16 EPU has its own hydrazine fuel supply. I don't know if EPU's can supply hydraulics as well. 6) Generator, which supplies 115V/400Hz power to a bus. Supplier is a CSD. You could model the APU generator as an independent object using the APU as a supplier, or you could incorporate the APU generator into the APU model. Generators generally have two switches. The field switch turns the generator on/off. The breaker switch connects/disconnects the generator from its bus. 7) RAT (ram air turbine), like the EPU it usually comes on atomatically, although it can also be activated by a cockpit switch. The RAT falls down into the airstream and supplies 155V/400Hz power. In some airplanes it also supplies hydraulics, or only hydraulics. 8) HPG (hydraulic powered generator) uses a hydraulic motor to spin a generator. This is purely a backup source, used for ETOPS certification, and comes on automatically. 9) Bus, a simple component which only keeps a list of suppliers and a list of users. AC or DC. 10) TR (transformer/rectifier) converts AC to DC. Supplier is one of the AC buses. User is one of the DC buses. 11) Static Inverter converts DC to AC. Used by the battery bus to supply the Standby AC bus. In the event the battery is the only source operating, the Standby AC bus is the only source of AC power. Only essential users are on this bus. 12) Battery charger, supplied by an AC bus (with a backup AC bus also), user is the battery and everything the battery powers. I'll soon draw up a diagram of a typical Boeing electrical system and send it to whoever wants it. Dave Culp [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim re-init crash
On Tue, 24 Sep 2002 08:44:33 -0500 "Curtis L. Olson" <[EMAIL PROTECTED]> wrote: >Tony, > >After your recent changes, when I try to do a reset from >the FlightGear menu I get: We need to add this to the list of test procedures we perform before committing changes, next time. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Canadian Airspace
I guess it's not just the US that's touchy about its airspace. I've been having fun with the new Google news search, and came up with this story: http://www.zwire.com/site/news.cfm?newsid=5443180&BRD=1467&PAG=461&dept_id=188527&rfi=6 The explanation of the problem is a little confused, though: it had nothing to do with a flight plan. In Canada, all *controlled* airspace between 12,500ft ASL and FL180 is class B, but class G airspace can also extend up to FL180. (Above FL180 is class A -- IFR-only -- as in the US). With Victor airways, control-zone extensions, etc., there's not all that much class G airspace in Southern Canada: in class B airspace ATC provides positive separation to all VFR and IFR aircraft, so the pilot needed an ATC clearance (not necessarily a flight plan) and needed to be using an encoding transponder. Understandably, ATC was a little pissed-off to have an apparently NORDO aircraft flying through its space without clearance, though having the US dispatch F-16s was probably overkill. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] mpe progresss+URL
Oops, I forgot the link: http://www.kbs.twi.tudelft.nl/People/Students/L.Otte/ Leon Otte --- ace project <[EMAIL PROTECTED]> wrote: > Date: Tue, 24 Sep 2002 06:48:14 -0700 (PDT) > From: ace project <[EMAIL PROTECTED]> > Subject: mpe progresss > To: [EMAIL PROTECTED] > > We were in a good mood today and published a > snapshot > of our current code. We would like it if other > developers could take a look at it and see if you > can > compile the code and run into platform problems. > We have succesfully compiled on Cygwin, Solaris > (version unkown), Red Hat 7.2 (gcc 2.96 sick) and > Debian (version unknown) (gcc 2.95.5). > (BTW, the Makefile is NOT reliable) > > We are still far away from a working program, but we > like hints on possible problems. > Despite it is not possible to use source code > created > by others because that would give problems with our > gradiation (this is a graduation project for us). > > Published stuff: > - Source-code > - Source-code Documentation > - minor stuff > Not published yet: > - Background research > > Have fun, > > Leon Otte > Jeroen Boogaard > __ Do you Yahoo!? New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] mpe progresss
We were in a good mood today and published a snapshot of our current code. We would like it if other developers could take a look at it and see if you can compile the code and run into platform problems. We have succesfully compiled on Cygwin, Solaris (version unkown), Red Hat 7.2 (gcc 2.96 sick) and Debian (version unknown) (gcc 2.95.5). (BTW, the Makefile is NOT reliable) We are still far away from a working program, but we like hints on possible problems. Despite it is not possible to use source code created by others because that would give problems with our gradiation (this is a graduation project for us). Published stuff: - Source-code - Source-code Documentation - minor stuff Not published yet: - Background research Have fun, Leon Otte Jeroen Boogaard = OK, I admit it: My girlfriend's just an object to me. Unfortunately, there is some information hiding, but thankfully, she's fairly encapsulated, nicely modular, and has a very well defined interface! __ Do you Yahoo!? New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Compile Error in vacuum.cxx
Tony Peden writes: > Both you and Curt did it and it looks like there may be two declarations > of _pressure_node now. OK, I've just fixed it. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] JSBSim re-init crash
Tony, After your recent changes, when I try to do a reset from the FlightGear menu I get: FGPropertyManager::GetNode() No node found for fcs/componentspitch-trim-sum Segmentation fault This doesn't happen in Yasim models so it looks like it's confined to JSBSim. Maybe just a typo in a property name? 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
re: [Flightgear-devel] Compile Error in vacuum.cxx
Tony Peden writes: > Both you and Curt did it and it looks like there may be two declarations > of _pressure_node now. FWIW, I snuck mine in first. :-) 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
re: [Flightgear-devel] Compile Error in vacuum.cxx
On Tue, 2002-09-24 at 06:10, David Megginson wrote: > Tony Peden writes: > > > I ran into compile errors with vacuum.cxx this morning. Adding > > _pressure_node to the header as a member variable solved the problem. > > The file is attached. > > Apologies -- I just forgot to commit the header. It's in now. Both you and Curt did it and it looks like there may be two declarations of _pressure_node now. > > > All the best, > > > David > > -- > David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Compile Error in vacuum.cxx
Tony Peden writes: > I ran into compile errors with vacuum.cxx this morning. Adding > _pressure_node to the header as a member variable solved the problem. > The file is attached. Apologies -- I just forgot to commit the header. It's in now. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] JSBSim updates in FG
I checked the latest JSBSim into FG cvs this morning. Please note that you must update the base package as well since the file format has changed. Otherwise, FG will die with a rude message regarding config file incompatibility. -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS busted
If no one sends me an updated / corrected README.msvc, I will just remove them both, since neither of the existing ones provide current information. Curt. Norman Vine writes: > CAN WE RESOLVE THIS ISSUE it is a major PITA !! > > - Original Message - > From: "Norman Vine" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Wednesday, September 11, 2002 5:27 PM > Subject: [Flightgear-devel] CVS busted > > > > Someone else mentioned this but ... > > > > PLEASE can we move one of these to the ATTIC > > > > FWIW > > Windows is a case preserving but a case insensitive file system > > so you can't have two files differing by case only in the same directory > > > > or-is-this-an-anti-bill-conspiracy'ly yr's > > > > Norman > > > > $ cvs -d :pserver:[EMAIL PROTECTED]:/var/cvs/FlightGear-0.9 co > > FlightGear > > ? FlightGear/docs-mini/.new.README.msvc > > cvs server: Updating FlightGear > > cvs server: Updating FlightGear/docs-mini > > U FlightGear/docs-mini/README.msvc > > cvs [checkout aborted]: cannot rename file .new.README.msvc to > README.msvc: > > Filename exists with different case > > > > > > ___ > > Flightgear-devel mailing list > > [EMAIL PROTECTED] > > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > > > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- 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
Re: [Flightgear-devel] Fw: [vtp] Elevationdata of the Alps?
Norman writes: > It should be relatively easy to substitute the derived gtopo30 data > for any 'nans' < holes > The trick here is to back-project from the > higher-res set and interpolate from the nearest points in the > coarser data. I think that TerraGear already has a DEM interpolation > routine so we just need to do the back projection and this is trivial > in a 'rectangular' projection The GTOPO30 data is very unsatisfactory, and there could be considerable discrepencies between it the ASTER DEM data around it, resulting in obvious and probably unsatisfactory anomalies. On another issue, would the licence requirements for distributed ASTER data allow it to be used in FlightGear? I don't know if the following is the correct document - http://www.gds.aster.ersdac.or.jp/gds_www2002/service_e/a_p.guid_e/set_service_e kiyaku.html but if it is, it would seem to restrict the data for personal (and peaceful) use only. Mally ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Compile Error in vacuum.cxx
I ran into compile errors with vacuum.cxx this morning. Adding
_pressure_node to the header as a member variable solved the problem.
The file is attached.
--
Tony Peden
[EMAIL PROTECTED]
We all know Linux is great ... it does infinite loops in 5 seconds.
-- attributed to Linus Torvalds
// vacuum.hxx - a vacuum pump connected to the aircraft engine.
// Written by David Megginson, started 2002.
//
// This file is in the Public Domain and comes with no warranty.
#ifndef __SYSTEMS_VACUUM_HXX
#define __SYSTEMS_VACUUM_HXX 1
#ifndef __cplusplus
# error This library requires C++
#endif
#include
#include
/**
* Model a vacuum-pump system.
*
* This first, simple draft is hard-wired to engine #1.
*
* Input properties:
*
* /engines/engine[0]/rpm
* /systems/vacuum[0]/serviceable
*
* Output properties:
*
* /systems/vacuum[0]/suction-inhg
*/
class VacuumSystem : public FGSubsystem
{
public:
VacuumSystem ();
virtual ~VacuumSystem ();
virtual void init ();
virtual void bind ();
virtual void unbind ();
virtual void update (double dt);
private:
SGPropertyNode_ptr _serviceable_node;
SGPropertyNode_ptr _rpm_node;
SGPropertyNode_ptr _suction_node;
SGPropertyNode_ptr _pressure_node;
};
#endif // __SYSTEMS_VACUUM_HXX
Re: [Flightgear-devel] Fw: [vtp] Elevationdata of the Alps?
Mally writes: > The holes that Peter mentioned are due (I think) to cloud cover, and they can be > quite significant, e.g. 45% or more of any particular area. A DEM reader for > ASTER DEMs would have to have some way of filling these holes - they cannot > simply be ignored. It should be relatively easy to substitute the derived gtopo30 data for any 'nans' < holes > The trick here is to back-project from the higher-res set and interpolate from the nearest points in the coarser data. I think that TerraGear already has a DEM interpolation routine so we just need to do the back projection and this is trivial in a 'rectangular' projection > I haven't been back and checked, but I thought the ASTER DEMs are to continue to > be free - it's just some other types of data they've started charging for. Correct, I think that you just need to by a small data set ~50$US from which to compute the GCP's inorder to georeference the data request other wise there is a LONG wait for the data > > It's a shame that the release of the SRTM 90m data seems to have been put back. > I think I read that they were now planned for 2004. Agreed - but at least it looks as if it will still be available eventually Norman > > Mally > > - Original Message - > From: "Norman Vine" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Tuesday, September 24, 2002 12:19 PM > Subject: [Flightgear-devel] Fw: [vtp] Elevationdata of the Alps? > > > > A source for non-US 30 meter DEM's > > > > I believe that for those areas already processed and on line > > these are still free. > > > > We would have to build a new DEM reader to handle these > > but that should not be too dificult in that they are in a > > 'well known' format > > > > Norman > > > > - Original Message - > > From: "Roger James" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Tuesday, September 24, 2002 7:06 AM > > Subject: Re: [vtp] Elevationdata of the Alps? > > > > > > > You can view the current coverage at > > > > > > http://edcsgs7.cr.usgs.gov/aster/dem_map.html > > > > > > If it is not on this then you have to order it yourself. Expect a 9 month > > > lead time for relative DEMs but only a few days if you can provide GCPs > > and > > > request an absolute DEM. To generate the GCPs you will need the L1A > > dataset, > > > this will now cost you but not a lot. > > > > > > Roger > > > > > > - Original Message - > > > From: "Peter Guth" <[EMAIL PROTECTED]> > > > To: <[EMAIL PROTECTED]> > > > Sent: Tuesday, September 24, 2002 5:06 AM > > > Subject: Re: [vtp] Elevationdata of the Alps? > > > > > > > > > > > > I am looking for 10-30m elevation data of the Alps. > > > > > > > > > > > > > You could also try the ASTER DEM from NASA/USGS: > > > > > > > > http://edcdaac.usgs.gov/aster/ast14dem.html > > > > > > > > They have data worldwide, but not complete. You also have to deal with > > > > holes > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To unsubscribe from this group, send an email to: > > > > [EMAIL PROTECTED] > > > > > > > > Your use of Yahoo! Groups is subject to > > http://docs.yahoo.com/info/terms/ > > > > > > > > > > > > > > > > > To unsubscribe from this group, send an email to: > > > [EMAIL PROTECTED] > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > > > > > > > > > > > ___ > > Flightgear-devel mailing list > > [EMAIL PROTECTED] > > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > > > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Re: Flightgear-devel digest, Vol 1 #1016 - 15 msgs
Matthew Law writes: > Maybe we just model the general characteristics of the given type > of battery usually found in that aircraft. As you quite rightly > pointed out the discharge curve for most batteries can be described > with quite a basic exponential function. The atmospheric > conditions surrounding the battery may change it's characteristics > a little but I'm sure aviation batteries are made with that in mind > too. It could be that extreme cold temperatures affect the battery as well as the oil. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Caravan model
Jim Wilson writes: > Or for just about any aircraft there's always the auctions: > http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=1565095164 Great idea. This one ships only to the US, unfortunately, but with the current minimum bid at only USD 9.00, it's a good deal. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Fw: [vtp] Elevationdata of the Alps?
The holes that Peter mentioned are due (I think) to cloud cover, and they can be quite significant, e.g. 45% or more of any particular area. A DEM reader for ASTER DEMs would have to have some way of filling these holes - they cannot simply be ignored. I haven't been back and checked, but I thought the ASTER DEMs are to continue to be free - it's just some other types of data they've started charging for. It's a shame that the release of the SRTM 90m data seems to have been put back. I think I read that they were now planned for 2004. Mally - Original Message - From: "Norman Vine" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, September 24, 2002 12:19 PM Subject: [Flightgear-devel] Fw: [vtp] Elevationdata of the Alps? > A source for non-US 30 meter DEM's > > I believe that for those areas already processed and on line > these are still free. > > We would have to build a new DEM reader to handle these > but that should not be too dificult in that they are in a > 'well known' format > > Norman > > - Original Message - > From: "Roger James" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Tuesday, September 24, 2002 7:06 AM > Subject: Re: [vtp] Elevationdata of the Alps? > > > > You can view the current coverage at > > > > http://edcsgs7.cr.usgs.gov/aster/dem_map.html > > > > If it is not on this then you have to order it yourself. Expect a 9 month > > lead time for relative DEMs but only a few days if you can provide GCPs > and > > request an absolute DEM. To generate the GCPs you will need the L1A > dataset, > > this will now cost you but not a lot. > > > > Roger > > > > - Original Message - > > From: "Peter Guth" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Tuesday, September 24, 2002 5:06 AM > > Subject: Re: [vtp] Elevationdata of the Alps? > > > > > > > > > I am looking for 10-30m elevation data of the Alps. > > > > > > > > > > You could also try the ASTER DEM from NASA/USGS: > > > > > > http://edcdaac.usgs.gov/aster/ast14dem.html > > > > > > They have data worldwide, but not complete. You also have to deal with > > > holes > > > > > > > > > > > > > > > > > > > > > > > > To unsubscribe from this group, send an email to: > > > [EMAIL PROTECTED] > > > > > > Your use of Yahoo! Groups is subject to > http://docs.yahoo.com/info/terms/ > > > > > > > > > > > > To unsubscribe from this group, send an email to: > > [EMAIL PROTECTED] > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > > > > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Flightgear-devel digest, Vol 1 #1016 - 15 msgs
On Tue 24 September 2002 10:16, Elad Yarkoni wrote: > > Since there is no such thing as a perfect power source you could go to > > much more detail - modelling the internal resistance of the battery and > > it's own capacitive and inductive load characteristics for example. > > I think it's not really needed (after all, we may > end up writing pSpice within FlightGear... ;) ) > Sorry I wasn't being clear. My use of 'you could go to much more detail' usually means 'you could, but why?! ' :-) > Hmm... we can either find an algebric expression (exponential functions > would do the work nicely), or use interpolation table (I know some > voltage drop diagrams... I have it somewhere in my intro. to Electronic > Devices lecture notes). I've got some stuff on battery discharge characteristics for different battery types somewhere. Are aviation batteries lead acid as in many cars or are they different? Maybe we just model the general characteristics of the given type of battery usually found in that aircraft. As you quite rightly pointed out the discharge curve for most batteries can be described with quite a basic exponential function. The atmospheric conditions surrounding the battery may change it's characteristics a little but I'm sure aviation batteries are made with that in mind too. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Fw: [vtp] Elevationdata of the Alps?
A source for non-US 30 meter DEM's I believe that for those areas already processed and on line these are still free. We would have to build a new DEM reader to handle these but that should not be too dificult in that they are in a 'well known' format Norman - Original Message - From: "Roger James" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, September 24, 2002 7:06 AM Subject: Re: [vtp] Elevationdata of the Alps? > You can view the current coverage at > > http://edcsgs7.cr.usgs.gov/aster/dem_map.html > > If it is not on this then you have to order it yourself. Expect a 9 month > lead time for relative DEMs but only a few days if you can provide GCPs and > request an absolute DEM. To generate the GCPs you will need the L1A dataset, > this will now cost you but not a lot. > > Roger > > - Original Message - > From: "Peter Guth" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Tuesday, September 24, 2002 5:06 AM > Subject: Re: [vtp] Elevationdata of the Alps? > > > > > > I am looking for 10-30m elevation data of the Alps. > > > > > > > You could also try the ASTER DEM from NASA/USGS: > > > > http://edcdaac.usgs.gov/aster/ast14dem.html > > > > They have data worldwide, but not complete. You also have to deal with > > holes > > > > > > > > > > > > > > > > To unsubscribe from this group, send an email to: > > [EMAIL PROTECTED] > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > > > > > > To unsubscribe from this group, send an email to: > [EMAIL PROTECTED] > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D-clouds and HUD markers
Martin Spott > > So to reiterate what Curt > > "This isn't quite ready for general consumption" > > but some of us are working on it > > Sorry, I didn't mean to hurt anyone. No problem, just wanted to make sure everyone realizes this is still in development :-) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D-clouds and HUD markers
> So to reiterate what Curt > "This isn't quite ready for general consumption" > but some of us are working on it Sorry, I didn't mean to hurt anyone. I just recognized this effect and I had the desire to point at it. It's beyond my scope to realize what people are aiming to deal with, so I thought it _might_ be useful to share my discovery, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Caravan model
David Megginson <[EMAIL PROTECTED]> said: > Matthew Law writes: > > > I took it upon myself to email cessna last night in the hope that > > they might be able to supply me with some line drawings and a few > > useful bits of technical data for the caravan model. I did point > > out that the info would be used solely for this project and as such > > would be re-distributed under the terms of the project. > > > > I don't expext they will want to help given that the caravan was a > > major selling point in their relationship with M$ for FS2002, but > > if you don't ask you don't get ;-) > > > > If anyone here knows of any good line drawings to help with the > > model I'd be most grateful. > > If you call Cessna and ask to order the Information Manual for a > specific model/year of Caravan, they'll be happy to sell it to you > (probably under USD 50.00). It will include line drawings, > performance tables, system descriptions, weight and balance, and a lot > of other interesting stuff. > Or for just about any aircraft there's always the auctions: http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=1565095164 Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MSVC 6.0 Problem with systems/vacuum/vacuum.cxx
Richard Bytheway writes: > I changed my copy to use min() rather than fmin() (W2K, cygwin, gcc version 2.95.3-5 (cygwin special)). > Builds, links, and appears to run OK. Yes that works, however it would be nice to be able to use the (f) version of the common math functions when they are available in that they **maybe** faster depending on the machine compiler combination. AFAIK This was part of the rationale behind their addition to the C99 standard Cheers Norman > > -Original Message- > > From: Bernie Bright [mailto:[EMAIL PROTECTED]] > > Sent: 24 September 2002 10:34 am > > To: [EMAIL PROTECTED] > > Subject: Re: [Flightgear-devel] MSVC 6.0 Problem with > > systems/vacuum/vacuum.cxx > > > > > > On Tue, 24 Sep 2002 03:46:54 -0400 > > "Norman Vine" <[EMAIL PROTECTED]> wrote: > > > > > Bernie Bright writes: > > > > > > > On Mon, 23 Sep 2002 18:51:25 -0700 > > > > Jonathan Polley <[EMAIL PROTECTED]> wrote: > > > > > > > > > MSVC does not have fmin() defined, so complains in vacuum.cxx. > > > > > > > > > > > > > gcc 2.95.3 complains too. fmin() is only defined if > > _ISOC99_SOURCE is > > > defined before including . > > > > > > I wonder if we are going to need a sg_math.h > > > if so here is a first stab at one > > > > > [cut] > > > > Well, as far as I can tell, fmin() is C99 not Std C++. We > > could use std::min() but that causes a problem with MSVC > > where you have to use cpp_min() instead. And so it goes on... > > > > Bernie > > > > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MSVC 6.0 Problem with systems/vacuum/vacuum.cxx
Bernie Bright writes: > Well, as far as I can tell, fmin() is C99 not Std C++. We could > use std::min() but that causes a problem with MSVC where you have > to use cpp_min() instead. And so it goes on... My fault -- I didn't realize that fmin() was non-ANSI. I've fixed it in the CVS (in advance of integration of Alex's vacuum model from steam.cxx). All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Caravan model
Matthew Law writes: > I took it upon myself to email cessna last night in the hope that > they might be able to supply me with some line drawings and a few > useful bits of technical data for the caravan model. I did point > out that the info would be used solely for this project and as such > would be re-distributed under the terms of the project. > > I don't expext they will want to help given that the caravan was a > major selling point in their relationship with M$ for FS2002, but > if you don't ask you don't get ;-) > > If anyone here knows of any good line drawings to help with the > model I'd be most grateful. If you call Cessna and ask to order the Information Manual for a specific model/year of Caravan, they'll be happy to sell it to you (probably under USD 50.00). It will include line drawings, performance tables, system descriptions, weight and balance, and a lot of other interesting stuff. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS busted
CAN WE RESOLVE THIS ISSUE it is a major PITA !! - Original Message - From: "Norman Vine" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, September 11, 2002 5:27 PM Subject: [Flightgear-devel] CVS busted > Someone else mentioned this but ... > > PLEASE can we move one of these to the ATTIC > > FWIW > Windows is a case preserving but a case insensitive file system > so you can't have two files differing by case only in the same directory > > or-is-this-an-anti-bill-conspiracy'ly yr's > > Norman > > $ cvs -d :pserver:[EMAIL PROTECTED]:/var/cvs/FlightGear-0.9 co > FlightGear > ? FlightGear/docs-mini/.new.README.msvc > cvs server: Updating FlightGear > cvs server: Updating FlightGear/docs-mini > U FlightGear/docs-mini/README.msvc > cvs [checkout aborted]: cannot rename file .new.README.msvc to README.msvc: > Filename exists with different case > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D-clouds and HUD markers
Martin Spott writes: > > did you recognize that some markers in the HUD display disappear when > 3D-clouds come in sight ? Shortly after takeoff, when looking at the clouds, > I see a HUD like this: There are LOTS of issues to be ironed out with the 3DClouds yet. The 'OpenGL Transparency Issue' is just one of them, another is that they currently live in a completely different vector space then the rest of FGFS. So to reiterate what Curt "This isn't quite ready for general consumption" but some of us are working on it And 'hats off to JohnW" for doing a great job getting this to 'work' in Unix without using the 'card' and WIN32 specific OpenGL stuff that MarkH used in the original code. < some of these I am experimenting with 'conditionally' adding back in though in that there are usually significant performance gains to be had when a card supports the 'newer' OpenGL extensions -for example pbuffers-. I am trying to determine this conditional stuff at initialization time so that it should be transparent to the user > Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RE: Electrical system
Once upon a time, you were sitting and writing: > To avoid things getting very complex very quickly it might be easier to take a > very simplistic apporach and model the batteries chief characteristics such > as terminal voltage, and ampere/hour capacity. > Since there is no such thing as a perfect power source you could go to > much more detail - modelling the internal resistance of the battery and > it's own capacitive and inductive load characteristics for example. I think it's not really needed (after all, we may end up writing pSpice within FlightGear... ;) ) I think the electrical systems for most small airplanes have DC sources, so having capacitance/inductance for the electric devices is ... I dunno... I don't think we need this property yet (we probably seek for steady state analysis, and not transient response of the system). > But for the beginning surely we just need to > know how what voltage it will supply and how much current capacity is > available don't we? Sure. That would be just about anything we need to model/simulate for a start. > Furthermore, if we need more accurate battery discharge modelling to represent > the inherent voltage drop when the load approaches or exceeds the maximum the > battery can supply in it's current condition we can have generic functions > in code to model the behaviour and supply the values for the specific case > from XML. Hmm... we can either find an algebric expression (exponential functions would do the work nicely), or use interpolation table (I know some voltage drop diagrams... I have it somewhere in my intro. to Electronic Devices lecture notes). All the best, Elady. //// (o)o) (-)-) booom ! ( ._.)(o) > < > < Elad (elady) J. Yarkoni "Elady" for friends or "Oh my God... - It's Him !" for fans (or turbofans). eMail: [EMAIL PROTECTED] WWW: http://www.ee.bgu.ac.il/~elady Dept. of ECE, BGU, Beer-Sheva, Israel, 84105. 972-8-647-2417. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] MSVC 6.0 Problem with systems/vacuum/vacuum.cxx
I changed my copy to use min() rather than fmin() (W2K, cygwin, gcc version 2.95.3-5 (cygwin special)). Builds, links, and appears to run OK. Richard > -Original Message- > From: Bernie Bright [mailto:[EMAIL PROTECTED]] > Sent: 24 September 2002 10:34 am > To: [EMAIL PROTECTED] > Subject: Re: [Flightgear-devel] MSVC 6.0 Problem with > systems/vacuum/vacuum.cxx > > > On Tue, 24 Sep 2002 03:46:54 -0400 > "Norman Vine" <[EMAIL PROTECTED]> wrote: > > > Bernie Bright writes: > > > > > On Mon, 23 Sep 2002 18:51:25 -0700 > > > Jonathan Polley <[EMAIL PROTECTED]> wrote: > > > > > > > MSVC does not have fmin() defined, so complains in vacuum.cxx. > > > > > > > > > > gcc 2.95.3 complains too. fmin() is only defined if > _ISOC99_SOURCE is > > defined before including . > > > > I wonder if we are going to need a sg_math.h > > if so here is a first stab at one > > > [cut] > > Well, as far as I can tell, fmin() is C99 not Std C++. We > could use std::min() but that causes a problem with MSVC > where you have to use cpp_min() instead. And so it goes on... > > Bernie > > ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MSVC 6.0 Problem with systems/vacuum/vacuum.cxx
On Tue, 24 Sep 2002 03:46:54 -0400 "Norman Vine" <[EMAIL PROTECTED]> wrote: > Bernie Bright writes: > > > On Mon, 23 Sep 2002 18:51:25 -0700 > > Jonathan Polley <[EMAIL PROTECTED]> wrote: > > > > > MSVC does not have fmin() defined, so complains in vacuum.cxx. > > > > > > > gcc 2.95.3 complains too. fmin() is only defined if _ISOC99_SOURCE is > defined before including . > > I wonder if we are going to need a sg_math.h > if so here is a first stab at one > [cut] Well, as far as I can tell, fmin() is C99 not Std C++. We could use std::min() but that causes a problem with MSVC where you have to use cpp_min() instead. And so it goes on... Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] 3D-clouds and HUD markers
Hello, did you recognize that some markers in the HUD display disappear when 3D-clouds come in sight ? Shortly after takeoff, when looking at the clouds, I see a HUD like this: http://document.ihg.uni-duisburg.de/bitmap/FGFS/Clouds3D_07.png After taking down the nose a little bit the clouds disappear and the HUD gets reappears completely: http://document.ihg.uni-duisburg.de/bitmap/FGFS/Clouds3D_08.png Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Improved 3D panel
> Hmmm...I can see clearly there that culling isn't the problem. Are you having > any problems with other models? BTW the offets are from the 3D Model's origin > (0,0,0) which in this case is about 3 meters behind the pilot on a line that > crosses the leading edge of the wings about halfway down the sweep. Thanks for the explanation. Unfortunately, after pulling recent changes from CVS this morning, the panel display turned bad as known from the last months: http://document.ihg.uni-duisburg.de/bitmap/FGFS/Clouds3D_05.png http://document.ihg.uni-duisburg.de/bitmap/FGFS/Clouds3D_06.png Please note: All screenshots were taken with these settings: --disable-clouds --enable-clouds3d Martin. P.S.: I had to remove the connections to the Vacuum subsystem to get FlightGear compiled and linked correctly. You already discussed this in another thread. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Caravan model
I took it upon myself to email cessna last night in the hope that they might be able to supply me with some line drawings and a few useful bits of technical data for the caravan model. I did point out that the info would be used solely for this project and as such would be re-distributed under the terms of the project. I don't expext they will want to help given that the caravan was a major selling point in their relationship with M$ for FS2002, but if you don't ask you don't get ;-) If anyone here knows of any good line drawings to help with the model I'd be most grateful. Regards, Matt. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] RE: Electrical system
To avoid things getting very complex very quickly it might be easier to take a very simplistic apporach and model the batteries chief characteristics such as terminal voltage, and ampere/hour capacity. Since there is no such thing as a perfect power source you could go to much more detail - modelling the internal resistance of the battery and it's own capacitive and inductive load characteristics for example. But for the beginning surely we just need to know how what voltage it will supply and how much current capacity is available don't we? I think this would make it easier for situations like alternator offline or (as happened almost every flight in a C206 I know of!) the fan belt coming off mid-flight. I'm sure in these situations one would want to turn off everything but the essential items like the radio etc. - as I'm not a pilot (yet!) I don't know. Furthermore, if we need more accurate battery discharge modelling to represent the inherent voltage drop when the load approaches or exceeds the maximum the battery can supply in it's current condition we can have generic functions in code to model the behaviour and supply the values for the specific case from XML. Just my 2p worth :-) What do people think? Regards, Matt. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MSVC 6.0 Problem with systems/vacuum/vacuum.cxx
Bernie Bright writes: > On Mon, 23 Sep 2002 18:51:25 -0700 > Jonathan Polley <[EMAIL PROTECTED]> wrote: > > > MSVC does not have fmin() defined, so complains in vacuum.cxx. > > > > gcc 2.95.3 complains too. fmin() is only defined if _ISOC99_SOURCE is defined before including . I wonder if we are going to need a sg_math.h if so here is a first stab at one cut #ifndef __SG_MATH #define __SG_MATH #include #if defined(_MSC_VER) && (_MSC_VER >= 1300) #include #endif #if (defined(WIN32) && !(defined(_MSC_VER) && (_MSC_VER >= 1300)) ) || \ defined (macintosh)|| \ defined (sun) || \ defined (__DARWIN_OSX__) #include #ifndef acosf #define acosf (float)acos #endif #ifndef asinf #define asinf (float)asin #endif #ifndef cosf #define cosf (float)cos #endif #ifndef sinf #define sinf (float)sin #endif #ifndef logf #define logf (float)log #endif #ifndef powf #define powf (float)pow #endif #ifndef sqrtf #define sqrtf (float)sqrt #endif #ifndef fabsf #define fabsf (float)fabs #endif #ifndef isnanf #define isnanf (float)isnan #endif #endif #if (defined(WIN32) && !(defined(_MSC_VER) && (_MSC_VER >= 1300)) ) || \ defined (macintosh)|| \ defined (sun) || \ defined (__DARWIN_OSX__) ||\ defined (__hpux__) #ifndef floorf #define floorf (float)floor #endif #endif #endif // __SG_MATH ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
