On Sun, 19 Jun 2005 09:08:05 -0700, Andy wrote in message
<[EMAIL PROTECTED]>:
> Arnt Karlsen wrote:
> > Andy Ross wrote:
> > > Yeah, but that's a bug. There is only one manifold pressure.
> > > Surely you don't want *both* "mp-inhg"
> > > and "supercharger-output-inhg", which mean exactly the s
Erik Hofman wrote:
> No we shouldn't. In aviation there are not many places where SI units
> are used so we stick with what is used by default. If you don't like it
> use Nasal to correct it yourself.
In the _long_ run it might make _much_ sense to use SI units
_internally_ and let every design
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:flightgear-devel-
> [EMAIL PROTECTED] On Behalf Of Andy Ross
> Sent: 19 June 2005 18:34
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] New turbo/supercharger code
>
> Vivian Meazza
Vivian Meazza wrote:
> Not. At least, only in the sense of RTB. This is where we came in. It might
> not produce any thrust, but it should solve shouldn't it?
Er, huh? I guess I don't understand how you think that would work.
What the solver does is figure out how much drag the airframe needs to
Andy Ross
> > No - nothing else has been modified. I've gone back to the cvs-head
> version
> > of source and data. This is the _only_ change in the code anywhere:
> >
> >
> > >control="THROTTLE"/>
>
> Bingo.
Not. At least, only in the sense of RTB. This is where we cam
Vivian Meazza wrote:
> What does it do for defined properties that contain null/nil?
It doesn't. The solver doesn't actually try to read properties during
solution (which would be madness -- you would get different solution
results by changing values that aren't in the aircraft definition
file).
Arnt Karlsen wrote:
> Andy Ross wrote:
> > Yeah, but that's a bug. There is only one manifold pressure.
> > Surely you don't want *both* "mp-inhg"
> > and "supercharger-output-inhg", which mean exactly the same
> > thing.
>
> ..I beg to differ; flow always means there are flow losses.
The discuss
Andy Ross
> Vivian Meazza wrote:
> > OK with the name. PSI(gauge) is what we use over here, otherwise
> > it's inhg absolute for the US. Gauge-inhg makes no sense. In real
> > life there's no difference between the way the US and UK measure the
> > pressure, it's the zero on the gauge which is d
Andy Ross wrote
> Vivian Meazza wrote:
> > I would deduce that the property:
> > Controls/engines/engine/boost-control
> > Does not exist when the solver runs.
>
> It should still see a zero for undefined properties,
What does it do for defined properties that contain null/nil?
> although you
Andy Ross
>
> Vivian Meazza wrote:
> > >
> > Here is the setting in the property browser
> >
> > Controls/engines/engine/boost-control= 1.0
>
> Case bug or just a typo?
>
Oh, were it that easy! Unfortunately, neither - my mail client did that -
it's right in the code.
I've checked n times.
On Sat, 18 Jun 2005 15:24:09 -0700, Andy wrote in message
<[EMAIL PROTECTED]>:
> Vivian Meazza wrote:
> > OK with the name. PSI(gauge) is what we use over here, otherwise
> > it's inhg absolute for the US. Gauge-inhg makes no sense. In real
> > life there's no difference between the way the US an
Vivian Meazza wrote:
> I would deduce that the property:
> Controls/engines/engine/boost-control
> Does not exist when the solver runs.
It should still see a zero for undefined properties, although you can
make arbitrary property settings in the approach/cruise definitions up
at the top. Some of
Vivian Meazza wrote:
> > I found this in thrusters.cpp
> Another potential pooh trap?
No, those are applied to the throttle setting after the input mapping has
happened. The code you want to be reading is in ControlMap.[hc]pp
Andy
___
Flightgear-deve
Vivian Meazza wrote:
> OK with the name. PSI(gauge) is what we use over here, otherwise
> it's inhg absolute for the US. Gauge-inhg makes no sense. In real
> life there's no difference between the way the US and UK measure the
> pressure, it's the zero on the gauge which is different, so I think
>
Vivian Meazza wrote:
>
> Here is the setting in the property browser
>
> Controls/engines/engine/boost-control= 1.0
Case bug or just a typo?
Andy
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/list
Oliver C. wrote:
> In this case inch Hg is wrong, because it is not an SI-unit.
> Pascal (Pa) is a SI-Unit so that should be used in the base code.
> Conversion from none SI-Unit can still be done in nasal code.
Uh... except that aircraft gauges almost never read in SI units.
The point here isn't
I wrote:
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:flightgear-devel-
> [EMAIL PROTECTED] On Behalf Of Vivian Meazza
> Sent: 18 June 2005 11:23
> To: 'FlightGear developers discussions'
> Subject: RE: [Flightgear-devel] New turbo/supercharger code
I wrote:
>
>I found this in thrusters.cpp
>
> void Thruster::setThrottle(float throttle)
> {
> _throttle = Math::clamp(throttle, 0, 1);
> }
>
> Will this prevent a negative value for:
>
> control="THROTTLE"/>
>
> when we get it to work?
>
Another potential pooh trap?
// Returns the inp
Andy Ross
> Vivian Meazza wrote:
> > Engines/engine/boost-pressure-psi-gauge = 46.00167 (correct order of
> > boost)
>
> Can you try it with the CVS code? This may be interacting badly with
> your local changes, which makes debugging difficult. Nothing in this
> mechanism should require any of
Andy Ross wrote:
> Vivian Meazza wrote:
> > Engines/engine/boost-pressure-psi-gauge = 46.00167 (correct order of
> > boost)
>
> Can you try it with the CVS code? This may be interacting badly with
> your local changes, which makes debugging difficult. Nothing in this
> mechanism should require
Oliver C. wrote:
We should really try to use only SI-units everywhere in the base code.
If this is not the case, we should start to correct that.
No we shouldn't. In aviation there are not many places where SI units
are used so we stick with what is used by default. If you don't like it
use
On Saturday 18 June 2005 01:09, Andy Ross wrote:
>
> mp-pascals: Is this needed? The standard so far for manifold pressure
>has always been inHg. Having lots of duplicate units around
>complicates things; we can always do conversions in the panel
>animations or Nasal code.
In this ca
Vivian Meazza wrote:
> Engines/engine/boost-pressure-psi-gauge = 46.00167 (correct order of
> boost)
Can you try it with the CVS code? This may be interacting badly with
your local changes, which makes debugging difficult. Nothing in this
mechanism should require any of the new code.
Also on th
I wrote:
>
> Andy Ross wrote
>
> >
> > I'm quite certain this technique works. It's been in there, and
> > actively used, since day one.
>
> Yes, I know it should work, and I'm familiar with its use elsewhere: this
> was behind my query yesterday. It seems to partially work. Odd. Well, I'll
>
Andy Ross
> Vivian Meazza wrote:
> > Good news: I've got Andy's code to run. Just a few minor changes.
> > Bad news: It doesn't work.
> >
> > I've set the property "/controls/engines/engine[0]/boost-control" to
> > a fixed value. Yasim shows the correct Boost value. But there's no
> > power.
>
>
Vivian Meazza wrote:
> Good news: I've got Andy's code to run. Just a few minor changes.
> Bad news: It doesn't work.
>
> I've set the property "/controls/engines/engine[0]/boost-control" to
> a fixed value. Yasim shows the correct Boost value. But there's no
> power.
What does "show the correct b
I wrote:
> > > Additive? I.e. are the input axes added?
> >
> > Yes, all control axes are added to get the final value (clamped to the
> > natural output range, of course); this is how trim works, for example.
> >
>
> I thought so, thanks.
>
Good news: I've got Andy's code to run. Just a few m
Andy Ross
> Vivian Meazza wrote:
> > Additive? I.e. are the input axes added?
>
> Yes, all control axes are added to get the final value (clamped to the
> natural output range, of course); this is how trim works, for example.
>
I thought so, thanks.
V.
Vivian Meazza wrote:
> Additive? I.e. are the input axes added?
Yes, all control axes are added to get the final value (clamped to the
natural output range, of course); this is how trim works, for example.
Andy
___
Flightgear-devel mailing list
Flightg
Andy Ross
> Vivian Meazza wrote:
> > I like it very much indeed. Will it work in practice? Testing and
> > tuning will take some time as I don't have any exact data. Probably
> > into next week.
>
> I suspect it should work fine. The real device would have been an
> analog computer hooked to a (
Vivian Meazza wrote:
> I like it very much indeed. Will it work in practice? Testing and
> tuning will take some time as I don't have any exact data. Probably
> into next week.
I suspect it should work fine. The real device would have been an
analog computer hooked to a (presumably) slow motor, s
Andy Ross
Vivian Meazza wrote:
> > It would be possible to simulate the Boost Control Cutout by
> > adjusting the wastegate on the fly to a very high number effectively
> > disabling it (I take that it is possible to do that). It's a hack, I
> > don't like it, but ...
>
> The whole thing is a ha
Vivian Meazza wrote:
> It would be possible to simulate the Boost Control Cutout by
> adjusting the wastegate on the fly to a very high number effectively
> disabling it (I take that it is possible to do that). It's a hack, I
> don't like it, but ...
The whole thing is a hack anyway; if we *really
Andy Ross wrote:
> Vivian Meazza wrote:
> > Andy Ross wrote:
> > >* For one, I still hate the boost function that goes negative at high
> > > RPM
> >
> > I have revised the curve: now a Hoerl power function. It's a good fit
> > over the rpm range up to x4 peak power rpm (unnecessary: x3 is too
>
On Wed, 15 Jun 2005 10:26:33 -0700, Andy wrote in message
<[EMAIL PROTECTED]>:
> The cleanest solution at this point, IMHO, would to split out the
> x-charger implementation and do it twice: once for gear-driven
> superchargers and again for exhaust-driven turbochargers.
..these can re-use code
Vivian Meazza wrote:
> Andy Ross wrote:
> >* For one, I still hate the boost function that goes negative at high
> > RPM
>
> I have revised the curve: now a Hoerl power function. It's a good fit
> over the rpm range up to x4 peak power rpm (unnecessary: x3 is too
> much imho) and tails off therea
I wrote
> Already the case: see above. I considered a spline, but the extra
> complication doesn't really give a better outcome. Asymptotic ... OK up
> to
> a point, but at some rpm the compressor goes supersonic (depending on the
> design) and output falls away. I attempt to model this in a gene
Vivian Meazza wrote:
Andy Ross wrote
Vivian Meazza wrote (in a CVS checkin):
I've removed all the features that rely on the diff to YASim
that I posted recently, I don't expect any reaction from Andy
any time soon! I feel a bit inclined to remind him of his rant
against Cygwin recently. I'm wi
Andy Ross wrote
> Vivian Meazza wrote (in a CVS checkin):
> > I've removed all the features that rely on the diff to YASim
> > that I posted recently, I don't expect any reaction from Andy
> > any time soon! I feel a bit inclined to remind him of his rant
> > against Cygwin recently. I'm willing
Vivan Meazza wrote (in a CVS checkin):
> I've removed all the features that rely on the diff to YASim
> that I posted recently, I don't expect any reaction from Andy
> any time soon! I feel a bit inclined to remind him of his rant
> against Cygwin recently. I'm willing to be favourably
> surprised.
40 matches
Mail list logo