Re: [Flightgear-devel] FGPiston patch RFC
On Fri, 2008-12-19 at 23:28 -0700, John Denker wrote: > An alternative approach is diagrammed at > http://www.av8n.com/fly/throttle.htm#fig-x1xt > > This is more plausible in terms of the physics of the situation, and > more consistent with everyday Real World pilot experience. Here is a dynamometer test report of an engine intended for use in an aircraft: http://members.cox.net/alg3/Dynamometer%20test%20report.htm Please note especially the RPM v. Manifold Pressure chart at the end: http://members.cox.net/alg3/Dynamometer%20test%20report_files/image005.jpg The shape of this curve is the reverse of the curves you've postulated in your figure 3. It also remains above 28 inHg to nearly 5000 RPM. Your proposed model appears unable to duplicate this feat, as your full throttle line is below 0.94 (28 inHg / 29.92 inHg) MAP by 0.07 RPM. While we're at it, please consider this dyno picture http://aagearinc.com/supercharged_na.gif Yes, its a motorcycle engine not an aircraft engine, but both function according to the same principles and studying one will lead to understanding of both. The red line is a normally aspirated engine. You can clearly see the power peak and fall off. The blue line is the same engine with boost. It produces linear power to the top of the RPM run because it can breathe. Thanks, Ron -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New Engine for the C182
On 12/20/2008 08:52 PM, Ron Jensen wrote: > Yes, 2400 is full fine. I asked about full coarse. I was under the > impression, perhaps mistaken, that you expected the engine to turn > faster than 1750 rpm with the lever back (coarse): OK, sorry, most recently I misread course/fine. My bad. However, previously I did answer (as best I could) the question about full coarse. On 12/20/2008 03:11 PM, I wrote: >> I reckon full back might set the governor for somewhere >> near 900 but I'm not sure. I recall it is impressively low, but >> I don't recall the exact number. I will add that it is for sure below 1750 RPM. Far, far below. The preflight runup in the Real World Cessna 182 is performed at 1700 RPM, and "exercising" the prop requires bringing the governor below 1700, and that requires far less than full-back on the control. > "Consider the following scenario: The Sim World c182rg is sitting on > the runway at KSFO. The propeller control is pulled back, so that the > engine is operating at relatively low revs, about 1750 RPM in > contrast to redline which is 2400 RPM. The pilot can observe that if > the throttle is open anywhere between 52% and 100% open, moving the > throttle has no effect on the MAP." I will also add that the precise value of the revs in this scenario (1750 RPM) is of no importance to the point I wanted to make. My point remains that in the Sim World c182, you can under some conditions bring the throttle back nearly half way with *zero* effect on the MAP. The MAP remains equal to the ambient static pressure. The idea of significant flow with *zero* pressure drop across a half-closed valve is in flagrant violation of the laws of physics. I emphasize that for today at least, I am not talking about the code and not talking about the configuration data. I am talking about the behavior : the directly observable in-the-cockpit behavior of the Sim World model. The MAP-vs-throttle behavior and the power-vs-throttle behavior are flagrantly unrealistic. Yeah, the minimum revs on the SW governor is also unrealistic. That wasn't the point I wanted to emphasize, but you can add it to the list of bugs if you want. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New Engine for the C182
On Sat, 2008-12-20 at 18:30 -0700, John Denker wrote: > On 12/20/2008 04:37 PM, Ron Jensen wrote: > > >> You don't need to tell me the propeller and engine interact. > >> I'm pretty sure I knew that already. That's exactly why > >> they should be tested separately. > > > > And yet, you are testing them together and posting your results. > > I report my results in the form of shaft power, torque, RPM, > and MAP. And each time I explain that -- in that form -- > they are independent of the properties of the propeller. > > > You've never told me what RPM you expect the engine to achieve with the > > prop set full coarse? > > Except that I did. Unless my inbox and outbox are lying > to me, on 12/20/2008 03:11 PM, I wrote in part: > > > Full forward on the prop control sets the governor for > > 2400. > > Not coincidentally, 2400 is redline and top-of-the green > on the tachometer in the real aircraft, and not coincidentally > also in the current FGFS c182 and c182rg, because that's > where I put them when I did the artwork. Yes, 2400 is full fine. I asked about full coarse. I was under the impression, perhaps mistaken, that you expected the engine to turn faster than 1750 rpm with the lever back (coarse): "Consider the following scenario: The Sim World c182rg is sitting on the runway at KSFO. The propeller control is pulled back, so that the engine is operating at relatively low revs, about 1750 RPM in contrast to redline which is 2400 RPM. The pilot can observe that if the throttle is open anywhere between 52% and 100% open, moving the throttle has no effect on the MAP." -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New Engine for the C182
On 12/20/2008 04:37 PM, Ron Jensen wrote: >> You don't need to tell me the propeller and engine interact. >> I'm pretty sure I knew that already. That's exactly why >> they should be tested separately. > > And yet, you are testing them together and posting your results. I report my results in the form of shaft power, torque, RPM, and MAP. And each time I explain that -- in that form -- they are independent of the properties of the propeller. > You've never told me what RPM you expect the engine to achieve with the > prop set full coarse? Except that I did. Unless my inbox and outbox are lying to me, on 12/20/2008 03:11 PM, I wrote in part: > Full forward on the prop control sets the governor for > 2400. Not coincidentally, 2400 is redline and top-of-the green on the tachometer in the real aircraft, and not coincidentally also in the current FGFS c182 and c182rg, because that's where I put them when I did the artwork. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New Engine for the C182
On Sat, 2008-12-20 at 15:11 -0700, John Denker wrote: > On 12/20/2008 10:24 AM, Ron Jensen wrote: > > > Lets look instead at finding out the real reasons why the output > > behavior is not as it should be. > > > > First question, prop_81in2v.xml gives a minimum and maximum propeller > > pitch of 12.0 and 31.8. Any idea if these numbers are right or are they > > just guesses? > > > > Second question, prop_81in2v.xml gives a minimum and maximum rpm of 900 > > and 2400 rpm.Any idea if these numbers are right or are they just > > guesses? > > > Hmmm ... prop_81in2v.xml is not a Hartzell part number or > even close, so I have no idea what RW propeller that file > is supposed to represent. Similarly, there is no documentation > in the file to tell me. It looks like the c_power and c_thrust tables were taken from propC10v.xml which are taken from data in NACA Report 378. > I have here a RW 1979 Cessna R182 manual that says the propeller > has a low pitch of 15.8 and a high pitch of 29.4. Mr. Cessna is > kind enough to specify that this is measured at the 30" station > (otherwise the numbers would be meaningless). The Type Certificate Data Sheet for the 182S/T which are the only 182s listed for the IO-540-AB1A5 give 17 / 31.8 at the 30" station. That matches what was once in prop_81in2v.xml, I'm pretty sure the 12 is a typo. > The RPM numbers quoted above are probably about right as to the > governor. Full forward on the prop control sets the governor for > 2400. I reckon full back might set the governor for somewhere > near 900 but I'm not sure. I recall it is impressively low, but > I don't recall the exact number. I usually only see this number > during emergency glide conditions, and then I usually have other > things to look at. Of course the governor numbers are not > hard limits; at any prop setting if you pull the throttle back > far enough the propeller will drop out of regulation. That's > because the aforementioned pitch limits *are* hard limits; the > mechanism literally hits the stops. The FGFS model seems to > capture this out-of-regulation behavior OK. > > There is also transient behavior; it is easy to overspeed or > underspeed the prop temporarily. > > > > Now let me explain why that's not the right starting point. > Two reasons: physics and engineering. > > You don't need to tell me the propeller and engine interact. > I'm pretty sure I knew that already. That's exactly why > they should be tested separately. And yet, you are testing them together and posting your results. > Think about software engineering: We write modules and test > them individually. Yeah, they interact, which is why we > start by testing them separately, so if there is any funny > business we know where to look. We always *end* by testing > everything together, but that's not where we start. > > The same engineering principle applies to hardware. That's > why dynamometers and prony brakes were invented. I guarantee > you Lycoming tests the engines on a test stand before they > go anywhere near a propeller; I've seen the data. (I don't > have a copy; sorry.) Indeed. I use and abuse a test propeller configuration for engine test. > As to the physics: In the steady state, if we know the torque > and the revs, we don't need to know *anything* about the > propeller to ascertain engine performance. It doesn't matter > whether the engine is connected to a dynamometer or to a > propeller or to bunch of pom-poms on a broomstick. You can > formalize this in terms of Sturm-Liouville theory if you want. > The fundamental equations of physics are low-order differential > equations, and they need only a small number of initial > conditions and/or boundary conditions. > > Since it has been "stipulated" that there is misbehavior in > the engine, basic engineering principles suggest debugging > the engine before allowing it to interact with other > subsystems. > > Otherwise there is jeopardy of ending up with two bugs: > in particular, unrealistic prop behavior that compensates > and masks some part of the unrealistic engine behavior. Looking at engIO540AB1A5 I note its configured for 230 horsepower @ 2575 RPM, that makes it underpowered by about 5% as the correct numbers are 230 horsepower @ 2400 rpm. I modified the attached configuration with 250 hp @ 2575. That allows us 230 @ 2400 plus a bit more power when it exceeds redline. You've never told me what RPM you expect the engine to achieve with the prop set full coarse? Thanks, Ron engIO540AB1A5.xml Description: XML document -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear-1.99.5-RC2
I was reminded [off list] that as of 2008, you can get by without ADF in the US but not necessarily elsewhere. Therefore I retract my half-suggestion that the ADF could be removed entirely. Item 22 now reads: 22:: c172p: No GPS? Is it realistic to fly without a GPS these days? Suggestion: Relocate the DME and the ADF tuner. Put them way over on the starboard side. This makes room in the center stack for a transponder and GPS. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGPiston patch RFC
On 12/20/2008 10:24 AM, Ron Jensen wrote: > Lets look instead at finding out the real reasons why the output > behavior is not as it should be. > > First question, prop_81in2v.xml gives a minimum and maximum propeller > pitch of 12.0 and 31.8. Any idea if these numbers are right or are they > just guesses? > > Second question, prop_81in2v.xml gives a minimum and maximum rpm of 900 > and 2400 rpm.Any idea if these numbers are right or are they just > guesses? Hmmm ... prop_81in2v.xml is not a Hartzell part number or even close, so I have no idea what RW propeller that file is supposed to represent. Similarly, there is no documentation in the file to tell me. The "locate" command suggests that this file is associated mainly with the SW c182 and c182rg. I have here a RW 1979 Cessna R182 manual that says the propeller has a low pitch of 15.8 and a high pitch of 29.4. Mr. Cessna is kind enough to specify that this is measured at the 30" station (otherwise the numbers would be meaningless). The RPM numbers quoted above are probably about right as to the governor. Full forward on the prop control sets the governor for 2400. I reckon full back might set the governor for somewhere near 900 but I'm not sure. I recall it is impressively low, but I don't recall the exact number. I usually only see this number during emergency glide conditions, and then I usually have other things to look at. Of course the governor numbers are not hard limits; at any prop setting if you pull the throttle back far enough the propeller will drop out of regulation. That's because the aforementioned pitch limits *are* hard limits; the mechanism literally hits the stops. The FGFS model seems to capture this out-of-regulation behavior OK. There is also transient behavior; it is easy to overspeed or underspeed the prop temporarily. Now let me explain why that's not the right starting point. Two reasons: physics and engineering. You don't need to tell me the propeller and engine interact. I'm pretty sure I knew that already. That's exactly why they should be tested separately. Think about software engineering: We write modules and test them individually. Yeah, they interact, which is why we start by testing them separately, so if there is any funny business we know where to look. We always *end* by testing everything together, but that's not where we start. The same engineering principle applies to hardware. That's why dynamometers and prony brakes were invented. I guarantee you Lycoming tests the engines on a test stand before they go anywhere near a propeller; I've seen the data. (I don't have a copy; sorry.) As to the physics: In the steady state, if we know the torque and the revs, we don't need to know *anything* about the propeller to ascertain engine performance. It doesn't matter whether the engine is connected to a dynamometer or to a propeller or to bunch of pom-poms on a broomstick. You can formalize this in terms of Sturm-Liouville theory if you want. The fundamental equations of physics are low-order differential equations, and they need only a small number of initial conditions and/or boundary conditions. Since it has been "stipulated" that there is misbehavior in the engine, basic engineering principles suggest debugging the engine before allowing it to interact with other subsystems. Otherwise there is jeopardy of ending up with two bugs: in particular, unrealistic prop behavior that compensates and masks some part of the unrealistic engine behavior. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear-1.99.5-RC2
Ron Jensen wrote: > On Sat, 2008-12-20 at 13:09 -0600, Curtis Olson wrote: > >> On Sat, Dec 20, 2008 at 12:58 PM, Jon Stockill wrote: >> Curtis Olson wrote: >> > There's no reason the chooser can't be made to run on any of >> our >> > supported platforms. It's written in fltk I believe and >> I've had it >> > running in Linux in the past. The only reason it might seem >> like it's a >> > win32 only app is that Frederic is really the only one who >> has taken the >> > time to bundle it with his binary build. >> >> >> Not quite true - it's been included in the Slackware Linux >> packages too. >> >> Excellent ... real proof it's not just a win32 application. :-) >> > > I also (ab)use it as a flightgear model viewer to quickly check submodel > placement... On debian where it builds just fine. > > Ron > > > > -- > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > > I didn't mean it was a windows only option ... Ive used it with Linux (also as a model viewer) , but I prefer the command line and an .fgfsrc file :) Cheers -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear-1.99.5-RC2
On Sat, 2008-12-20 at 13:09 -0600, Curtis Olson wrote: > On Sat, Dec 20, 2008 at 12:58 PM, Jon Stockill wrote: > Curtis Olson wrote: > > There's no reason the chooser can't be made to run on any of > our > > supported platforms. It's written in fltk I believe and > I've had it > > running in Linux in the past. The only reason it might seem > like it's a > > win32 only app is that Frederic is really the only one who > has taken the > > time to bundle it with his binary build. > > > Not quite true - it's been included in the Slackware Linux > packages too. > > Excellent ... real proof it's not just a win32 application. :-) I also (ab)use it as a flightgear model viewer to quickly check submodel placement... On debian where it builds just fine. Ron -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Doppler
Hi, Melchior FRANZ schrieb am 20.12.2008 20:01: > Yes, USE_SOFTWARE_DOPPLER works with openal-soft. Is there any chance to get to know at compile time, that openal-soft is used? If not: is there any chance to get to know at runtime, that openal-soft is used? if yes: we need to change the concept of choosing the Doppler algorithm at compile time to do so at runtime. Maik -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Doppler
* Melchior FRANZ -- Saturday 20 December 2008:
> Unfortunately, the sound isn't muted when pausing ...
Pfff ...
| /*
| alcSuspendContext
|
| Not functional
| */
| ALCAPI ALCvoid ALCAPIENTRY alcSuspendContext(ALCcontext *pContext)
| {
| // Not a lot happens here !
| (void)pContext;
| }
No, not a lot, indeed.
m.
--
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear-1.99.5-RC2
On Sat, Dec 20, 2008 at 12:58 PM, Jon Stockill wrote: > Curtis Olson wrote: > > There's no reason the chooser can't be made to run on any of our > > supported platforms. It's written in fltk I believe and I've had it > > running in Linux in the past. The only reason it might seem like it's a > > win32 only app is that Frederic is really the only one who has taken the > > time to bundle it with his binary build. > > Not quite true - it's been included in the Slackware Linux packages too. > Excellent ... real proof it's not just a win32 application. :-) Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Doppler
* Maik Justus -- Saturday 20 December 2008: > Melchior FRANZ schrieb am 20.12.2008 18:29: > > I re-tried with USE_SOFTWARE_DOPPLER, and that only worked > > for a very short time (less a minute), and then there was > > no sound at all. > Strange, in this mode I only modify the pitch value in the same range > any sound.xml file can do even without Doppler. Good point. Turns out I had just used the wrong aircraft for this test. Apparently the f-14b has another funny feature that I hadn't encountered before. :-} Yes, USE_SOFTWARE_DOPPLER works with openal-soft. Unfortunately, the sound isn't muted when pausing ... m. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear-1.99.5-RC2
Curtis Olson wrote: > There's no reason the chooser can't be made to run on any of our > supported platforms. It's written in fltk I believe and I've had it > running in Linux in the past. The only reason it might seem like it's a > win32 only app is that Frederic is really the only one who has taken the > time to bundle it with his binary build. Not quite true - it's been included in the Slackware Linux packages too. Jon -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear-1.99.5-RC2
There's no reason the chooser can't be made to run on any of our supported platforms. It's written in fltk I believe and I've had it running in Linux in the past. The only reason it might seem like it's a win32 only app is that Frederic is really the only one who has taken the time to bundle it with his binary build. Regards, On Sat, Dec 20, 2008 at 9:53 AM, Syd wrote: > > > Well, and what about using a graphical aircraft chooser. I know a good > > one ;-) > > > > -Fred > > > > PS: fgrun if you didn't get it. > > > > > Its great for Windows users , but I dont use such things :) > > > -- > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > -- Curtis Olson: http://baron.flightgear.org/~curt/ -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] default trim at startup
Typically, the bendable trim tabs on aileron and rudder are used in real life to get near hands off performance at typical cruise with the ball centered. So a modeller will use the property browser and adjust the values to achieve this so the ball is centred with wings level and no aileron input and then put those values in the set.xml file. I just noticed that when I start with fgrun, all the trim values are set to 0.0 but when I start from the command line, the values in the set.xml are used to initialize the trims. The problem with starting with all trims 0.0 is that there is then no way in an aircraft that only has elevator trim adjust (and even rudder trim adjust) to get non slip/skid cruise with no aileron input. I cannot find what to edit to get rid of the trims being initialized to all being 0.0 when using fgrun. What am I missing? Dave P. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Doppler
Melchior FRANZ schrieb am 20.12.2008 18:29: * Maik Justus -- Saturday 20 December 2008: And the manual calculation works quite fine. And if it works with openal-soft we should use it with openal-soft. Ah, ok. I re-tried with USE_SOFTWARE_DOPPLER, and that only worked for a very short time (less a minute), and then there was no sound at all. m. Strange, in this mode I only modify the pitch value in the same range any sound.xml file can do even without Doppler. Maik -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Doppler
* Maik Justus -- Saturday 20 December 2008: > And the manual calculation works quite fine. And if it works with > openal-soft we should use it with openal-soft. Ah, ok. I re-tried with USE_SOFTWARE_DOPPLER, and that only worked for a very short time (less a minute), and then there was no sound at all. m. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Doppler
Hi Melchior, Melchior FRANZ schrieb am 20.12.2008 17:54: * Maik Justus -- Saturday 20 December 2008: Did you try to #define USE_SOFTWARE_DOPPLER instead? No, AFAICS that enables your "manual" Doppler calculations, which you added for openal implementations with broken Doppler (or with correct Doppler that doesn't work with our broken setup ;-). Yes, that is the actual state under windows. And the manual calculation works quite fine. And if it works with openal-soft we should use it with openal-soft. I only wanted to know if openal-soft's Doppler works with fgfs, and apparently it doesn't. (Though, as you know, the openal-soft maintainer claims that his version is correct and that some of the others are buggy. So our code might be tuned for broken openals and, thus, not support openal-soft.) Yes I know. Unfortunately I do not have a openal implementation with working Doppler here; therefore I can not investigate, what need to be changed, to get it working with openal-soft. I had a quick look over the code and couldn't find any suspicious line. m. Maik -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGPiston patch RFC
On Sat, 2008-12-20 at 04:46 -0700, John Denker wrote: > On 12/20/2008 02:44 AM, Ron Jensen wrote: > > John, > > > > You've just convinced me you don't have a clue what is happening inside > > this code. > > You keep saying that. Even if it were true (which I > doubt), it wouldn't be important. > > I call attention again to the scenario I posted: > > >> The Sim World c182rg is sitting on > >> the runway at KSFO. The propeller control is pulled back, so that the > >> engine is operating at relatively low revs, about 1750 RPM in > >> contrast to redline which is 2400 RPM. The pilot can observe that if > >> the throttle is open anywhere between 52% and 100% open, moving the > >> throttle has no effect on the MAP. Similarly, it has no effect on the > >> shaft power of the engine, as you can confirm by looking at the > >> property tree. This insensitivity to throttle setting is dramatically > >> unlike what is seen in a Real World Cessna 182RG. > > If you would kindly take a couple of minutes, you could > verify that what I say about the SW c172rg is true. If > you had the slightest experience in real aircraft, or if > you thought about the physics for a moment, you would > know that what I say about the RW C172RG is true. John, I did look at the SW c182rg, and it behaves as you describe. And I will stipulate that behavior is not correct compared to a real-world c182rg. > Think about it: If the first half of the throttle motion > has *no* effect on the MAP, what reason is there to think > that the second half of the motion will have any effect? > It's just a mechanical valve. It's not psychic. The throttle is a valve. In the instant case, when it opens past about 60% it is flowing 100% of the engine demand. Or more specifically the function doMAP() converts ambient pressure, throttle position, and RPM into a manifold pressure between the ambient pressure and some smaller value, generally around 6 inHg. It does that as coded, yes we could change the algorithm, but that would not and should not change the behavior we are seeing. > You keep saying that the code is working as designed. So > what? That just means that the design is unrealistic. No, it means the c182rg propeller configuration and/or the engine configuration need to be adjusted. The engine model is putting out ~175 hp at 1750 RPM. According to the propeller configuration data this just enough power to turn the prop, with no torque left over to accelerate it faster. So, do we need more horsepower from the engine or less power absorption from the propeller? > The performance of the model is unrealistic. I said that > before looking at the code. Obviously you didn't look at the code. > > It is definitely not because code section you seem to > > love going on about. > > It was unrealistic before I looked at the code, and it is > still unrealistic. > > Do you really expect anybody to believe that things are OK > when pulling the throttle halfway back has absolutely no > effect on the MAP? Yes. > Explaining (again) how the code makes this happen this will > not help. The fact remains that it should not happen. The > RW aircraft does not do this, and the SW aircraft should not > do it either. Neither will blindly blaming sections of code from FGPiston.cpp and drawing pictures of idealized pressure curves. Lets look instead at finding out the real reasons why the output behavior is not as it should be. First question, prop_81in2v.xml gives a minimum and maximum propeller pitch of 12.0 and 31.8. Any idea if these numbers are right or are they just guesses? Second question, prop_81in2v.xml gives a minimum and maximum rpm of 900 and 2400 rpm.Any idea if these numbers are right or are they just guesses? Thanks, Ron -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Doppler
* Maik Justus -- Saturday 20 December 2008: > Did you try to > > #define USE_SOFTWARE_DOPPLER > > instead? No, AFAICS that enables your "manual" Doppler calculations, which you added for openal implementations with broken Doppler (or with correct Doppler that doesn't work with our broken setup ;-). I only wanted to know if openal-soft's Doppler works with fgfs, and apparently it doesn't. (Though, as you know, the openal-soft maintainer claims that his version is correct and that some of the others are buggy. So our code might be tuned for broken openals and, thus, not support openal-soft.) m. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Doppler
Hi Melchior, Melchior FRANZ schrieb am 20.12.2008 15:56: * Melchior FRANZ -- Saturday 20 December 2008: I just defined USE_OPEN_AL_DOPPLER after that #if* group, but Doppler didn't work. PS: not just after the group, but instead of it, so the other optional symbols weren't defined. m. Did you try to #define USE_SOFTWARE_DOPPLER instead? Maik -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear-1.99.5-RC2
> Well, and what about using a graphical aircraft chooser. I know a good > one ;-) > > -Fred > > PS: fgrun if you didn't get it. > > Its great for Windows users , but I dont use such things :) -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Doppler
* Melchior FRANZ -- Saturday 20 December 2008: > I just defined USE_OPEN_AL_DOPPLER after that #if* group, but > Doppler didn't work. PS: not just after the group, but instead of it, so the other optional symbols weren't defined. m. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Doppler
* Maik Justus -- Saturday 20 December 2008: > #ifndef HAVE_WINDOWS_H > #ifdef AL_VERSION_1_2 > #define USE_OPEN_AL_DOPPLER should work My openal-soft (svn/head) defines AL_VERSION_1_1 (and _1_0), but not _1_2. I just defined USE_OPEN_AL_DOPPLER after that #if* group, but Doppler didn't work. m. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Doppler
Hi James, James Sleeman schrieb am 20.12.2008 13:21: Csaba Halász wrote: http://kcat.strangesoft.net/openal.html Some distributions (notably debian) have switched to this version from the "original" implementation. Ahh I see, using Ubuntu here and yes it appears to be this soft version. I think the Doppler effect even should work with openal-soft. Can you check, what is defined after #ifndef HAVE_WINDOWS_H #ifdef AL_VERSION_1_2 #define USE_OPEN_AL_DOPPLER should work #else #define USE_OPEN_AL_DOPPLER_WITH_FIXED_LISTENER better than nothing #endif #else // the Open_AL Doppler calculation seems to be buggy on windows #define USE_SOFTWARE_DOPPLER seem to be necessary #endif (file simgear/sound/sample_openal.hxx lines 65ff) and evaluate if Doppler works for you if you define one of the other two USE_ macros (and undefine the defined one). Best regards, Maik -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Ideas to stabilize c172p performance
I found some of my notes regarding the changes I made to the c172p.xml and c172p-set.xml files back in 2007. The changes that seemed to work the best for me are in the -set.xml file: 1) Change the value from the default 0.027 to a value between 0.030 and 0.032. 2) Change the value from the default 0.00 to a value between 0.05 and 0.10. I am still experimenting with changes to various values in the c172p.xml files, as there are ample opportunities to further refine the flight characteristics in several areas there. But maybe John and Ron would be willing to test these rudder/aileron trim numbers a bit and give me some feedback? Not surprisingly, I found that the rudder trim value has the greatest impact on the effect of P-factor. And indeed, on the real aircraft there is a ground-adjustable trim tab on the back of the 172's rudder--and this is always bent slightly in order to offset the need for right rudder in the climb. So setting a positive value for rudder trim seems to emulate this effect, and results in a less impressive left-turning tendency in the FG C172P. As for the aileron trim, I found that a very small change seems to also help the situation. My current settings are 0.05 for the rudder trim, and 0.030 for the aileron trim--but I am not sure these are the best values, and thus would like some input from other 172 pilots out there. It make take retesting with a proper set of 3-axis flight controls to make this determination; as it stands now, these have been tested using an inexpensive joystick with auto-coordination turned 'on' to control the degree of rudder input needed from the pilot. If it's not too much to ask, I would also like someone to change the name of the engine file to "eng_o320.xml." It seems like a small (nit-picky) issue I realize, but the 172 never came equipped with an Injected, Opposed (IO-320) engine. There were a couple of later models with the Lycoming IO-360 engine, but the 172P had the non-injected opposed (O-320) Lycoming engine. Again, it's a small point, but it helps resolve confusion for those new to FG and trying to sort out the way things work. And it only takes about 30 seconds to fix. I am significantly impressed with the level of understanding shown by people like Ron Jensen and John Denker, regarding the piston-engine issues we are experiencing in the 172 model. I think that these guys are really getting close to further improving the fidelity of the model, and this will only make a great emulation that much better. Thanks in advance. TB -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Translations
Hi! Does this translated strings is using anyware? I did not find references in source code for this strings. I was trying to change the file strings-default.xml , but did not see any differences in GUI. With respect, Alex _ Show them the way! Add maps and directions to your party invites. http://www.microsoft.com/windows/windowslive/events.aspx-- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Doppler
Csaba Halász wrote: > http://kcat.strangesoft.net/openal.html Some distributions (notably > debian) have switched to this version from the "original" > implementation. > Ahh I see, using Ubuntu here and yes it appears to be this soft version. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGPiston patch RFC
On 12/20/2008 02:44 AM, Ron Jensen wrote: > John, > > You've just convinced me you don't have a clue what is happening inside > this code. You keep saying that. Even if it were true (which I doubt), it wouldn't be important. I call attention again to the scenario I posted: >> The Sim World c182rg is sitting on >> the runway at KSFO. The propeller control is pulled back, so that the >> engine is operating at relatively low revs, about 1750 RPM in >> contrast to redline which is 2400 RPM. The pilot can observe that if >> the throttle is open anywhere between 52% and 100% open, moving the >> throttle has no effect on the MAP. Similarly, it has no effect on the >> shaft power of the engine, as you can confirm by looking at the >> property tree. This insensitivity to throttle setting is dramatically >> unlike what is seen in a Real World Cessna 182RG. If you would kindly take a couple of minutes, you could verify that what I say about the SW c172rg is true. If you had the slightest experience in real aircraft, or if you thought about the physics for a moment, you would know that what I say about the RW C172RG is true. Think about it: If the first half of the throttle motion has *no* effect on the MAP, what reason is there to think that the second half of the motion will have any effect? It's just a mechanical valve. It's not psychic. You keep saying that the code is working as designed. So what? That just means that the design is unrealistic. The performance of the model is unrealistic. I said that before looking at the code. > It is definitely not because code section you seem to > love going on about. It was unrealistic before I looked at the code, and it is still unrealistic. Do you really expect anybody to believe that things are OK when pulling the throttle halfway back has absolutely no effect on the MAP? Explaining (again) how the code makes this happen this will not help. The fact remains that it should not happen. The RW aircraft does not do this, and the SW aircraft should not do it either. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 777 vs 787
* Durk Talsma -- Saturday 20 December 2008: > Having said that, I did decide not to swap the 777 for the 787. I get three nasal errors for the 787 and no turbine sound. Nasal runtime error: nil used in numeric context at $FG_ROOT/Aircraft/787/Nasal/system.nas, line 194 Nasal runtime error: setprop() value is not string or number at $FG_ROOT/Aircraft/787/Nasal/flightdirector.nas, line 897 called from: $FG_ROOT/Aircraft/787/Nasal/flightdirector.nas, line 1181 Nasal runtime error: nil used in numeric context at $FG_ROOT/Aircraft/787/Nasal/system.nas, line 412 called from: $FG_ROOT/Nasal/globals.nas, line 96 Others don't seem to get them, so they are likely startup order bugs. m. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear-1.99.5-RC2
* Frederic Bouvier -- Saturday 20 December 2008: > Well, and what about using a graphical aircraft chooser. > I know a good one ;-) ... or a shell completion script if you want it "pure" (-> ./scripts/completion/). Adding code for guessing what a user's bad input could have meant is a rather bad idea. You'd need ways to resolve ambiguities and there's no guarantee that the guess is actually correct. I prefer a good old error message in such cases. m. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 777 vs 787
Hi Gijs, On Friday 19 December 2008 16:52:34 Gijs de Rooy wrote: > Hm, there should be nothing missing. I only included the moved textures, an > enhanced systems.nas file, 787-8.ac, enhanced 787.xml and the Liveries/... > files. Though you have updated more files in CVS... like the instruments > .ac files. Why? > Actually, please disregard. I turned out that I had some local garbage in my Aircraft directory that was causing trouble. It should work now. Having said that, I did decide not to swap the 777 for the 787. Even though, I did get the engines to start on my laptop, I couldn't get the panel buttons to respond on my desktop, which uses a customized camera setup. This, combined with limited test reports, and Syd's advice, made decide to judge a little on the conservative side. Cheers, Durk -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear-1.99.5-RC2
John Denker a écrit : > On 12/20/2008 01:59 AM, Erik Hofman wrote: > >> Syd wrote: >> >>> John Denker wrote: >>> 46:: Capitalization: Example: As of rc2, on the command line, when specifying --aircraft=dhc2W, the "dhc" must not be capitalized, while the "W" must be capitalized. This does not seem user-friendly. From the user's point of view, this does not make any sense. >>> I'm open to suggestions would a dhc2-wheels , dhc2-floats make more >>> sense ? >>> >> I think John is thinking of using non cases-sensitive aircraft names. >> > > I was ... but Syd raises a couple of other good points: > > It wouldn't hurt to make the --aircraft=... option > a) insensitive to hyphenation, and > b) accepting of unique abbreviations > as well as > c) insensitive to case. > > Example: If the "official" name is DHC2-wheels, then dhc2w would > automatically be an acceptable synonym. > > This seems like an obvious step in the direction of user-friendliness. > Well, and what about using a graphical aircraft chooser. I know a good one ;-) -Fred PS: fgrun if you didn't get it. -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery http://fgsd.sourceforge.net/FlightGear Scenery Designer -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear-1.99.5-RC2
On 12/20/2008 01:59 AM, Erik Hofman wrote: > > Syd wrote: >> John Denker wrote: >>> 46:: Capitalization: Example: As of rc2, on the command line, when >>> specifying --aircraft=dhc2W, the "dhc" must not be capitalized, while >>> the "W" must be capitalized. This does not seem user-friendly. From >>> the user's point of view, this does not make any sense. >>> >> I'm open to suggestions would a dhc2-wheels , dhc2-floats make more >> sense ? > > I think John is thinking of using non cases-sensitive aircraft names. I was ... but Syd raises a couple of other good points: It wouldn't hurt to make the --aircraft=... option a) insensitive to hyphenation, and b) accepting of unique abbreviations as well as c) insensitive to case. Example: If the "official" name is DHC2-wheels, then dhc2w would automatically be an acceptable synonym. This seems like an obvious step in the direction of user-friendliness. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGPiston patch RFC
On Thu, 2008-12-18 at 19:47 -0700, John Denker wrote: > On 12/17/2008 12:18 AM, Ron Jensen wrote: > > > I've made the constant "C" a configurable item, but I don't have a good > > name for it. The patch calls it but there must be a better > > name... I just can't think of one. > > Physically, this C represents internal friction. So, maybe > "gagg_friction" or some such??? > > > The Gagg-Farrar equation uses a constant to express the power drop off > > of a piston engine as air density decreases. > > > > sigma= air_density / standard_density > > > > phi = ( sigma - C ) / ( 1 - C ) > > > > power *= phi > > > > In early testing it seems to work well. I used rho_air_manifold for > > air_density and replaced suction_loss, which was based in part on > > throttle position, with phi. This may resolve one of Torsten's issues > > with the FGPiston model. > > There seems to be a consensus that this engine model would > benefit from some TLC. > > The Gagg-Farrar equation is delightfully simple and reasonable. > However, AFAICT it assumes the throttle is wide open. That > makes sense for the original applications intended by Gagg > and Farrar ... but I don't think it does what FGPiston needs > to get done. > > In particular, I call attention to the lines in front of the > patch Ron contributed: > > suction_loss = RPM > 0.0 ? ThrottlePos * MaxRPM / RPM : 1.0; > if (suction_loss > 1.0) suction_loss = 1.0; > MAP = (something) * suction_loss; > > First of all, regarding this quantity "suction_loss", it's a > misnomer to call it a "loss" ... because as this quantity > becomes greater the MAP becomes greater. True, this is actually a normal value, with 1 equaling static pressure, and the value decreasing towards zero as map drops. > Terminology aside, I don't think we should be multiplying by > throttle/RPM ... instead we should be dividing by (1+RPM/throttle) > roughly speaking. > This is much better behaved, especially > at low RPM. Sorry, not true. Using your model for manifold pressure, http://www.av8n.com/fly/throttle.htm#eq-map-tk, I was unable to find a value for beta which satisfied a high manifold pressure (over 28 inHg ) at full throttle / 2700 rpm and a low manifold pressure (under 15 inHg) at 0.2 throttle / 750 rpm, for a 320 in^3 engine. The model behaved even worse for the 5800 RPM red-line Rotax912 model. Further, you never bothered to declare how we will define a value for Beta. I considered a similar route last year, however since details of specific aircraft engine induction systems are very hard to come by I dropped the idea in favor of specifying the peak horsepower RPM. > Furthermore, these lines seem to be missing a rather important > dependence on ambient pressure. Well, you decided to replace the inlet pressure variable with "something" so you lost p_inlet, which is assigned to p_amb(ient) at the top of the function. > This is related to the fact > that while dynamic viscosity is insensitive to pressure and > density, the kinematic viscosity is directly sensitive. > I wrote up a first draft of the algebra involved in making a > quasi-plausible model of this stuff. It can be found at > http://www.av8n.com/fly/throttle.htm > This includes a graph of the non-decreasing power versus > revs curve that we discussed yesterday. Again, a real engine will not increase power with RPM indefinitely. There is an RPM which represents a "peak" horsepower. See, for example, this table http://users.erols.com/srweiss/tablehdp.htm which estimates peak horsepower as a function of a single piston's displacement and flow rate into that piston. The instant engine, an O-320 has four cylinders each displacing 80 in^3. The table lists 200 CFM and 80 in^3 as having a peak horsepower at 2778 RPM. If you will remember I estimated the flow rate for our engine to be 200 CFM @ 2700 RPM, and the configuration file specifies 2700 RPM as the "maxrpm" which I used as a synonym for peak horsepower RPM. As you can see, this table is very close to the current model. If you want the model to produce power beyond 2700 rpm we need to simply raise the specified maxrpm in the config file. > The analysis is not 100% complete; in particular it does > not include the frictional terms that Gagg-Farrar features. > I reckon if we add that in, we might get something pretty > nice. In particular, the Gagg-Farrar result should emerge > as a corollary of the more general analysis, applicable to > the special case where the throttle is wide open. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGPiston patch RFC
On Fri, 2008-12-19 at 23:28 -0700, John Denker wrote: > Consider the following scenario: The Sim World c182rg is sitting on > the runway at KSFO. The propeller control is pulled back, so that the > engine is operating at relatively low revs, about 1750 RPM in > contrast to redline which is 2400 RPM. The pilot can observe that if > the throttle is open anywhere between 52% and 100% open, moving the > throttle has no effect on the MAP. Similarly, it has no effect on the > shaft power of the engine, as you can confirm by looking at the > property tree. This insensitivity to throttle setting is dramatically > unlike what is seen in a Real World Cessna 182RG. > > This buggy behavior is a direct consequence of the FGPiston.cpp code: > suction_loss = RPM > 0.0 ? ThrottlePos * MaxRPM / RPM : 1.0; > if (suction_loss > 1.0) suction_loss = 1.0; > MAP = p_amb * suction_loss; John, You've just convinced me you don't have a clue what is happening inside this code. Maybe I should have documented it better, but... Let me explain what I see happening here: The propeller configuration is loading the engine configuration down. This could be because the c_power for the prop configuration is too high, or it could be because the prop pitch is set to go too high, or it could be because engine is underpowered. It is definitely not because code section you seem to love going on about. Run the math: 1 * 2500 / 1750 = 1.45, which is clipped to 1. Suction_loss is a multiplier. A multiplier of 1 has no effect. That makes manifold pressure equal ambient pressure. This section of code has the engine set to the highest power it can put out. Which isn't enough to speed the propeller up. If that is wrong, it is configuration not code. Ron -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] 1.9.0 source upload
Ladies & Gentlemen, I would just like to announce that I have uploaded the FlightGear 1.9.0 source and base packages to an -as of yet- undisclosed location (although you can probably guess). The source packages are currently being redistributed to higher capacity servers and will hopefully be ready for general download during the course of the day. I also hope that the windows binary will be available soon. Cheers, Durk -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear-1.99.5-RC2
Syd wrote: > John Denker wrote: >> 46:: Capitalization: Example: As of rc2, on the command line, when >> specifying --aircraft=dhc2W, the "dhc" must not be capitalized, while >> the "W" must be capitalized. This does not seem user-friendly. From >> the user's point of view, this does not make any sense. >> > I'm open to suggestions would a dhc2-wheels , dhc2-floats make more > sense ? I think John is thinking of using non cases-sensitive aircraft names. Erik -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] METAR interpolation?
You're right. That's why I have implemented quickly a smooth changement precipitations. I think that the changement should be refactoring. Mostly for wind... Regards, Le vendredi 19 décembre 2008 à 14:35 -0600, Curtis Olson a écrit : > I just did a cross country flight with the latest CVS > cloud/weather/metar changes and I noticed that the weather > interpolation that smoothed out abrubt changes to wind and clouds when > a new METAR report comes in seems to have now been lost. We are back > to abrubt wind and cloud changes. I haven't had a chance to dig in > myself, but thought I'd mention this to the folks that currently have > their heads immersed in that section of the code. > > Regards, > > Curt. > -- > Curtis Olson: http://baron.flightgear.org/~curt/ > -- > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Nicolas VIVIEN -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
