* Vivian Meazza -- 1/1/2009 11:14 AM:
This hasn't mattered up to Melchior's patch,
because THROTTLE in YASim was clamped to positive values.
And it is *still* clamped to 0..1 by default. But, of course,
nothing should break if an FDM developer changes the clamping
explicitly.
m.
I don't think a normalized voltage makes any sense. It should be real
voltage in volts. Then the particular instruments should check for
acceptable input voltage. I must be missing some point, what's wrong
with this approach?
Nothing is wrong with this approach, but the normalized,
On 2 Jan 2009, at 09:05, Torsten Dreyer wrote:
Nothing is wrong with this approach, but the normalized, dimensionless
approach is a more general one.
Not really my area of expertise, but I'd far prefer to use real volts,
and have the aircraft electrical system define globally what it
On 2 Jan 2009, at 05:59, John Denker wrote:
On 01/01/2009 10:05 PM, syd adams wrote:
I think i assumed long ago that the GS deflection had a limit of
-10 to 10
like the heading-needle-deflection , and so scaled the needle to the
outermost dot accordingly.
That is not consistent with
On 2 Jan 2009, at 11:58, James Turner wrote:
Not really my area of expertise, but I'd far prefer to use real volts,
and have the aircraft electrical system define globally what it
considers nominal to be to, i.e what John proposed with:
Whoops, re-reading this, a tiny addendum: while I
On 2 Jan 2009, at 04:20, Csaba Halász wrote:
Found the feenableexcept() function, so expect more of these :)
Thanks to Ron for his help.
Applied. Frankly, all uses of atan() should probably be replaced with
atan2(), but with some inspection of the call site to verify the
change is sane.
On 01/02/2009 02:05 AM, Torsten Dreyer wrote:
I don't think a normalized voltage makes any sense. It should be real
voltage in volts. Then the particular instruments should check for
acceptable input voltage. I must be missing some point, what's wrong
with this approach?
That proposal has
On 2 Jan 2009, at 12:57, John Denker wrote:
The only thing that the jumper approach really needs is for
you to set a jumper to tell other people what you have done.
Asking aircraft designers to set one or two jumpers in the
property tree doesn't seem unreasonably burdensome.
This is the
On Fri, 2 Jan 2009, James Turner wrote:
/system/electrical/nominal = 1.0
/system/electrical/subnominal = 0.7
Just a minor side-note:
Could we find more descriptive property names for these voltage/potential
difference properties? Just to make it clear what they are (and avoid
Not really my area of expertise, but I'd far prefer to use real volts,
and have the aircraft electrical system define globally what it
considers nominal to be to, i.e what John proposed with:
For designers who prefer real volts:
/systems/electrical/nominal = 12
On 2 Jan 2009, at 13:26, Anders Gidenstam wrote:
Could we find more descriptive property names for these voltage/
potential
difference properties? Just to make it clear what they are (and avoid
confusion with potential future properties, e.g. for current, charge
or
power).
Good point.
On 01/02/2009 05:42 AM, Torsten Dreyer wrote:
For designers who prefer real volts:
/systems/electrical/nominal = 12
/systems/electrical/subnominal = 7
Doing it that way requires a definition of absolute values in each system and
for every possible operating voltage.
No, it does
For the GS, John states that the 'usable' part is only 0.7 degrees
thick. I'm unsure what usable means in that context, but given then
+/- 0.8 DDM range used by the Mk-VIII GPWS, and their dots-to-DMM
factor of 0.0875 for the GS, maximum deviation is 9.142 **dots**.
Clearly that's a much
On Fri, Jan 2, 2009 at 7:39 AM, James Turner wrote:
On 2 Jan 2009, at 13:26, Anders Gidenstam wrote:
Could we find more descriptive property names for these voltage/
potential
difference properties? Just to make it clear what they are (and avoid
confusion with potential future
On Fri, Jan 2, 2009 at 10:05 AM, Torsten Dreyer tors...@t3r.de wrote:
I don't think a normalized voltage makes any sense. It should be real
voltage in volts. Then the particular instruments should check for
acceptable input voltage. I must be missing some point, what's wrong
with this
0x00474dd6 in flightgear::CameraGroup::setCameraParameters
(this=0x2149370, vfov=0, aspectRatio=0) at
src/Main/CameraGroup.cxx:224
_viewer-getCamera()-setProjectionMatrixAsPerspective(vfov,
1.0f / aspectRatio,
On 2 Jan 2009, at 13:50, Curtis Olson wrote:
However, the existing XML based electrical system model is extremely
difficult to use from an xml configuration standpoint, and although
it worked ok for the c172 electrical system, I began to run into
core design barriers when i was
0x0085e028 in Tape (this=0xcb70970, hud=0xc835e50,
n=0xcb75420, x=320, y=240) at src/Instrumentation/HUD/HUD_tape.cxx:67
67 _odd_type = int(floorf(_input.max() + 0.5)) 1 ? true : false;
(gdb) p _input._max
$8 = 3.40282347e+38
Something along the lines of:
_odd_type =
On Fri, Jan 2, 2009 at 10:19 AM, James Turner zakal...@mac.com wrote:
On 2 Jan 2009, at 13:50, Curtis Olson wrote:
However, the existing XML based electrical system model is extremely
difficult to use from an xml configuration standpoint, and although
it worked ok for the c172 electrical
0x007e96fe in HeadingIndicator::update (this=0xc322430, dt=0)
at src/Instrumentation/heading_indicator.cxx:90
90 double factor = 0.01 / (spin * spin * spin * spin * spin * spin);
Similar lines at mrg.cxx:157, heading_indicator_fg.cxx:112 and
heading_indicator_dg.cxx:111
0x007e1c50 in GPS::updateTTWNode (this=0xce164c0,
c...@0x7fff664fdee0, distance_m=12822604.584446406,
no...@0x7fff664fddd0) at src/Instrumentation/gps.cxx:483
483 unsigned int TTW_seconds = (int) (TTW + 0.5);
(gdb) p TTW
$10 = 62278235905.950584
Not sure what it is calculating
On 2 Jan 2009, at 17:32, Csaba Halász wrote:
Not sure what it is calculating anyway. This happened with the
hurricane just at startup.
And all the while loops look silly too. Not to mention that it
should probably display times up to 99:59:59 so the check at the top
is wrong.
I have a
Csaba Halász wrote
0x007e1c50 in GPS::updateTTWNode (this=0xce164c0,
c...@0x7fff664fdee0, distance_m=12822604.584446406,
no...@0x7fff664fddd0) at src/Instrumentation/gps.cxx:483
483 unsigned int TTW_seconds = (int) (TTW + 0.5);
(gdb) p TTW
$10 = 62278235905.950584
Not
Going through the Primus manaul again , and one section states that capture
occurs at +- 0.5 degrees , and an approach illustration states typical
capture point at 1/3 dot ... so for the Primus it looks like each dot is 1.5
degrees deviation...
attachment:
On 01/02/2009 11:37 AM, syd adams wrote:
Going through the Primus manaul again , and one section states that capture
occurs at +- 0.5 degrees , and an approach illustration states typical
capture point at 1/3 dot ... so for the Primus it looks like each dot is 1.5
degrees deviation...
Which
Hi Folks
FG puts a model of a VOR shack into the scenery in places where
there is supposed to be a VOR shack. So far so good.
The problem is, the model seems awfully small. It looks like
it is about 5 meters in diameter. I've never seen one in RL
that is that small. I've seen them sometimes
John Denker wrote:
Hi Folks
FG puts a model of a VOR shack into the scenery in places where
there is supposed to be a VOR shack. So far so good.
The problem is, the model seems awfully small. It looks like
it is about 5 meters in diameter. I've never seen one in RL
that is that small.
John Denker wrote:
Hi Folks
FG puts a model of a VOR shack into the scenery in places where
there is supposed to be a VOR shack. So far so good.
The problem is, the model seems awfully small. It looks like
it is about 5 meters in diameter. I've never seen one in RL
that is that
On Fri, Jan 2, 2009 at 11:32 AM, John Denker j...@av8n.com wrote:
On 01/02/2009 11:37 AM, syd adams wrote:
Going through the Primus manaul again , and one section states that
capture
occurs at +- 0.5 degrees , and an approach illustration states typical
capture point at 1/3 dot ... so for
Further online searching turned up this
This deflection corresponds to the direction the pilot must fly to intercept
the glide path and is proportional to the angular displacement from the
glide path angle. As with the localizer, the full scale deflection is 150
microamperes. Typically, the
On 01/02/2009 01:01 PM, Erik Hofman wrote:
I've modeled them after these images in the past:
http://i149.photobucket.com/albums/s63/tundratantrum/kotzebuevortac1.jpg
http://www.dot.state.mn.us/aero/avoffice/navaids/images/vor3.jpg
http://members.chello.nl/vdleije/pics/ssj_vor.jpg
Wow, those
On Fri, Jan 2, 2009 at 2:32 PM, John Denker wrote:
On 01/02/2009 01:01 PM, Erik Hofman wrote:
I've modeled them after these images in the past:
http://i149.photobucket.com/albums/s63/tundratantrum/kotzebuevortac1.jpg
http://www.dot.state.mn.us/aero/avoffice/navaids/images/vor3.jpg
Putting on my aluminium foil hat, I'll point out that there are five
combinations of VOR/DME/TACAN even before you decide whether it is
going to be monitored locally and whether the earth has repeatable
conductivity to act as a ground plane. These decisions change what
gets physically installed
On 01/02/2009 01:37 PM, Curtis Olson wrote:
I can say from personal experience that Gopher (GEP, 117.30) is really tough
to spot from the air.
Here's the picture:
http://www.google.com/maps?ll=45.145694,-93.373194spn=0.012077,0.018539t=hz=16
If I'm measuring it properly, it's even bigger
I am moving this to the flightgear-devel list so we have a bigger chance of
getting some valueable comments or suggestions ;-)
OK - that turned out very well: many good comments and suggestions! Thanks
everybody for spending your time on this topic. I don't want to waste more of
it by
On Fri, Jan 2, 2009 at 1:10 PM, John Denker j...@av8n.com wrote:
Here's a proposal:
0) If somebody has actual data, use that; otherwise:
1) Put 17m diameter shacks in enroute locations.
2) Put 12m diamater shacks in on airport locations.
Anybody got a better idea?
Here is a derivative
Ok , Im getting closer...i think
Another manual i have states min glideslope angle = 2.5 degrees , maximum =
3.25 degrees,
so does that mean the needle animation range should be 0.25 at the upper
second dot, and -0.5 for the bottom second dot ?
That approach illustration is really confusing me now
Alex Perry wrote:
Here is a derivative idea. There are several classes of VOR
(irrespective of the other radio services that might be colocated)
which determine what the receivable range is ... and whether they're
usable for jet routes. That change in transmitter power may be a
defining
No. The standard design is based around 3 degrees slope. With that
design, the usable range is 1.4 degrees high, from 2.1 to 3.7 degrees
and offers 0.35 degrees per dot. Therefore, a dot equals 50ft per
mile range from the touchdown zone of the runway. When the standard
design is scaled for
OK , so my needle animation is far too insensitive , but the needle
deflection property shows 0 at dead center (3 degrees). What I was asking is
what amount of deflection per dot the needle should move based on the
existing property , so I'll go with 0.35 and try some approaches.
Thanks everyone
On 01/02/2009 03:28 PM, Alex Perry wrote:
From the point of view of implementation in a simulator, just take the
actual slope number for a specific runway and combine that with the
aircraft's position to generate a ratio. Repair the ratio to allow
for the side lobes (which as I recall are the
On 01/02/2009 06:26 AM, Anders Gidenstam wrote:
Just a minor side-note:
Could we find more descriptive property names for these voltage/potential
difference properties? Just to make it clear what they are (and avoid
confusion with potential future properties, e.g. for current, charge or
John Denker wrote:
Obviously there's considerable variability. I have no idea
how to determine what style is used in any given location.
Pass by and take pictures of each individual station. The size/type of
the respective housing is usually not recorded anywhere.
444 : double x = fabs(current[0] - metar[0]);
445 : double y = fabs(current[1] - metar[1]);
446 : double dx = x / (x + y);
447 : double dy = 1 - dx;
I guess we could even compare the speed/direction values directly
before
On Fri, Jan 2, 2009 at 3:12 PM, John Denker j...@av8n.com wrote:
On 01/02/2009 03:28 PM, Alex Perry wrote:
From the point of view of implementation in a simulator, just take the
actual slope number for a specific runway and combine that with the
aircraft's position to generate a ratio.
For the last couple of weeks, cvs fgfs does not allow initialization by
--prop:/environment/clouds/layer[0]/elevation-ft=
--prop:/environment/clouds/layer[0]/thickness-ft=
--prop:/environment/clouds/layer[0]/coverage=
either using fgrun or from the command line.
What I am getting is two layers
Dave Perry wrote:
For the last couple of weeks, cvs fgfs does not allow initialization by
--prop:/environment/clouds/layer[0]/elevation-ft=
--prop:/environment/clouds/layer[0]/thickness-ft=
--prop:/environment/clouds/layer[0]/coverage=
either using fgrun or from the command line.
What I
--- On Fri, 1/2/09, Erik Hofman e...@ehofman.com wrote:
From: Erik Hofman e...@ehofman.com
Subject: Re: [Flightgear-devel] VOR shack : scenery model upgrade opportunity
To: FlightGear developers discussions
flightgear-devel@lists.sourceforge.net
Date: Friday, January 2, 2009, 2:01 PM
John
In reading the recent postings, I see there's some confusion regarding
glide slope angle vs. glide slope *arc*. While the angle of the GS is
typically 3 degrees above the horizon (may vary for terrain, as
mentioned previously), the arc that the GS swings tends to be 1.4
degrees, according to the
Stuart Buchanan wrote:
Dave Perry wrote:
For the last couple of weeks, cvs fgfs does not allow initialization by
--prop:/environment/clouds/layer[0]/elevation-ft=
--prop:/environment/clouds/layer[0]/thickness-ft=
--prop:/environment/clouds/layer[0]/coverage=
either using fgrun or from
On Fri, 2009-01-02 at 15:53 +0100, Csaba Halász wrote:
For such generic models the configuration xml should provide the the
relevant voltages of the operating characteristics (not necessarily
only min/max).
If I have a 12V instrument modeled in xml on top of the C++ code, I
still want to be
On 01/02/2009 05:33 PM, Bohnert Paul wrote:
http://scenemodels.flightgear.org/modeledit.php?id=39 vordme_1
http://scenemodels.flightgear.org/modeledit.php?id=615 vordme_2
1) Thanks for the points.
2) For folks without edit passwords, the following is more
useful:
52 matches
Mail list logo
