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:
http://scenemodels.fl
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
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 fgr
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 FA
--- On Fri, 1/2/09, Erik Hofman wrote:
> From: Erik Hofman
> Subject: Re: [Flightgear-devel] VOR shack : scenery model upgrade opportunity
> To: "FlightGear developers discussions"
>
> Date: Friday, January 2, 2009, 2:01 PM
> John Denker wrote:
> > Hi Folks
> >
> > FG puts a model of a VOR sh
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.
>
> Wh
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
lay
On Fri, Jan 2, 2009 at 3:12 PM, John Denker 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. Repair the
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 doin
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.
> http://www.thtech.net/im
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
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
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 fo
On 01/02/2009 02:25 PM, 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
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 ter
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
> definin
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
On Fri, Jan 2, 2009 at 1:10 PM, John Denker 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 derivat
> 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 rewindi
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.373194&spn=0.012077,0.018539&t=h&z=16
If I'm measuring it properly, it's even big
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 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
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, tho
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 g
On Fri, Jan 2, 2009 at 11:32 AM, John Denker 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 the P
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 th
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
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 w
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...
Whic
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...
<>
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
>
>
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 ha
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 anyw
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
Apparently
On Fri, Jan 2, 2009 at 10:19 AM, James Turner 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 system,
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 = _input.max(
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 atte
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 Fri, Jan 2, 2009 at 10: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?
> Not
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 futur
> 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 muc
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, i
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 po
> 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
>/systems/elec
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
c
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
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
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 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 bel
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 consist
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
con
> 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, dimensio
* 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.
---
53 matches
Mail list logo