Andy Ross
Vivian Meazza wrote:
control-input axis=/controls/engines/engine[0]/boost-control
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 -
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 can
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 discussion was about
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).
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-input axis=/controls/engines/engine[0]/throttle
control=THROTTLE/--
control-input
-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 wrote:
Not. At least, only
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 designer
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 same
thing.
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
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 any of
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 the new
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-input axis=/controls/engines/engine[0]/boost-control
control=THROTTLE/
when we get it to work?
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
Andy Ross
Vivian Meazza
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
Vivian Meazza wrote:
control-input axis=/controls/engines/engine[0]/boost-control
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
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
it's
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-devel
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
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 and UK
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 boost
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.
What does show
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
just have to
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
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 case
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 hack
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, so
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:
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
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:
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
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 general
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 thereafter
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
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
much imho)
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 (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
36 matches
Mail list logo
