[Flightgear-devel] Two different crashes
Hi all, I have encountered two different crashes with latest CVS: http://www.pastebin.org/60526 http://www.pastebin.org/60527 Both happens with or without any parameters and while startup. Regards, Roland signature.asc Description: This is a digitally signed message part -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] releases +- bugs
On 12/01/2009 12:47 PM, Stuart Buchanan wrote: >> 4 :: wrong runway, not in airport database > I suspect that might be an artifact of the apt.dat file being out of > kilter with the scenery you've got. Have you tried TerraSync to see > what the latest scenery looks like. Yes, things look much different now. I got rid of the "old" 1.0.1 scenery, fired up terrasync, restarted fgfs a couple of times so that terrasync would load the "new" scenery and fgfs would find out about it. Thanks for the clue. I never would have guessed that the problem was scenery-related. In fact I still don't understand how using the "old" 1.0.1 scenery could cause an existing runway to vanish and a spurious runway to appear. Are runways part of the scenery? Is the runway information in apt.dat now obsolete, or soon to become obsolete? Is there any chance of making the code more robust, so that it correctly parses apt.dat even when the "new" scenery is in use? Does the "new" scenery have a new version number, or is it still considered 1.0.1? Are there plans for making the "new" scenery available as tarballs, for folks who aren't running (or can't run) terrasync? Maybe this would be a good occasion to implement version numbers in the scenery files, and version checking in the scenery-processing code ... so that if it can't handle the old data, it at least realizes it can't handle it. -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Terragear how to
Hello , Ive decided to try to install terragear again and fix some of the local airports and scenery ... but things aren't all that clear on the wiki ... Do I install Terragear or Terragear-cs ?Is terragear-cs a set of patches for terragear ? I heard it mentioned that there was a simgear-cs , do i need this or the current simgear ? I'm still searching on the subject , but any answers would be appreciated .Thanks -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] ground effect +- h_b-mac-ft +- documentation
On Thu, 2009-12-03 at 19:40 +, Ron Jensen wrote: > Hmm, climb too high and cruise too low... Someone installed a climb > propeller on our aircraft? :D > > For example: > http://forums.cessnaowner.org/read/1/7599 > "I have a 172H and this summer I had the pitch changed from cruise to > climb. I lost approx 2 knots but saw a noticeable increase in takeoff > and climb performance. " > > We're 10% off max cruise, and 25% up on climb performance.. > > Our propeller model really starts to fall off around an advance ratio of > 0.60. Advance ratio is > > Speed / ((propeller revolutions/time)*(propeller diameter)) > > Some advance ratio calculations for our c172: > 107 knot/ ((2500/min)*75 in) ~= .69 > 120 knot/ ((2500/min)*75 in) ~= .78 > 120 knot/ ((2700/min)*75 in) ~= .72 > 60 knot/ ((1000/min)*75 in) ~= .97 40 knot/ ((1000/min)*75 in) ~= .65 And converting our advance ratios (J) into thrust: Thrust = Ct*density*(rpm)^2*(prop diameter)^4 J Ct 0.65 ~= 0.054 0.69 ~= 0.05 0.72 ~= 0.045 0.78 ~= 0.04 0.97 ~= 0.019 Sea Level density ~= 0.00238 slugs/ft3 8000 ft density ~= 0.00187 slugs/ft3 107 Knots, 2500 RPM, 8000 ft: (0.00187 slug/ft3) * ( 2500/min)^2 * (74 in)^4 * 0.05 ~= 235 lbs thrust 120 knots, 2500 RPM, 8000 ft: (0.00187 slug/ft3) * ( 2500/min)^2 * (74 in)^4 * 0.045 ~= 188 lbs thrust 120 knots, 2700 RPM, 8000 ft: (0.00187 slug/ft3) * ( 2500/min)^2 * (74 in)^4 * 0.045 ~= 245 lbs thrust So, as you can see, not allowing the propeller to accelerate as the speed increases actually reduces thrust with the current propeller. Accelerating the propeller to 2700 (red-line for this engine?) yields only a modest thrust increase. At the other data point mentioned: 60 knots, 1000 RPM, sea level: (0.00238 slug/ft3) * ( 1000/min)^2 * (74 in)^4 * 0.019 ~= 20 lbs thrust 40 knots, 1000 RPM, sea level: (0.00238 slug/ft3) * ( 1000/min)^2 * (74 in)^4 * 0.054 ~= 50 lbs thrust As the airspeed drops from 60 knots to 40 knots, the advance ratio moves to a powerful region causing a 150% increase in thrust. It appears we may want a propeller thrust table that is flatter in the 0.6 - 0.8 J range. A corresponding flattening of the power table may slow the engine below 1000 rpm when idling at higher speeds thus causing a more appropriate drop in thrust. Ron -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Model diffuse and ambient colors
I quess that was a pretty lame answer of mine , I assumed you only
needed to fix a single ac file...
Ive modified my local ac3d_export to alway copy the rgb values to amb
, and use mirror color as emissive .
Cheers
On 12/2/09, syd adams wrote:
> or just set the amb color to the same as rgb in the .ac file.
>
> On 12/2/09, Curtis Olson wrote:
>> Thanks Vadym and Erik, hopefully this does the trick.
>>
>> Curt.
>>
>>
>> On Wed, Dec 2, 2009 at 8:46 AM, Vadym Kukhtin wrote:
>>
>>> 2009/12/2 Curtis Olson :
>>>
>>> > non-illuminated sides. Is there a howto posted somewhere that
>>> > explains
>>> how
>>> > to fix this?
>>>
>>> Some time ago I found this in devel-list:
>>>
>>> #! /bin/sh
>>>
>>> for f in "$@" ; do
>>> sed -i.before-color-change
>>>
>>> 's,\(MATERIAL.*\)rgb\(.*\)amb\(.*\)emis\(.*\)spec\(.*\)shi\(.*\)trans\(.*\)$,\1rgb\2amb\2emis\4spec\5shi\6trans\7,1'
>>> "$f"
>>> if ! cmp "${f}" "${f}.before-color-change" > /dev/null 2>&1 ; then
>>> echo "$f has changed colors!"
>>> fi
>>> done
>>>
>>>
>>> --
>>> ---
>>> WBR, Vadym.
>>>
>>>
>>> --
>>> Join us December 9, 2009 for the Red Hat Virtual Experience,
>>> a free event focused on virtualization and cloud computing.
>>> Attend in-depth sessions from your desk. Your couch. Anywhere.
>>> http://p.sf.net/sfu/redhat-sfdev2dev
>>> ___
>>> Flightgear-devel mailing list
>>> Flightgear-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>>>
>>
>>
>>
>> --
>> Curtis Olson: http://baron.flightgear.org/~curt/
>>
>
--
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] releases +- bugs
Hi, > Torsten Dreyer a écrit : > > "No transponder" correct, an IFR certified > aircraft without a > > transponder is unrealistic. It's low priority on > my todo list and I > > consider it a missing feature, not a bug. My > goal is to model a > > GTX330 which is what I have in the RL Seneca. As > a side note: I > > consider a transponder "optional". It's one of > the very few items I > > carry on board just for other peoples (ATC) > purpose - next to sick > > bags ;-) > > The transponder isn't often powered in a school glider (who > cares to > take another battery on board when you just plan to > turn around the > field ?) > > But for sure, the first time a glider student has the > chance to fly (high) > in the ATC wisdom, this thing becomes suddenly important. > And well, > how did you say it works ? > > Alexis > I had to smile a bit, when I read about "no transponder" - even we had this in the FGFS c172p- it would be useless, as this is only a dummy. We don't have any real simulating transponder yet- so our ATC-tool can't see our squawks, altitude etc;-) Our transponder models are just dummies __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] releases +- bugs
Torsten Dreyer a écrit : > "No transponder" correct, an IFR certified aircraft without a > transponder is unrealistic. It's low priority on my todo list and I > consider it a missing feature, not a bug. My goal is to model a > GTX330 which is what I have in the RL Seneca. As a side note: I > consider a transponder "optional". It's one of the very few items I > carry on board just for other peoples (ATC) purpose - next to sick > bags ;-) The transponder isn't often powered in a school glider (who cares to take another battery on board when you just plan to turn around the field ?) But for sure, the first time a glider student has the chance to fly (high) in the ATC wisdom, this thing becomes suddenly important. And well, how did you say it works ? Alexis -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] ground effect +- h_b-mac-ft +- documentation
On Thu, 2009-12-03 at 17:18 +, Stuart Buchanan wrote: > John Denker wrote: > > > On 12/01/2009 12:47 PM, Stuart Buchanan asked: > > > > > You suggest two possible explanations. Not having access to a C-172, > > > nor enough flight time to be able to guess which is correct, I'm not > > > sure there's much I can sensibly do without making it worse. If you > > > can suggest which is wrong, I'll see what I can do. My guess would be > > > idle RPM, given your previous comments that the aircraft if > > > over-powered. > > > > Those are good questions. I don't yet know for sure > > whether there is too much power and/or too little drag. > > I took the opportunity to check the PoH against the simulator experience. > While I didn't go as far as getting the OAT exactly right, the errors I came > across were fairly signficant (using a HUD to get accurate altitude/TAS etc.) > > As I think you've noted before, the climb rate is too high - I consistently > see 1000ft/min up to 8000ft ASL, instead of approx 800ft/min at sea level, > and 400ft/m at 8000ft ASL. > > In contrast, the cruise speed is a bit too low - I don't recall what I saw at > sea-level, but at 8000ft ASL, I saw 107 KTAS rather than 120 KTAS (though as > that was very close to the IAS, it may be that the environment was not quite > right). > > I'm not sure what to make of this. Perhaps the drag and power should be > reduced, or possibly the alpha drag needs to increase? > > I suspect I need to use JSBSim directly to tune these parameters better. > > -Stuart Hmm, climb too high and cruise too low... Someone installed a climb propeller on our aircraft? :D For example: http://forums.cessnaowner.org/read/1/7599 "I have a 172H and this summer I had the pitch changed from cruise to climb. I lost approx 2 knots but saw a noticeable increase in takeoff and climb performance. " We're 10% off max cruise, and 25% up on climb performance.. Our propeller model really starts to fall off around an advance ratio of 0.60. Advance ratio is Speed / ((propeller revolutions/time)*(propeller diameter)) Some advance ratio calculations for our c172: 107 knot/ ((2500/min)*75 in) ~= .69 120 knot/ ((2500/min)*75 in) ~= .78 120 knot/ ((2700/min)*75 in) ~= .72 60 knot/ ((1000/min)*75 in) ~= .97 -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] basic flight dynamics
On 12/03/2009 10:18 AM, Stuart Buchanan wrote:
> I took the opportunity to check the PoH against the simulator
> experience. While I didn't go as far as getting the OAT exactly
> right, the errors I came across were fairly signficant (using a HUD
> to get accurate altitude/TAS etc.)
>
> As I think you've noted before, the climb rate is too high - I
> consistently see 1000ft/min up to 8000ft ASL, instead of approx
> 800ft/min at sea level, and 400ft/m at 8000ft ASL.
>
> In contrast, the cruise speed is a bit too low - I don't recall what
> I saw at sea-level, but at 8000ft ASL, I saw 107 KTAS rather than 120
> KTAS (though as that was very close to the IAS, it may be that the
> environment was not quite right).
I'm really glad you're looking into this. I will happily
help as much as I can, but I've spent about 200 hours in
hospitals in the last three weeks, which cuts into my
flying and virtual flying time
> I'm not sure what to make of this.
Being a test pilot is very demanding work. Nothing easy
about it.
> Perhaps the drag and power should
> be reduced, or possibly the alpha drag needs to increase?
A distinct possibility.
Suggestion: Try plotting the power curve. Start by
measuring the power-off vertical speed as a function
of airspeed.
The top of the curve should correspond to the POH
power-off best-glide speed. If the induced drag
("alpha drag") is off, the curve will be wildly
off. Finding the exact top of the curve is not
easy, but a little curve-fitting helps a lot.
The next step is to measure the power-on power curve.
In the real airplane, this is a pain in the neck
because engine power depends so strongly on altitude.
In the sim the pain is slightly less, because you
can easily record _thrust_ horsepower (thrust times
TAS) as you go along, and take that into account in
the analysis.
I suggest turning on auto-coordination. The yaw
axis behavior in the C172p sim is quite unrealistic,
and we don't want that to pollute the power and drag
measurements. We can deal with the yaw axis some
other time.
> I suspect I need to use JSBSim directly to tune these parameters
> better.
There's nothing easy about that, either.
At one point I started writing a wind tunnel based
on JSBSim, i.e. something that would systematically
map out the aerodynamic coefficients. But I got
a negative amount of cooperation, so I moved on
to other things. If there is sufficient interest
maybe that effort could be revived.
--
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] ground effect +- h_b-mac-ft +- documentation
Hi, > > I took the opportunity to check the PoH against the > simulator experience. While I didn't go as far as getting > the OAT exactly right, the errors I came across were fairly > signficant (using a HUD to get accurate altitude/TAS etc.) > > As I think you've noted before, the climb rate is too high > - I consistently see 1000ft/min up to 8000ft ASL, instead of > approx 800ft/min at sea level, and 400ft/m at 8000ft ASL. > > In contrast, the cruise speed is a bit too low - I don't > recall what I saw at sea-level, but at 8000ft ASL, I saw 107 > KTAS rather than 120 KTAS (though as that was very close to > the IAS, it may be that the environment was not quite > right). > > I'm not sure what to make of this. Perhaps the drag and > power should be reduced, or possibly the alpha drag needs to > increase? > > I suspect I need to use JSBSim directly to tune these > parameters better. > > -Stuart > I wonder if it makes really sense to compare our C172P-model with a real C172N. Both types has different engines and therefore different perfomances. That's why I suggested to have one real aircraft with everything, which our sim-model is modelled after it. The manual should only help to get an idea of some stuff, like panel, handling. But Perfomance is difficult, as it is not the c172P. Kind Regards HHS __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] ground effect +- h_b-mac-ft +- documentation
John Denker wrote: > On 12/01/2009 12:47 PM, Stuart Buchanan asked: > > > You suggest two possible explanations. Not having access to a C-172, > > nor enough flight time to be able to guess which is correct, I'm not > > sure there's much I can sensibly do without making it worse. If you > > can suggest which is wrong, I'll see what I can do. My guess would be > > idle RPM, given your previous comments that the aircraft if > > over-powered. > > Those are good questions. I don't yet know for sure > whether there is too much power and/or too little drag. I took the opportunity to check the PoH against the simulator experience. While I didn't go as far as getting the OAT exactly right, the errors I came across were fairly signficant (using a HUD to get accurate altitude/TAS etc.) As I think you've noted before, the climb rate is too high - I consistently see 1000ft/min up to 8000ft ASL, instead of approx 800ft/min at sea level, and 400ft/m at 8000ft ASL. In contrast, the cruise speed is a bit too low - I don't recall what I saw at sea-level, but at 8000ft ASL, I saw 107 KTAS rather than 120 KTAS (though as that was very close to the IAS, it may be that the environment was not quite right). I'm not sure what to make of this. Perhaps the drag and power should be reduced, or possibly the alpha drag needs to increase? I suspect I need to use JSBSim directly to tune these parameters better. -Stuart -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] ground effect +- h_b-mac-ft +- documentation
On 12/01/2009 12:47 PM, Stuart Buchanan asked: > You suggest two possible explanations. Not having access to a C-172, > nor enough flight time to be able to guess which is correct, I'm not > sure there's much I can sensibly do without making it worse. If you > can suggest which is wrong, I'll see what I can do. My guess would be > idle RPM, given your previous comments that the aircraft if > over-powered. Those are good questions. I don't yet know for sure whether there is too much power and/or too little drag. However, while trying to answer those questions, I came across another snafu that calls for some attention. The topic for today is the h_b-mac-ft variable that is used by JSBSim as part of the interface between the C code and the xml configuration files for a given aircraft. There are at least four things we know about this variable: 1) How it is calculated, upstream of the interface 2) How it is used, downstream of the interface 3) Some meaning we can try to read into the name of the variable; and 4) The explicit documentation found at http://www.mail-archive.com/flightgear-us...@lists.sourceforge.net/msg02747.html When we look into it we find: 1) My reading of the code that produces h_b-mac-ft suggests it is the height of AERORP (the aerodynamic reference point) above the ground ... divided by wingspan. 2) The variable is used in the xml configuration files to calculate ground effect. This is entirely consistent with (1). This is not causing the problem with the C172p. So far so good. 3) As previous explained in detail, I find it is rarely a good practice to read meaning into names. Charpentier was a composer, not a carpenter. Boulanger was another composer, not a baker. 4) In the only documentation I could find, namely http://www.mail-archive.com/flightgear-us...@lists.sourceforge.net/msg02747.html it claimes h_b-mac-ft is the "Altitude of MAC divided by wing span" which doesn't make any sense. MAC is the conventional abbreviation for Mean Aerodynamic Chord. Talking about MAC in this context is like talking about the diameter of my arm when you want to know the height AGL of my collarbone. == Suggestions: A) Having documentation in an archive such as http://www.mail-archive.com/flightgear-us...@lists.sourceforge.net/msg02747.html is wy better than nothing, but it would be even better if documentation were incorporated in the code base, so that *) people could find it more easily, and *) people could submit patches against it B) In general: documenting the interfaces is important. No matter how well documented (or poorly documented) the internal workings of the code may be, there needs to be good documentation for the interface. C) In this particular case, it would be nice to document h_b-mac-ft conspicuously, and sooner rather than later, given that there are misconceptions floating around. -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
