Re: [Flightgear-devel] Engines on c310
Curtis L. Olson writes: Also, the presets dialog doesn't appear to do anything when you click ok or apply. OK and apply copy the values from the dialog to the presets; they do not apply the presets. We probably need to make that more intuitive. 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] Engines on c310
Curtis L. Olson writes: Is there any mechanism yet to apply the presets? I haven't been able to find it. Yes, the big button at the top that says Revert to Defaults (since we're setting default values). Please feel free to play around with the dialog to make it more intuitive. Also when I try to select File-Reset I get No command attached to binding That was a typo in menubar.cxx -- I've just checked in a fix. 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] When talking about bridges ....
Arnt Karlsen writes: ...which would warrant both runtime and compile time options like --build-invisible-walls-under-bridges, and --tip-fbi... ;-) I'd prefer --tip-interpol: after all, this is an international project. Sometimes there are legitimate reasons to fly under something -- not that often, but sometimes: for example, a helicopter doing a low-level hydrographic survey might pass under a very high bridge, as might a helicopter on approach to a shoreline helipad. There is no reason at all that a seaplane shouldn't water-taxi under a bridge. 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] J3 Cub -- sitting in the backseat
Jim Wilson writes: It doesn't in 24 bit. With the 3D instruments there is a tradeoff between accuracy and z-fighting. The further out the needles are the more error there is even at shallow view angles. Hmmm...maybe it would be useful to have a property that would indicate 16 bit depth buffers. Then all sorts of things (including model animation, lod select) could be conditioned on that property. With that, the xml could be setup to move the needles out 0.005m or something like that. I've been thinking about setting up a few new system-info properties, including OS and colour depth, just for that kind of thing. I can live with the z-buffer fighting for now -- you're not really supposed to look at the instruments much in a Cub anyway (and cannot do so easily with an instructor sitting in the way). How do you like flying from the back in fgfs? I might raise the viewpoint a bit to make it easier to see over the nose, but it's definitely a different kind of experience. 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] Morse numerals
When I tried to ident 3U (a local NDB), I realized that FlightGear did not support numerals in Morse identifiers -- I just kept hearing U ... U ... U. That's fixed now in the current CVS. Just out of curiosity, do no U.S. navaids have digits in their identifiers, not even local NDB beacons? 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] Hi-Res C172-S instruments
Jon Berndt writes: 1) The escape key used to kill flightgear. It doesn't seem to work, now. I got this: No type specified for GUI object Widget exit does not contain a proper GUI definition Remember these two rules: 1. If you upgrade FlightGear and SimGear, then you have to upgrade the base package at the same time. 2. If you upgrade the base package, you have to upgrade FlightGear and SimGear at the same time. 2) The panel takes up the whole screen. I don't know how to make see the panel and the outside view. It's not intuitive at all. The Shift-P option toggles, but the menu options don't seem to be helpful here, either. How do I fix this? That's deliberate -- Curt designed the panel to be displayed on a separate monitor. 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] Logging
I've made a minor change to logging -- all logs and log entries now require an explicit 'enabled' property, set to a boolean true value, or else they will be skipped. I made this change to support the new logging dialog (under State/Logging) that I've just checked in -- you can now log properties without creating XML files and adding them to the command line. The dialog supports logging up to 9 properties to a CSV file, though there's no hard-coded limit in FlightGear internally. 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] DAFIFT progress
James Turner writes: - I uncovered some API inconsistencies between the fixlist and the navlist (some routines taking degrees, others radians, for lat / lon) : which do we prefer? (I'll fix the offenders) In general, we prefer degrees on the user side and radians on the math/physics side. 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] TACANs (was DAFIFT progress)
James Turner writes: So, armed with the knowledge that TACANs are UHF, not VHF, and that they use military channel codes, I went and looked at the DAFIF fields again ... and guess what the field two after FREQ is? Yeah, it's the channel. Boy do I feel silly. It's more complicated than that. DME receivers (which are UHF) can use TACANs to get distance information -- usually, you do that by tuning in a fake paired VOR frequency. For example, if I tune my DME to 108.8, or slave it to a NAV radio tuned to 108.8, I get distance readings from the UPP TACAN at CYOW, even though there's no VOR. Can the paired frequency be deduced from the channel? 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] TACANs (was DAFIFT progress)
James Turner writes: That said, the UPP TACAN is not listed in NAV.TXT, if you know of any others, please let me know and I'll check. (Or did you mean UUP, 'Uplands'?) That's it -- I was giving the ident from memory. 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] Night approach
Here's a nice shot of the 310 on a long, straight-in night approach to runway 06L at CYUL (Montreal/Dorval): http://www.megginson.com/flightsim/cyul-06l.jpg 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] Live property picker
James Turner writes: This was a two hour hack I did to learn a bit more of the code, it was fun to do, and the end result is quite nice. It could use some polish (rounding off some digits), and while performance seems okay I'm worried on 'big' nodes it might be a hit. I'm simply using the propertyNode's changeListener API, so presumable there are some nodes in the tree which are not firing their valueChanged() methods when they should be Currently, the property tree knows about changes only when someone changes a value through it; when a property is tied to C++ code, the valueChanged() method is never fired. 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] Autoconf/Makefile question (slightly OT)
Richard Bytheway writes: I spent a little while last night trying to figure out what to change to get plib/SimGear/FlightGear to install using install -cp rather than just install -c. I got horribly stuck. Can someone point me in the right direction? INSTALL=/usr/bin/install -pc ./configure The problem is that this will not survive when the makefiles automatically rerun configure, unless the INSTALL environment variable is permanently set. 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] Live property picker
James Turner writes: If so, seems like we're kind of shooting ourselves in the foot or am I just being super-anal and should just poll them as Jim Wilson suggests? This is a good discussion to start. I'm inclined to eliminate tying altogether and have every module set properties explicitly; what does everyone else think? 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] Live property picker
Tony Peden writes: This is a good discussion to start. I'm inclined to eliminate tying altogether and have every module set properties explicitly; what does everyone else think? I'd really like to see tying stay in. I'm not sure we ever would have incorporated the property tree into JSBSim without it. In that case, if we want change events to work, we'll have to do one of the following: 1. Require every module that ties a property to fire an update event whenever the value changes; or 2. Poll tied properties with change listeners attached inside the property system and fire the events when appropriate. I'd be include towards #2, since it would centralize the polling and do it only when actually needed. 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] Live property picker
Frederic BOUVIER writes: But I don't think there is a huge penalty here. Classes that are doing tying now must store the SGPropertyNode as a separated pointer for tying and untying. They don't, actually -- the property manager takes care of storing the node. You just do something like fgTie(/foo/bar, this, Foo:getBar, Foo:setBar); at the start, and fgUntie(/foo/bar); and the end, and for the rest of the time you can pretend the property system doesn't exist. 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] Live property picker
Jon Berndt writes: Let me add that in JSBSim (and for that matter probably any FDM) just offhand I'd say that almost all of our properties will be changing every single frame. Aircraft state and EOM are dynamic things. I think that we can centralize this and make it invisible to JSBSim and other suppliers of property values. Polling inside the property manager makes sense, since a) it will be done only on demand (when someone assigns a listener to a property), b) it will be done only once for each property, no matter how many other routines are listening to it, c) it will create no extra work for anyone. 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] OT: 100 Hours
I passed 100 hours total flying time today, while practicing holds and approaches under the hood in C-FBJO. 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] OT: 100 Hours
Jim Wilson writes: Wow! Not bad for...what is it? 8 months since you started? Give or take. Thanks, 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] [more or less OT] Map Projection on Navigation Displays
Norman Vine writes: This works fine for a 'map' but straight lines will not be great circles which AFAIK is still the standard for *most* aviation 'charts', both paper and electronic versions It depends on scale. World Aeronautical Charts (1:1,000,000) and VNCs/Sectionals (1:500,000) use Lambert Conformal Conic projection, so that (as Norm suggests) a straight line drawn on the chart will really be a great circle. VFR terminal area charts (1:250,000) use Transverse Mercator projection since they cover a smaller area. 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] Viewer suggestion: acceleration effects
For the cockpit view, it might be interested to add optional acceleration effects to make up for the lack of full motion -- I think I first noticed this trick in Battle of Britain. The FDMs already publish the required information in the property tree: /accelerations/pilot/x-accel-fps_sec /accelerations/pilot/y-accel-fps_sec /accelerations/pilot/z-accel-fps_sec What we'd do is tilt the cockpit viewpoint slightly for any strong forwards/backwards or sideways accelerations. For example, a strong, forward acceleration (like a takeoff roll in a fighter jet) might tilt the view pitch angle up a degree or so, while a strong deceleration might tilt the head forward about the same amount. Sideways accelerations would cause the head to tilt sideways similarily (the view roll angle). Vertical accelerations are trickier, since they're roughtly perpendicular to the spine. The best thing here would be to adjust the vertical view offset by half an inch or so down for a strong upwards acceleration (being pushed down into your seat) or up for a strong downwards acceleration (straining up against your lap belt). If we want these to be useful and not cheesy, they'll have to be very subtle in most normal flight (i.e. a fraction of a degree) except for special situations like the initial part of the takeoff roll or heavy braking. On the other hand, if the plane is being flown by a ham-fisted sim driver, we could rock things around a little more as would be happening with real passengers (Alex has also suggested splattering the panel with virtual vomit). Jim: are you interested in adding this to the viewing architecture, or would you like me to take a try in a week or two? I don't claim to fully understand how to use these, but you can look at src/Instrumentation/slip_skid_ball.cxx for a sideways-acceleration example I ripped off from Alex's old steam code. 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] Live property picker
James Turner writes: I think that we can centralize this and make it invisible to JSBSim and other suppliers of property values. Polling inside the property manager makes sense, since a) it will be done only on demand (when someone assigns a listener to a property), b) it will be done only once for each property, no matter how many other routines are listening to it, c) it will create no extra work for anyone. I'm happy to have a go at this, or do you (David) want to take a look? i agree it's far and away the best suggestion I've heard in terms of non-impact on the code, efficiency and so forth. Go for it -- I probably won't be able to get to it right away. 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] Viewer suggestion: acceleration effects
Andy Ross writes: I'd give this more general idea a shot first, before trying axis-specific code. The axis-specific stuff is easier for me to understand -- perhaps someone with a stronger physics background could work with Jim to do a generalized, spring implementation. 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] Viewer suggestion: acceleration effects
Michael Selig writes: Sounds useful. Can I suggest that this feature be enabled/disabled at the option of the user? Yes -- that's why I mentioned it should be optional. It would make no sense if FlightGear were hooked up to a full-motion sim (or even just a moving chair). 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] Viewer suggestion: acceleration effects
Tony Peden writes: On Sat, 2003-02-08 at 19:53, Curtis L. Olson wrote: I agree with Michael though that whatever we do with respect to providing motion queues through the visual system should be user selectable. Any time your eyes (visuals) disagree with your butt eh, hemm. Inner ear. All three, I think -- the brain also uses pressure on the feet or posterior to establish balance. 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] xml property documentation
Erez Boym writes: If not, I have tried to find the xml parser in the source tree with no luck, where would be the best place to start reverse engineer the xml parser to produce such documentation ? The XML parser is in SimGear, but you don't need it -- FlightGear already holds the preparsed property tree in memory. 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] Updated set of goals?
Jim Wilson writes: Yes, and it could be handy to turn a c172 into a c310 right after engine failure while flying through hells canyon. Or fun to get a jet up to mach 1.2 and then turn it into a cub. :-) We need to animate the fabric ripping off the wings just before the wooden spars snap. 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: xml property documentation
Martin Spott writes: As far as I know, no one has started documenting the propperly, mainly because they tend to change rather quickly. You probably hit the nail ;-) Aside from that, there will probably be a major restructuring when we add multi-vehicle support. 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: xml property documentation
Erez Boym writes: Well, I'm new to FlightGear tweaking, but I find it strange that to use flight gear (Add objects, add aircrafts etc.) you have to search the source files, just to find these xml properties that will enable me to do that work. You can also examine the tree live in the online property browser -- that's probably the best approach (it's the one I use). I agree that we need documentation, but no one has stepped forward and volunteered to write any. I disagree with Norm that all FlightGear development should stop until that documentation is written -- if we used that rule, we wouldn't have ATC, 3D cockpits, runway lighting, and just about everything else interesting that's appeared in FlightGear over the past couple of years. In my inexpert eyes it's something we must maintain otherwise we limit FlightGear usage to code reader experts that can tweak the source files. Normal users that only want to add things to flight gear would be left out or bug mailing lists for these properties. If you're volunteering, you're very welcome. I agree that the work is critical, and it's a good way for a non-coder to make a major contribution to the project. 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] ANN: Turbulence
Major A writes: Can you seriously land a plane like this? I think the idea would be to try to let the passengers walk away, whatever condition the plane ended up in (that's assuming that you had no choice but to land). Also, doesn't turbulence get less when you get closer to the ground? I think so -- I'm wondering if we should fade it out within a couple of wingspans of the ground. 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] Turbulence redux
I've made some minor adjustments to the turbulence support for JSBSim in FlightGear: 1. The /environment/turbulence-norm property for JSBSim is now squared before scaling; that way, the hard stuff doesn't hit until fairly late, and more of the range is flyable (I think it's more intuitive). 2. Turbulence does a linear fade-out within two wingspans of the ground. The second item is there merely to annoy Jon into implementing something 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] Turbulence redux
Andy Ross writes: As long as I have you on the line, Andy, how hard would it be for you to adapt the FGAtmosphere::Turbulence() function (in src/FDM/JSBSim/FGAtmosphere.cpp) for YASim? It looks like it should be fairly clean. You would take the per-iteration turbulence vector and add it to the wind at setup time. This happens in YASim.cxx, lines 235-237. Just move the turbulence value to somewhere accessible from the YASim FDM object (properties or whatnot) and add it in. The value gets converted into YASim's internal coordinate system later on; this part is in NED coordinates and should accept Jon's output without change (well, units might need twiddling). Really the only significant code that would have to be written is a patch to get FGAtmosphere::Turbulence() to export the velocity vector. I meant to integrate it by cut and paste. FGAtmosphere is a JSBSim class, so it won't run when YASim is the current FDM. 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] Turbulence redux
Jon S Berndt writes: Here is what's in Turbulence(), now: Well, two CVS checkins ago, anyway. I've integrated your change into the current code base, but still (for now) basing it on HOverBMAC (as used for ground effect) rather than absolute altitude AGL. It seems to work well -- thanks. Jon: check out the latest FlightGear and play with the turbulence at bit -- there a slider to adjust it in the dialog linked to the Weather/Winds menu entry. 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] SeaHawk
Erik Hofman writes: Visual only. It was meant to work on the ground only, but the brakes gets applied whet in the air as well (which is the correct behaviour IMHO). The best thing to do would be to read a new property, like /controls/wings which would be set to something between 0.0 (fully folded) and 1.0 (fully extended). There is no need to make any changes to the C++ code, but it would be useful to bind this property to something (or to add it to a dialog). I don't know how hard it would be to make YASim do something with this property. 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] Piper Cub Flying Hints
My reproduction of the 1946 Piper J3 Cub Owner's Manual arrived yesterday from an eBay seller (my first experimentation with sniping). Most of it contains maintenance information, but I've copied the FLYING HINTS section into $FG_ROOT/Aircraft-yasim/README.j3cub. It has some performance numbers that will help people to fly the plane and will help us to fine-tune the YASim flight model. 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: FlightGear (fwd)
Curtis L. Olson writes: Keith does make a good point, simple test cases are the most ideal in terms of debugging problems, but the flip side is that you run the risk of building drivers that only work on the simple test cases. You need a simple test case that uses lots of polygons and lots of texture memory. 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] YASim washout support
I've added support for wing twist to YASim. The twist allows you to model washout during a stall, so that every stall doesn't result in a violent spin. YASim also has an undocumented incidence property for wings (in non-aerobatic planes, wings are not usually perfectly level with the fuselage), which I've taken advantage of. Give the J3 Cub a spin with the latest CVS code and base package, and you should find its low-speed characteristics much more docile (as an added bonus, it swerves less when the nose comes up on the takeoff roll, but I'm not sure why). The J3 Cub now has a steerable tailwheel as well. fgfs --aircraft=j3cub 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] YASim washout support
Jim Wilson writes: Now I can take off very quickly (even before it reaches the runway number at KSFO) just by holding the stick back about half way and it'll continue climbing steadily once out of ground effect at about 32 kts. Is that correct for the j3? Was that 32 kt from the HUD, or 32 mph from the ASI? The J3 cub has a stall speed around 25 kt (roughly 30 mph) and is supposed to be able to take off in a 200 ft groundroll and land in a 300 ft roll under ideal conditions. Here's what the 1946 owner's manual says (see $FG_ROOT/Aircraft-yasim/README.j3cub): (1) For takeoff use full throttle, heading into wind. Airplane loaded will become airborne at approximately 39 M.P.H. Best climb speed is an indicated 55 M.P.H. I just ran a test, and with the stick all the way back, my wheels lifted off the ground at around 32 mph (28 kt) indicated, but as would be expected near the stall the plane was hard to control (in real life, I'd also be worried about the forces on the tailwheel). With more realistic back pressure, the tail lifted first, then the Cub took off around 40 mph (35 kt). Best climb speed (Vx) is 55 mph (48 kt), so you'll want to push the nose forward and fly in ground effect for a few seconds before climbing out. At KSFO, remember, you're flying the Cub from a runway built for 747s -- since it's 200 ft wide, you could take off sideways across it (I just tried and was up with 20 feet to spare). Even at a small airport like KPAO, the 2500 ft runway is far, far more than a Cub needs. This is an airplane that was built to take off from little fields or country roads -- I remember seeing an early ad with drawing of a Cub sitting in a parking lot outside a country store, though that's obviously a bit of an exaggeration. 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] J3cub improvements
Dave Perry writes: I just took the j3 for a spin. The stall characteristics are significantly improved. The response to rudder when a wing drops still seems less than in a real aircraft. This could be the range of my pedals. That can be adjusted very easily. Open up $FG_ROOT/Aircraft-yasim/j3cub.xml, find the vstab element, then play with the lift attribute on the the vstab/flap0 element. The number is currently 1.5 -- if you make it higher, the rudder will become more effective. I also noticed that the climb was very laborous Vx is supposed to be 55 mph and Vy is supposed to be 65 mph; however, I'm getting a good climb rate at 55 and an anemic one at 65, so the model clearly needs a little tweaking. What climb speed did you use? and when I cut power, it did not glide far. Did you increase the drag, or is it that it defaults to the door open? The real cub has a rather shallow glide. What glide speed did you use? I think Vglide is supposed to be around 60 mph, but I'm not sure that's where it is in the model right now. On another note. About the time that version 8.0 was released, I had submitted a change to the j3cub.xml animation for the ailerons that used interpolation to leave the bottom of the ailerons parallel with the bottom of the wing with the stick in neutral. I'd rather fix that in the 3d model. I'll be happy to put in a patch for the differential aileron deflection, though. 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: J3cub improvements
Dave Perry writes: I flew the j3cub again and I take back my assesment of the climb and glide. It appears that it starts with significant nose down trim. Thanks. Actually, I think you did find a real problem with the v-speeds, but I'll keep working on it. The Cub should start at neutral trim -- is there something else (i.e. your joystick) pushing the trim forward? What is the value of the /controls/elevator-trim property when you start up? This is still one of my favorite aircraft in FlightGear. Keep up the good work! Thanks. It will be even more fun when we model bumpy surfaces. 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] YASim washout support
Curtis L. Olson writes: I've also heard that if you fly tight enough circles, you can lower a rope with a bucket from your aircraft and actually exchange stuff with people on the ground ... kind of like an low budget (low payload) hover. :-) If you are landing into any kind of headwind, you can get out and job beside the plane for a while in the flare to make sure the tires are inflated. 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] YASim bug: airspeed
I've found a serious, and surprisingly not-previously-detected YASim bug. The calibrated airspeed does not allow for wind. Here's an easy way to test it: 1. Take a YASim plane (such as the J3 Cub), fly to altitude, then level out. Note exactly where the horizon is on the screen, and record the indicated airspeed from the panel (mph) or HUD (kt). 2. Pause the sim, go to the wind menu, and set a 20kt headwind. Unpause, and adjust so that the horizon is at the same position as before (the nose will try to rise up initially). You should note that the indicated airspeed in the HUD (if open) and on the panel is 20kt lower than before. 3. Pause the sim again, go to the wind menu, and set a 20kt tailwind. Unpause and bring the horizon back to the same spot again (the nose will initially plunge). You should note that the indicated airspeed is now 20kt higher than before. Before I plunge in to try to fix this, does Andy (or anyone else) have any suggestions? It looks like there is code that is *supposed* to subtract the wind from the airspeed, but it obviously isn't working. 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] YASim bug: airspeed
Andy Ross writes: Is the problem with the CAS output number, or is the whole simulator ignoring the wind? Fortunately, it's just the CAS output number. I tried doing a full-stall landing into a 25 kt headwind in the J3 Cub and was able to set it straight down like a helicopter -- it's just that the ASI is off. If it's just the output, the problem is likely in YASim.cxx; maybe it's using an absolute velocity incorrectly where it should have to add the wind itself? Here's your code: // Airflow velocity. float wind[3]; wind[0] = get_V_north_airmass() * FT2M * -1.0; // Wind in NED wind[1] = get_V_east_airmass() * FT2M * -1.0; wind[2] = get_V_down_airmass() * FT2M * -1.0; Math::tmul33(xyz2ned, wind, wind); // Wind in global Math::sub3(s-v, wind, v); // V - wind in global Math::vmul33(s-orient, s-v, v); // to body coordinates _set_Velocities_Wind_Body(v[0]*M2FT, -v[1]*M2FT, -v[2]*M2FT); _set_V_rel_wind(Math::mag3(v)*M2FT); // units? Hmm. Should the fourth last line be this instead? Math::vmul33(s-orient, v, v); // to body coordinates I'll give it a try. 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] YASim bug: airspeed
David Megginson writes: Hmm. Should the fourth last line be this instead? Math::vmul33(s-orient, v, v); // to body coordinates I'll give it a try. Yes, that was 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
Re: [Flightgear-devel] Re: Flightgear and lighting
Erik Hofman writes: I'm afraid you are on the wrong track. Emissive, is just what it says. It adds light emission to the textures (to make them brighter). That's right. If you want to see what happens, try the same thing at night, and the whole world will be flood-lit. There must be some kind of gamma parameter available for the X11 config file. 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] airspeed and headwind
David Culp writes: It looks like there is code that is *supposed* to subtract the wind from the airspeed, but it obviously isn't working. This made me curious. Does FlightGear simulate windshear? To simulate windshear properly (i.e. in the right place at the right time and magnitude), we would need to do a lot of meteorological work that we're not doing right now. However, you can get the effect of windshear by specifying a large gust factor fgfs --wind=180@10:40 or by giving a JSBSim-based flight model a large turbulence value fgfs --prop:/environment/turbulence-norm=0.5 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] airspeed and headwind
Curtis L. Olson writes: I guess I don't really know now that I think about it, but I always thought of windshear more as a singular event as you pass from one layer of wind to another rather than continuous high turbulence. If I'm wrong just ignore the rest of this. Wind shear is any vertical or horizontal change in wind that is fast enough to cause a change in airspeed. Passing through a front or into/out of an inversion are two possible causes. 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] airspeed and headwind
Curtis L. Olson writes: If things turn u [1] Blue line is the speed below which the rudder cannot overcome the torque effects of a single engine and you can no longer have directional control. I think that blue line is a bit higher than Vmc -- it's a speed where a typical pilot (rather than a highly-skilled test pilot under ideal conditions) might actually be able to control the plane. It's not mainly torque effects but the yawing moment that you have to worry about. Unless the plane is a centreline thrust, the good engine will be off to one side pulling that side forward and starting a yaw-induced roll (and if the bad one is not feathered, it will be dragging the far side back even further). In fact, if things start to go bad, the last-ditch solution is to cut the good engine as well -- if you do that in time, you can at least try a forced landing. A Navajo pilot over Winnipeg did that a couple of years ago in an apparently unsurvivable situation (low-altitude engine failure over a dense urban area) and managed to land on a busy city street with no fatalities, though some passengers suffered serious injuries including leg amputations). The plane somehow avoided killing anyone on the ground as well. That's actually the time you'd rather be in a single, because even a light twin is heavier and has a higher stall speed -- that means that you might have many times as much energy to dissipate in a forced landing. I would guess that *many* designs (especially commercial jets) would be much more survivable in those circumstances. And they'd have the added advantage of having a real pilot at the controls. :-) ... who, to keep their jobs, have to demonstrate those skills in a full-motion simulator twice a year with a DFE watching every move. I've noticed that many private multiengine pilots do recurrent training every six months as well (FlightSafety Intl. seems the place of choice) -- it's a big change from flying a single, and you have to be very, very current if you want to stay alive. 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] Navaids and fixes from DAFIF
I'm currently checking new files Navaids/default.nav.gz and Navaids/default.fix.gz into the base package. These are generated directly from DAFIF files (I've checked in my Perl scripts as well), so they will be easy to keep up to date. The navaids file is a moderate improvement, adding a couple of thousand additional navaids around the world; the fixes file is a major improvement, increasing the number of fixes from 16,000 to 71,000 -- that will be a good foundation for adding GPS support to FlightGear in the future. 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] Navaids and fixes from DAFIF
Curtis L. Olson writes: In the spirit of keeping code separate from data, would it make sense to put the scripts somewhere in the source tree? Maybe scripts/ or src/Navaids/? Sure -- I just dumped them there for now. Someone suggested earlier that we should modify FlightGear to read the DAFIFT format directly, and I think that's a good idea; at that point, the scripts would be obsolete. 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] Navaids and fixes from DAFIF
Curtis L. Olson writes: I should also say this really cool to be able to incorporate this data directly. In terms of fixes though 72000 is an insane amount. For anyone wanting to actaully draw these on a map, there is going to have to be some sort of data reduction strategy. Does the DAFIFT file give any hints or ranking of which are the more important or more widely used fixes? There's about 15 fixes right on or very near the KSFO airport property. Different intersections and fixes server different purposes: the ones around KSFO are probably parts of various instrument approaches, and we would need most or all of them to simulate ATC or an approach-certified GPS. Just around Ottawa TCA, we have quite a few intersections. Here are the ones you'll find on an enroute chart, serving both for navigation through the Ottawa area and for transition from enroute to approach: LORKA EBNYR ASHTN AGLIN THURO AVVON REEDO ULAMO LANRK CYRIL HUXLY FANOL But those don't tell nearly the whole story. Most instrument approaches add more waypoints that don't appear on the enroute charts. For example, the ILS or NDB 32 approach adds the TEXEN GPS fix, while the ILS or NDB 07 approach adds the VISOL GPS fix. And so on. The DAFIF contains quite a few additional fields, including a usage code -- you could use that as a filter for generating different kinds of maps. 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] Modesto Two Arrival
Here's a STAR into KSFO from the west, with lots of waypoints for anyone who'd like to try out the new options and the new fix database: http://edj.net/cgi-bin/echoplate.pl/echoplate.pl?Arrivals/MODESTO%20TWO.GIF All of the five-letter names like FAITH and GROAN represent waypoints that you can specify to FlightGear using the --fix option. 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] Navaids and fixes from DAFIF
Curtis L. Olson writes: The one area to be careful of is airports, runways, and taxiways of course. I'd hate to lose a lot of the hand edited data from X-Plane for airports that aren't available in DAFIFT (and for all the taxiways.) Agreed -- we should stick to ILS, navaids, and fixes for 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
Re: [Flightgear-devel] Navaids and fixes from DAFIF
Curtis L. Olson writes: That might be the thing to do. Fixes are something I'd have no hesitation to switching to DAFIFT format. We should also consider whether we want to compress the DAFIFT files. They take much more disk space uncompressed, but presumably CVS updates would be significantly faster, since they would exchange only deltas (or does the whole file come anyway?). 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] many external models w/ GNU GPL permission
Michael Selig writes: Caveats: Most of the airplanes still need corresponding flight models. That shouldn't be too hard. The challenging part is designing the interiors. 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] DAFIFT navids
James Turner writes: Sorry to muck people (esp David, by the sound of it) around, but I have 'live' DAFIFT importing working in my local tree (for about 3 weeks now), I've just been holding off submitting while I did more testing. I've had to extend the Nav types and APIs slightly, to cope with multiple fixes / intersections, and a few other things. On the contrary, I will be thrilled to remove this from my TODO list and to throw out my Perl scripts. Before I do that, I'll mention a few gotchas I found in the NAV file and how I dealt with them: 1. For VORs, we're interested in the slaved magnetic variation; you can always ignore the actual one, since we calculate that inside FlightGear anyway. 2. Entries for TACANs have only a channel, not a paired VHF frequency. By trial and error, I've figured out how to get the VHF (I think): - if the channel number is less than 57, use the formula 108 + ((channel - 17) / 10) - if the channel number is greater than or equal to 67, use 112 + ((channel - 67) / 10) I'm not sure why there is an unused band of 10 channels from 57-66. 3. Entries for civilian DMEs also have only a channel. You can use the same formula as you used for TACANs, but you have to add 0.05MHz to every one (I don't know why, but that is the pattern I found on the charts). 4. You have to split the NDB/DME entries into two to make them usable for FlightGear. The DME channel will be provided, so handle it as above to get a paired VHF frequency (tuning the NDB will never automatically tune a DME). 5. Non-U.S. VORs don't have a range provided, but they do have the usage code -- you can kludge a range from that (I used 200 nm for 'H' or 'B', 20 nm for 'T', and 50 nm for anything else). 6. Ditto for non-U.S. NDBs, DMEs, and TACANs, but I'm not so sure about my numbers in those cases. So far I'm reading the WPT, NAV and ATS files, about to move on to the ARPT files. I only read a few fields right now but extracting more is trivial. BTW, if we read the DAFIFT ARPT data, do we still need metakit for anything? Reading the DAFIFT files is surprisingly fast, even using brutal, non-indexed schemes (I run through every line in the 18mb airway file each time I instantiate an airway, and the performance seems fine, I expected it be crushingly slow) I don't need any arm-twisting to dump Metakit -- these are tiny databases for modern computers (that 20-second porn video clip your roommate/son/neighbout just watched probably needed several times as much memory as all our nav/arpt data put together). I can get the NAV and WPT stuff over to Curt / David today if there is interest, Yes, please. I'd also be interested in ILS. 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] DAFIFT navids
James Turner writes: 2. Entries for TACANs have only a channel, not a paired VHF frequency. By trial and error, I've figured out how to get the VHF (I think): snipped scary conversion Err, I'm not sure this is correct. the VORTACs have an explicit frequency as well as a channel, and a straight TACAN isn't receivable using a VHF NAV radio, is it? No, but it's receivable by a DME, which uses the paired VHF frequency for tuning -- at least, I tune the DME in my plane to 108.8 to receive the UUP TACAN (channel 25), or I can tune 108.8 on my NAV1 radio and then set the frequency switch on the DME to REMOTE so that the DME uses the frequency set in the nav radio. 3. Entries for civilian DMEs also have only a channel. You can use the same formula as you used for TACANs, but you have to add 0.05MHz to every one (I don't know why, but that is the pattern I found on the charts). I'm again not clear about this, I assumed these were 'DME only' military installations. Many civilian airports have DMEs without a paired VOR: they're commonly used to establish fixes for approach procedures (at CYOW, we use the TACAN for the same purpose). 4. You have to split the NDB/DME entries into two to make them usable for FlightGear. The DME channel will be provided, so handle it as above to get a paired VHF frequency (tuning the NDB will never automatically tune a DME). I haven't done this, but right now I don't believe the radiostack logic works this way. I think it simply looks for the 'isDME' flags on FGnav. The DME code will (rightly) never look for that flag on the ADF radio. The only way to get the DME part of an NDB/DME is to tune the paired VHF frequency explicitly somewhere, either on the DME itself (which we don't support in our version yet) or remotely in one of the VHF nav radios (which we do support). The same thing happens in real life -- the DME has no connection to the ADF, so you have to tune separately. Perhaps fancy flight management systems in transport aircraft do all that automatically, but we're not modelling those yet. 5. Non-U.S. VORs don't have a range provided, but they do have the usage code -- you can kludge a range from that (I used 200 nm for 'H' or 'B', 20 nm for 'T', and 50 nm for anything else). I was going to do this, but various people indicated these values were bogus and we'd be better using the 'practical approximation' you and Norman discussed a few weeks back. We definitely want to use that practical approximation to establish the minimum range, but a maximum range would also be helpful (a weaker signal will still not go as far). The FAA service volumes are a little silly, but we can assume that a terminal VOR has less power than a low-level-only VOR, which in turn has less power than a high-level VOR. Supporting new types is trivial. I would greatly prefer to switch the airport data over too, simply for consistency in the data set. Can anyone establish what (if anything we would lose by doing so?) I'd stay away from the airport data for now, since DAFIFT contains no information about taxiways. 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] animation types: translation and scaling
Michael Selig writes: I am wondering is it possible to translate an object? I am working on an ornithopter flight dynamics model (http://www.ornithopter.net) and the center piece of the wing translates. (I currently use Lee's Hawker Seahawk!) Yes, absolutely. Here are the animations we currently support: range: set the minimum/maximum range where the object is visible billboard: rotate the object to face the viewer (one or two axes) select: make the object appear or disappear spin: rotate the object continuously at a certain rate timed: select different variants of an object at different times rotate: rotate an object translate: translate an object You can combine these for more complex animations, and you can use interpolation tables for non-linear movements. Also, with plib/fgfs is it possible to scale an entire 3D external model? Plib doesn't include a scaling transformation -- when I asked Steve Baker, he said that it would screw up all of the FOV code. You'd be better to open the model in a 3D editor and scale it in advance. 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] DAFIFT navids
Martin Spott writes: I think merging this stuff has been on Robin's TODO for quite some time - but he did not manag to to it because apparently this requires a huge amound of manual editing, A simple either/or merge is manageable -- probably a day's work. The trick is to apply some automated heuristics to help the merge (for example, two airports with different identifiers located within 0.5nm are very likely the same one; flag for a human to verify). The hard part would be moving the XPlane taxiway data to the (more accurate) DAFIF runways. 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] Navaids and fixes from DAFIF
Jon Stockill writes: AIUI you'd get the whole file if it was compressed, because it's a binary file, where you'd just get diffs if it's left as text. I was pretty sure that that was the case, as well, but I'm concerned that sometimes CVS sends the whole file anyway. Are there any CVS experts on the list? 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] Navaids and fixes from DAFIF
Jon Stockill writes: The problem you have in using different sources for ILS and runways is that the two may not always line up. As far as I know, Robin takes the ILS positions from published sources rather than manually tweaking them to line up with his runways. 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 : Last time more on CVS ....
Danie Heath writes: Hopefully the last time I bug about CVS ... if I have modified any of the files, how do I get the changes to be included ? I have started creating an authentic cockpit for the old Gooney bird ... I'm very glad to hear that. CVS is not a classless society -- some users have the right to commit changes, but most don't (the 'anonymous' user rarely does). To start, e-mail your changes to one of the maintainers. Once you end up having many contributions accepted, you may get direct CVS access yourself (while it's not classless, at least classes are merit-based). Would you like a copy of my Blender sources for the DC-3 3D model, or are you basing your work on another external model? 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] Airport, nav-aids, fixes and airways
Robin Peel writes: I have finally subscribed to this list ... Welcome, and on behalf of all of the FlightGear users and developers, I'd like to thank you for all the data you've given us for the past few years. 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] Update rate of VSI
Danie Heath writes: Something I picked up on the Vertical Speed Indicator if I'm in a climb, and I adjust my flightpath to level flight, it's as if the VSI takes ages to return to the correct position. I've tried of fixing it, but it seems it's not defined in the XML file for the particular instrument ... any ideas ? The VSI uses a lag filter. It might be too slow right now, but a real-life VSI (other than the expensive, instantaneous ones) can take a very long time to settle as well. If you want to play around, look at src/Instrumentation/vertical_speed_indicator.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] Update rate of VSI
Andy Ross writes: That said, it does seem to me that the current VSI seeks awfully slowly. It has a half life of, I'd guess, 5-6 seconds or so. Do real gauges take this long? I'll keep an eye on mine this evening and let you know. 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] Update rate of VSI
David Megginson writes: That said, it does seem to me that the current VSI seeks awfully slowly. It has a half life of, I'd guess, 5-6 seconds or so. Do real gauges take this long? I'll keep an eye on mine this evening and let you know. Sorry -- I forgot to. On the bright side, I've finished all the hours for my night rating. 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] keycodes
Michael Selig writes: Maybe someone can point me in the right direction. In keyboard.xml there are numbers assigned to the keys, but when I do a google search for things like keycodes those numbers don't agree w/ the number assignments in keyboard.xml. Is there a list of keys and the corresponding numbers for them. For the special keys, we use the GLUT code + 256. 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] Speed Bottlenecks in FlightGear
Jon Berndt writes: One thing you could try is running JSBSim on the same machine in stand alone mode and connect it to FlightGear using the network interface (is this already possible)? There is an experiment that is sort of in-work, but not fully staffed. I think that's a wonderful idea for many reasons, but I'd be amazed if people saw any measurable speed-up; the FDM just uses too few cycles to matter. No one has profiled FlightGear for a while -- perhaps we should start there. 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] cycling w/ right mouse button pause
Curtis L. Olson writes: Yes, I observe this problem. Also a related problem is that incoming network packets are not read. What's going on is that when the sim is paused, the subsystems are not executed, but some of these things should be executed even when the sim is paused ... I haven't had time to look into it yet. David Megginson is the architect of the flightgear subsystem system so it's all his fault. :-) Yes it is. I don't think it will take too much work to fix. 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] Update rate of VSI
Tony Peden writes: It might make more sense for such instruments to have a start here mode. In other words, a mode in which its possible to set the initial value without going through the dynamics modeling. I've added a line to set the internal pressure to ambient pressure at initialization time. Unfortunately, at that point, ambient pressure is always sea-level pressure. Still, it helps at low airports like KSFO. 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] Update rate of VSI
Tony Peden writes: Does it matter? FGInterface::update() is not being called, so no data is being exchanged (unless your looking at the FDM specific properties) Right. The problem is just that the elevation changes after the instruments are initialized. 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] animation types: translation and scaling
Michael Selig writes: In this case I need to translate the lower linkage and also rotate it. Are there any existing examples of how to combine these motions in the -model.xml file? Yes, take a look at the animation code for the Fowler flaps on the 172P in $FG_ROOT/Aircraft/c172p/Models/c172p.xml (they slide back as they rotate down): animation typetranslate/type object-nameLeftFlap/object-name object-nameRightFlap/object-name property/surface-positions/flap-pos-norm/property factor0.15/factor axis x1.0/x y0.0/y z0.2/z /axis /animation animation typerotate/type object-nameLeftFlap/object-name property/surface-positions/flap-pos-norm/property factor30/factor center x-m0.76/x-m y-m-0.53/y-m z-m0.32/z-m /center axis x0.0/x y1.0/y z-0.1/z /axis /animation animation typerotate/type object-nameRightFlap/object-name property/surface-positions/flap-pos-norm/property factor30/factor center x-m0.76/x-m y-m-0.53/y-m z-m0.32/z-m /center axis x0.0/x y1.0/y z0.1/z /axis /animation 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] Instruments
Erik Hofman writes: How is an instrument build up at this time, is everything drawn in a texture and is this texture placed on the panel, or is everything drawn directly on the panel itself? The 2D panel code creates an instrument out of a collection of stacked, textured rectangles. I'm not sure what Andy did to make them appear in a 3D cockpit. 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] getting DME signal
David Culp writes: Can someone tell me how to get a DME signal from the KSFO ILS/DME RWY 28R (freq 111.7)? Or from any DME transmitter for that matter. I've never flown an airplane that required or allowed for tuning of DME. For the DME radio we have currently in FlightGear (which is not based on any particular real-world model), do this: 1. Tune one of the nav radios to 111.7 (it's already in the standby frequency for nav1 by default, so just swap). 2. Change the switch on the DME radio N1 or N2 (depending on which radio you used. 3. Once the distance is displaying, change the switch on the DME radio to HLD -- now the DME will stay tuned to 111.7, even if you change the nav radio. In real life, it is usually possible to tune a DME radio directly. 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] getting DME signal
--prop:/radios/nav/frequencies/selected-mhz[0]=111.7 --prop:/radios/nav/radials/selected-deg[0]=282.0 --prop:/radios/dme/switch-position=1 I think I should be getting a DME signal, although the in-range property is always false and I'm not getting any distance. I've also tried to get DME from the SFO VOR, with no luck. BTW, the localizer and GS signals from the 28R ILS work fine. I received a DME signal with no difficulty using the 172 panel. Perhaps you could try that, and browse the property tree to see what's actually set. 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] Multiplayer
Duncan McCreanor writes: My name is Duncan McCreanor. I am employed as a Software Engineer for an Australian company where we have been looking at the possibility of using Flightgear as the basis for an Air Traffic Control visual simulator. That sounds excellent. When coding/testing is completed, how do we go about getting the changes reviewed and added to Flightgear? You can send the code to Curt or me. I'd recommend Curt ([EMAIL PROTECTED]), since I have an enormous backlog right now, but I'll try to get to it quickly if it comes to me. If the code is working, even marginally, then you should consider sending it ASAP -- you'll have many more people to help you with the testing and debugging. The nice thing about Open Source is that you don't have to wait until code is fully polished before you throw it out into the world. The other advantage to sending code in now is that if people feel you are going the wrong direction with anything, we can catch it earlier. Thanks, 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] YASim in-air starts
I've done a little more work on YASim initial velocities, and the --vc and --mach options should now work more-or-less correctly (except that --vc doesn't take compressibility effects into consideration). That means that you can start YASim models in the air the same way as you start JSBSim and UIUC models: fgfs --aircraft=747 --mach=0.7 --altitude=3 fgfs --aircraft=dc3 --vc=130 --altitude=12000 fgfs --aircraft=j3cub --vc=60 --altitude=500 --offset-distance=1 The main difference is that YASim does not yet have a trimming routine, so you need to get right on the controls (things are not too bad if you choose a normal cruising speed and the controls start near neutral). 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] J3 Cub -- sitting in the backseat
Jim Wilson writes: BTW if you select j3cub-yasim, instead of j3cub-3d-yasim, you fly from the front seat. Not sure if that was intended. Fixed. Thanks, 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] [PATCH] assert.h required to compile tabbed_values.cxx
Frederic Bouvier writes: I am trying to compile tabbed_values.cxx and found that it requires assert.h to compile with MSVC (on Linux, it must be included indirectly). There is a patch below Committed. Thanks, 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] current bugs
Major A writes: Also, has anyone actually managed to fly a 747 from Europe to the US or the other way round? I just tried that, and first of all, I found it hard to get to a decent altitude (the autopilot keeps stalling it) at a decent speed -- or is 300kt IAS at 3ft normal for a 747? That would be about 480 kt TAS, which doesn't sound too far off. 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] GS in-range
Martin Dressler writes: I'm working on ILS indicator and I'm mising some property which could tell me if glide slope transmitter is in-range or something similar. Is there some property hidden? I also want to ask what it mean needle-deflection and how is it scaled. (ie. does it mean that when vor-needle-deflection is 10 and you have set radial 300, then you are on radial 310) We're not really doing a good job modelling the UHF radios (DME and GS) properly yet -- they are logically-separate receivers with their own ranges, reception issues, and so on, but we initially coded them as just features attached to VHF radios. I'm planning to clean up the radio code and move it into src/Instrumentation/ when I have some time, as I did with the old steam code. 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] Change to default aircraft
Curtis L. Olson writes: Thanks for doing this. I have one minor nit (which is probably an easy thing for a flatlander to miss.) :-) I don't see any way to adjust the mixture (without resorting to the property browser.) Aside from that, it looks great. Not me -- the mixture is the most-used lever on my plane, now that I pay for my own avgas and maintenance. In fact, the Warrior II POH actually recommends using the mixture rather than the throttle to set cruise power for best economy (leaving the throttle wide open), and I've had a lot of success with that -- it has the added bonus of reducing the risk of CO poisoning to virtually nil once the cylinders are all running lean of peak. (For those who are not aware, the rich-of-peak/lean-of-peak debate is the light-aircraft equivalent of the emacs/vi debate, i.e. the closest thing possible to a perpetual-motion machine.) All of that aside, I agree that we should add some hotspots to the panel for people who don't have mixture assigned to anything on their joysticks. We should also add a keyboard shortcut for mixture. 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] Change to default aircraft
Arnt Karlsen writes: ..heh, and you the emacs'er balance that by running lean-of-peak? ;-) I am afraid that I do no understand your insinuation. If I'm on the side of the angels with one, should I not be on their side with both? ..how far back can you drag it before it starts running rough? Without carb heat, I can lean back to between 65% and 75% power, depending on the day and how long the engine has been running. With carb heat on in cruise, I can pull it back much farther, probably right to cutoff if I were so inclined. The nice thing is that I have my Piper POH for backup: For Best Economy cruise, a simplified leaning procedure which consistently allows accurate achievement of best engine efficiency has been developed. Best Economy Cruise performance is obtained with the throttle fully open. To obtain a desired cruise power setting, set the throttle and mixture control full forward, taking care not to exceed the engine speed limitation, then begin leaning the mixture. The RPM will increase slightly but will then begin to decrease. Continue leaning until the desired cruise engine RPM is reached. This will provide best fuel economy and maximum miles per gallon for a given power setting. It's easy to do this with a fixed-pitch prop, since the tach gives a direct indication of power setting at any given density altitude. 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] Change to default aircraft
Arnt Karlsen writes: ..I should have asked: how far back/down of peak temp? Carb heat helps you down the temperatures on leaning way back, how far down? I'll check next time I'm up. I don't trust my EGT all that much, since it measures only one cylinder -- with a fixed-pitch prop, I find myself watching the tach a lot more. I'll see what I get, all the same. 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] Change to default aircraft
Ryan Larson writes: Carb heat on non-fuel injected engines helps keep the venturi from being plugged up by ice. This can happen with air temps as high as 100F and relative humidity of +50%. This normally happens when you are about to land or make a long decent. When you bring the RPM's out of the green arc on a fixed pitch prop aircraft you should either turn carb heat on for the duration or with Piper aircraft, turn it on an make sure the engine doesn't run rough. If it does, leave it on and let it burn off the ice, then the engine should run more smoothly again. There are many descriptions of how to use Carb heat in the POH's and on the web. Thanks -- I'm sorry that we didn't make our topic clear enough before. What we're discussing is a different use of carb heat, to even out the distribution to the cylinders while running lean of peak in cruise. A lot of regularly-aspirated engines simply won't run smoothly lean-of-peak because of the uneven distribution in the carb; carb heat seems to even it out in some cases. 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] current bugs
Andy Ross writes: There's a tunable TSFC number that you can play with. The engine model isn't smart enough to vary fuel consumption with condition (real engines have variable TSFC's under different situations). But as long as the number used is correct for cruise there shouldn't be too much difference over a long flight. This is probably obvious, but according to my study materials for the instrument rating, the efficiency of a jet engine depends on the temperature differential between its combustion and the outside air temperature -- that's why jets are very efficient flying near the tropopause at around -60 degC, but burn more fuel for less power in warmer temperatures (i.e. lower). Is YASim taking that into account? You could also check the throttle setting in the cruise parameters. I think I have most of them at 100% right now (max speed numbers, as opposed to cruise numbers), lowering that should lower overall drag and improve cruise-regime fuel consumption. As always, the best numbers to use are ones from a POH, if anyone has them. The 747 YASim config file has the throttle at 0.75. 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] [OT] tyre squeak
Erik Hofman writes: I've recently watched one of my favourite films called The Big Blue. I was amazed to find that even in a great film like this they added that fake tyre squeak sound on landing -- of a helicopter! I was at the local airport the other day and noticed *no* tire squeel for F-16's and a 737 and just twice (main gear) for a C-172. I can now confirm, after about 90 flights, that I have never heard a tire squeal on any of the planes I've flown (a Cessna 150, several 172s, a Cardinal, and my Warrior), even in some of the horrific landings during the first few hours of my PPL training. I'd be upset if I did hear one, since it would mean that I'd have to pay for a new tire and tube, and they're not cheap. 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] [OT] tyre squeak
Luke Scharf writes: With all due respect, I've had a few squeakers in the Cessna 172 I rent! On an extremely smooth landing for me (no bump at all), it makes an extremely faint chuff sound rather than a squeak -- even that might be in my imagination. I've never heard a squeak or any other sound when I've been standing outside watching planes land, except for the propeller and engine. 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] [OT] tyre squeak
Luke Scharf writes: I've noticed in my car that the tires squeal much more easily on hot days (=85 degrees F, =29 degrees C ) - so I'd imagine that it's similar for airplanes. On cooler days, my car tires just make a scuffing-sound. Are you up North? Yes, but I flew through last summer, with temperatures frequently in the mid-30's. 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] 2D Panel Instrument Change
I've made a change to the switch layer type that is very useful but also, unfortunately, backwards-incompatible (I've updated all of the instruments currently in the base package). In its old version, the switch layer looked like this: layer typeswitch/type property/foo/bar/property layer ... /layer layer ... /layer /layer If the /foo/bar property had a true boolean value, the first child layer would be used; otherwise, the second would be used. In the new version, the switch layer looks like this: layer typeswitch/type layer condition ... /condition ... /layer !-- repeat as many times as needed -- layer ... /layer /layer The first layer with a true condition gets used, no matter how many layers there are. This approach allows for simpler and more elegant tests in animating 2D instruments. 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] 747-400 cruise information
David Culp writes: I asked a 747-400 pilot what was the fuel flow per engine at cruise. He said about 6000 lb-per-hour. Assuming a TSFC of 0.5 (I've seen 0.318 and 0.348 for the PW4060, but I don't trust these numbers) that would mean each engine is developing 12000 pounds of thrust. Therefore the total drag on the airplane at cruise is 48000 pounds, and total fuel flow is 24000 pph. From looking at the code, I've discovered that YASim assumes a thrust-specific fuel consumption of 0.8 by default, so there's your problem. In fact, the following comment appears in Jet.cpp: // Initialize parameters for an early-ish subsonic turbojet. More // recent turbofans will typically have a lower vMax, epr0, and // tsfc. You can tune these with attributes on the jet element in the YASim config file. For example, in $FG_ROOT/Aircraft-yasim/747.xml, you can change jet x=-10.43 y=16.26 z=-1.20 mass=8000 thrust=63737 control-input axis=/controls/throttle[0] control=THROTTLE/ /jet to jet x=-10.43 y=16.26 z=-1.20 mass=8000 thrust=63737 esfc=0.4 control-input axis=/controls/throttle[0] control=THROTTLE/ /jet and effectively double the 747's range (repeating for all four engines). Here are all of the attributes Andy uses for the jet element, together with defaults where I could figure them out: x y z mass thrust afterburner [0] rotate [0] n1-idle [55] n1-max [102] n2-idle [73] n2-max [103] tsfc [0.8] egt [1050] epr [3.0] exhaust-speed [800] Play with these, and you should get the engine of your dreams. 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] Updates to YASim config doc
I've just updated $FG_ROOT/Aircraft-yasim/README.yasim with many more engine attributes (prop and jet) yanked out of the latest source code. I suggest that people working on YASim planes take a look, and let me know about any errors (I had to guess a bit). 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] ANN: internal GPS support
I've started basic GPS support under in /instrumentation/gps/. Right now, the GPS publishes the following properties: /instrumentation/gps/raim /instrumentation/gps/indicated-latitude-deg /instrumentation/gps/indicated-altitude-ft /instrumentation/gps/indicated-track-true-deg /instrumentation/gps/indicated-track-magnetic-deg /instrumentation/gps/indicated-ground-speed-kt I'm not sure whether the advanced navigation features (waypoints and so on) belong here or in a higher-level module. I'm not simulating errors and loss of satellites yet (position and altitude are always accurate), but the 'raim' property provides a future placeholder for us to do so. To try it out, browse to /instrumentation/gps/ in the property browser and watch the properties update as you fly (it's especially interesting to do so at high altitude and compare the groundspeed to the indicated airspeed). Perhaps, for a start, someone would like to throw together a very simplistic GPS display based on these properties so that we can stick it onto some panels. 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] C310 more stable
Jim Wilson writes: I found the C310 JSBSim model very unstable, so I've increased roll, pitch, and yaw damping -- please try it out and let me know what you think. Ah, much easier to land. I can't vouch for the realism, but it sure is a lot easier to line up and stay there. Before it was just about impossible to hit the center line. I'm not sure I changed the right coefficients, though -- I'm going to look into it more when I get the chance. The real problem might be in the moments of inertia. 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] C310 more stable
Jon Berndt writes: I'm not sure I changed the right coefficients, though -- I'm going to look into it more when I get the chance. The real problem might be in the moments of inertia. Hmm. I'm not so sure. The moments of inertia are cut and pasted from a technical document. That's just what they are. You can't change the mass properties. Full tanks way out on the wingtips of a 310 must create a significant roll moment. JSBSim will generate that moment for us, based on the amount of fuel in the tanks; however, if the published moment *already* assumes full wingtip tanks, then we'll get far too much rolling. We need someone with twin experience to try it out. Anyone with much twin experience is too broke to afford electricity, much less a computer. 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] C310 more stable
Michael Selig writes: Some real numbers on the 310 are in one of Roskam's books, and those same numbers are in the fgfs base package here: ~fgfsbase/Aircraft-uiuc/Cessna310/aircraft.dat Yes, I took my numbers from Roskam as well. Personally, given the ability of fgfs to do a fairly high-fidelity simulation (one of it's strengths), I'd stick w/ the published numbers. That applies only if we're starting from the same assumptions as Roskam. Roskam probably assumed fuel in the tanks when he estimated the moments with his AAA software (remember that his numbers are not from actual flight tests). Normally, that wouldn't matter so much, since fuel tanks tend to be on the inboard portion of the wings, close to the centre axis. The 310, however, is a special case: each wingtip tank holds 50 gallons of fuel, or approximately 300lb; since they're on the wingtips, each tank has an arm of about 88 inches from the centre axis, creating a very significant moment. JSBSim, on the other hand, assumes no fuel in the tanks, and does an additional calculation of the moment for the fuel when the tanks are full. Hence our (possible) problem. Chances are that the 310 has a yaw damper as part of the autopilot system. JSBsim has yaw damper functionality, and the current UIUC code (yet to be given to Curt) has this too. Rather than tweaking the aero and mass data, I suggest adding the yaw damper. The yaw damper would have to be disengaged in turbulence (and many other flight conditions), so we still need a flyable plane without it. Fortunately, yaw instability is the least of the problems -- pitch and roll instability are much more serious. There's also no reason to include yaw dampers in the individual FDMs -- we should be able to handle that in our FlightGear autopilot module. Roskam's pitch numbers are also worth investigating. He gives the 310 a Cmalpha of only -0.137 in cruise, compared to -0.613 for the 182 -1.89 for the Beech 99. That makes his 310 model surprisingly unstable in the pitch axis. On the other hand, in his climb condition (5 degrees alpha), he gives a linear Cmalpha of -0.339, and in his approach condition (6.6 degrees alpha, probably with flaps and gear down), he gives a linear Cmalpha of -0.619. We don't have enough information to factor out the flaps and gear from the last value, but these still suggest a steepening curve rather than a straight line -- i.e. the 310 is relatively unstable only in a small range around 0 alpha. 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] C310 more stable
Jon Berndt writes: I am 90% sure that the Ixx we use for the -310 is empty weight Ixx. That means of course that I am 22% not sure. When I put together the original 310 JSBSim config file (my first one, I think), I simply copied the numbers from Roskam -- they appear to be unchanged since then. 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] C310 more stable
Jim Wilson writes: Then we just need an interface to be able to turn yaw damping on or off? That scares me a bit. Our current FGInterface class for the FDMs is already terrifying. I'm hoping to start trimming it down soon and relying more on properties (as already happens for all new features), but it's a nightmarish proposition -- I think I'd rather spend a few hours in the dentist's chair. I think that FlightGear will work best if we make a clean separation between the physics engine (FDM) and higher-level logic like autopilots and navigational systems. 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] ANN: internal GPS support
Danie Heath writes: My copy of FGFS shows all the information below in the property browser, but only exports the value of 0 ... I then checked any of the other properties, and they export just fine ... I also tried the telnet route, and exactly the same happened ... do you have any ideas how I can fix it ? Which aircraft? Because of the way the electrical system is designed, each one needs to be edited separately to add a GPS power supply -- this is going to get to be a big pain as we get more and more aircraft with customized electrical systems. I made the change for the default 172 electrical system (which many other aircraft use), but it will have to be added manually elsewhere. 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] c310 more stable
paul mccann writes: I have not had a chance to update to the latest cvs version yet, but will tonight and will let you know as soon as I do. One of the manuals I have is dated 1969, and the other does not have a date but list models covered. They look to be from about the same era though. In mine, the photos look early 1960's, but the part number is D731-13-RAND-250-4/71 I'm guessing that the publication date might be April 1971. 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
