Hi --
I cobbled up some XML code to implement an
interval timer
aka approach timer
aka stopwatch.
Having an interval timer is more-or-less indispensible for performing
certain types of instrument approaches.
The XML can be found at:
http://www.av8n.com/fly/fgfs/stopwatch.xml
This
Hi --
Over the weekend I went looking for an X52 configuration file,
without success. I found rumors of its existence, but when I
tried to fetch the file, either the server was down, or the
tarball was gone, or the tarball didn't contain what I needed.
Eventually I decided it was easier to
On 01/02/2007 12:09 AM, Ron Jensen wrote:
I find including more libraries in some of
the Makefile.am's does the trick for me... I'm attaching a diff of my
debian-etch build tree against today's CVS.
Thanks for the patches. They applied cleanly to the bleeding edge package
but utterly failed
On 01/02/2007 03:51 PM, Roy Vegard Ovesen wrote:
You can't possibly mean replacing every occurence of the old list address in
the archive.
Good point; I didn't mean that.
How about starting with places like these:
-- http://mail.flightgear.org/mailman/listinfo/flightgear-devel
--
On 01/03/2007 04:00 PM, Curtis Olson wrote:
we do want this to work intuitively so I would welcome
any changes to improve the in-air reposition dialog box.
:-)
I think it makes a lot
more sense to focus on the gui dialog box.
Agreed.
I'm coming at this from the perspective of an
I found a way to make it do what I want. Here's my version
http://www.av8n.com/fly/fgfs/location-in-air.xml
and the diff against the cvs version:
http://www.av8n.com/fly/fgfs/location-in-air.diff
On 01/03/2007 05:19 PM, Curtis Olson wrote:
Only if you are relocating to a nearby position.
On 01/03/2007 09:07 PM, Dave Perry wrote:
This may seem a nit. I had the following quote drilled into my mind
by Don Berman in one of his well know Instrument Written Ground School
seminars.
Radials eminate from the station; direction of flight has nothing to
do with location.
1)
On 01/04/2007 04:28 AM, Torsten Dreyer wrote:
Well - at least on the eastern side of the atlantic, where I do instrument
flights in real world, the 090 radial is always EAST of the station, the 270
radial is WEST of the station.
A controller advice proceed on radial 090 or intercept radial
On 01/05/2007 04:06 AM, Torsten Dreyer wrote:
Less dirty and more correct should be:
relocate to the position of the fix, grab the magnetic variation and
calculate
the transporter coordinates using bearing and distance. Relocate again to
these coordinates. You can safely call this
Hi --
I have extensively reworked the location-in-air.xml popup.
It is now much more pilot-friendly.
I would appreciated if other folks would play with it
and provide feedback.
The latest greatest version is at
http://www.av8n.com/fly/fgfs/location-in-air.xml
there is also a diff
On 01/06/2007 04:25 PM, Jon S. Berndt wrote:
I'm not sure what you are talking about here. Could you be more descriptive?
I'll try!
Let's start with some use case analysis:
Scenario 1: User wants to practice landings. Using command-line options,
the user initializes the system to 4 mile
On 01/07/2007 12:28 PM, Martin Spott wrote:
John, actually, what you're looking for is a routine that allows you to
dump the whole property tree at runtime into a file and allow
re-loading this as a preset. In order not to break current behaviour it
would be necessary to compile a
On 01/07/2007 01:25 PM, Martin Spott wrote:
[...] For my purposes (and
I suspect a lot of other purposes besides), is much more useful
to be able to warp to some improvised place, without ever having
been there before.
Without ever having been there before I'd say you'll never know in
which
My version of fgfs has a rather large memory leak.
If I leave the thing parked after a flight, brakes on,
simulator paused, it will gobble up about 3 gigabytes
of virtual memory overnight. (In contrast, it's only
a little over 500 meg after a few minutes of flight.)
I'm running the version of
On 01/08/2007 10:06 AM, Stuart Buchanan wrote:
Are you particularly interested in using the c182?
Well, yes I am. A lot of FBOs will let you rent a 182. If we make
an XY plot trading off availability versus a combination of speed
and roominess, the 182 has high availability for a given
On 01/08/2007 12:44 PM, Stuart Buchanan wrote:
OK - I'll probably leave this as a general emissive light. Where is the
switch located? On the ceiling?
Multiple switches. Perhaps the most relevant to the model are the
two dimmer knobs (commonly but improperly called rheostats) located
just to
On 01/08/2007 02:17 PM, Stuart Buchanan wrote:
Already available - hold down the [middle] mouse-button when in tile/pan
mode
and drag the mouse around.
1) Thanks for the clue. I've been relying on my joystick (not
mouse) since Day One, so I had never explored the various
combinations of mouse
Here are some hints on how to build fgfs from source. This is what I
have had to do to get it to come anywhere /close/ to working on Debian
etch; there are still compilation errors.
If anybody has corrections or further suggestions, please speak up.
Also, I point out (again) that the
Hi --
I rejiggered the instrument placement on the c182 3d panel to
make it more nearly resemble the real aircraft.
My handiwork can be found at
http://www.av8n.com/fly/fgfs/c182s-3d-panel.xml.htm
http://www.av8n.com/fly/fgfs/c182s-3d-panel.xml
References, for comparison:
On 01/10/2007 01:08 PM, Stuart Buchanan wrote:
Looks good, except that the OMI marker cover the DME and the logo is
hiddden behind one of the radios
Good catch.
(though it was probably already like
that).
No, I broke it.
But it's fixed now.
The hsi now responds correctly to simulated failure as commanded
by the heading indicator item on the instrument failure popup.
My handiwork can be found at
http://www.av8n.com/fly/fgfs/hsi.xml.htm
http://www.av8n.com/fly/fgfs/hsi.diff
I have not checked other hsi-like instruments to see if
1) Did you know that there are 8 different BRAVO intersections
in the database?
Until now there was no support in the code for this; all but
one of the entries was thrown away at the lowest level. There
was a comment in the code saying that fixing this was on the
TODO list.
Well,
On 01/11/2007 10:58 AM, Stuart Buchanan wrote:
John Denker has suggested that a C-182 RG would be a good addition.
I'm still interested in that. It would be tremendously useful as a
procedures trainer.
However, this is very much on the drawing-board and would require
significant effort - we
I munged the code so that the routines that manage
the fix database (waypoints etc.) and
the navaid database
are now insensitive to the upper-case / lower-case distinction.
That is, the RBX VOR/DME is now equivalent to the rbx VOR/DME.
I have checked that all navaids and waypoints in the
On the Seneca II model, the KX 165 radios are broken.
-- When I try to tune 116.0 I get 116.99
-- When I try to tune 111.7 I get 111.69
-- But you can't just say everything is off by 0.01 MHz, because
if I put in 116.01, I get 116.01. The 116.0 result is skipped,
i.e. avoided!
I imagine
On 01/12/2007 04:08 AM, Stuart Buchanan wrote:
I don't know whether this should just a c182rg-set.xml file in the c182
directory, or completely separate in a c182rg directory. I suspect the
latter as the FDM and models files will (eventually) be different.
Eventually, I suppose. But there's
On 01/12/2007 05:41 PM, Georg Vollnhals wrote:
Hi John,
Generally spoken, I read all your posts with big interest.
:-)
Thanks for the feedback.
don't worry - this was one of Melchior's usual jokes. We all saw he
corrected it in CVS thanks to your hint.
OK, thanks for the explanation; I
On 01/12/2007 09:23 AM, Stuart Buchanan wrote:
Perhaps you could take a look at the FDM ?
That's not really on the list of things I was looking forward to
I think that most of the
coefficients were copied from a c172 (from looking at the CVS logs), so
are probably inaccurate.
As I've
On 01/13/2007 09:53 PM, Ron Jensen wrote:
squat switch.
Well, I decided to plug the script in and make it work... Done
Nifty.
I'm in the process of implementing a gear warning horn that comes on
when manifold pressure drops below 13 inches and gear lever is up.
I know the POH expresses
On 01/15/2007 04:27 AM, Stuart Buchanan wrote:
I think it is time for this to go into CVS, if no-one objects.
Certainly no objections from me. Any remaining nits should
be fixed within CVS, not without.
While we're on the subject: the 182rg should be added to the
download page:
On 01/13/2007 09:53 PM, Ron Jensen wrote:
squat switch.
Well, I decided to plug the script in and make it work... Done
Nifty.
I'm in the process of implementing a gear warning horn that comes on
when manifold pressure drops below 13 inches and gear lever is up.
I know the POH expresses
On 01/15/2007 12:12 AM, Ron Jensen wrote:
Remapped the G/g keys to control only the gear handle.
controls/gear/gear-down is only controlled by nasal.
That brings to light a problematic situation.
There are three properties of interest:
1) gear-handle-down
2) wow (aka squat switch)
3)
The current (cvs) fix.dat.gz has, internally, a 2005 date.
There are fixes missing from that database, and also fixes
in the database that are wrongly located.
How might we go about updating the databases?
-
Take Surveys.
On 01/16/2007 12:35 PM, Curtis Olson wrote:
I was told that JSBSim only runs the wow computations when the altitude
200' agl.
That's what we call an undocumented feature.
It would be nice to change this behavior, but you'll need
to convince the jsbsim gods that this is a problem that
On 01/13/2007 11:53 AM, Stuart Buchanan wrote:
John - can you tell me if I've got the gear animation approximately
correct. From photographs I've guessed that they fold up rearwards.
Yes, it is approximately correct.
1) I observe that the two main gear retract at unequal rates; this is
On 01/15/2007 04:27 AM, Stuart Buchanan wrote:
I have done some work on the FDM to decrease the aileron
response and adverse yaw.
That sounds great! Thanks!
I still have some tuning to do however - I can't
get above 112kts @ 5,000ft, even at 100% throttle which suggests some of
the drag
Hi --
Below is a piece of nasal code that reproducibly segfaults.
Remarks:
a) IMHO interpreted code should never segfault.
b) This code doesn't seem particularly unreasonable.
1) The stack trace and other lines of evidence indicate that it
is significant that the code sets and removes a
On 01/17/2007 09:22 AM, Melchior FRANZ wrote:
An old-school
polling loop wouldn't be less effective.
Ah, don't worry, there is a solution -- involving a timer
rather than a listener -- that is adequate for this unusual
purpose. Not elegant, but adequate.
Letting a listener remove itself is
This is getting somewhat OT, but it's fun, so I thought I would
mention it:
When you fly the Skylane RG, always take the tow-bar with you;
don't leave it in the hangar.
I guy I know had a gear failure involving loss of hydraulic
fluid (not simply failure of the hydraulic pump) such that
the
On 01/17/2007 01:47 PM, Melchior FRANZ wrote:
May I ask why this is a bad idea?
Because it's not supported? :-)
May I suggest that the documentation should /say/ it's
not supported? Waiting for a runtime error message
that may or may not occur within any bounded time is
not a good way to
On 01/17/2007 02:31 PM, Melchior FRANZ wrote:
The documentation doesn't say that. It says exactly:
Note that a listener can not remove itself, neither directly
nor indirectly.
Sorry, I missed that.
-
Take Surveys. Earn
On 01/16/2007 12:57 PM, daveluff wrote:
The best way to keep the data updated would be to feed improvements to
Robin Peel (http://x-plane.org/home/robinp/) and then pull his updated
data periodically.
An excellent suggestion.
In the meantime,
1) I pulled the data from the x-plane site.
I cobbled up a tachometer with the proper green arc and redline
for the c182 and c182rg
Here's the graphic plus the xml to make it work:
http://www.av8n.com/fly/fgfs/tach-skylane.tgz
Here's a patch to install it in the panel of both aircraft:
http://www.av8n.com/fly/fgfs/tach-skylane.diff
Here is a patch to make the engine sound more like it
should for the skylane (c182 and c182rg)
http://www.av8n.com/fly/fgfs/skylane-sound.diff
Previously the sound was the same for all engine speeds
from 1500 RPM on up. This detracted from the realism.
Pilots are verrry attuned to small
1) Here's a patch to add some semblance of a transponder to the
Skylane (c182 and c182rg)
http://www.av8n.com/fly/fgfs/xpdr-skylane.diff
This increases the usefulness of the model as a procedures trainer.
2) I notice that xpdr.xml is presently not much more than a stub.
It
In the real world, some VOR stations and even some localizers
have a colocated DME station ... but there are plenty that
don't.
The DME has its own Morse ident, with a distinctive higher pitch.
In the simulator, due to a bug in the code, all stations
transmit the DME Morse ident ... even
On 01/28/2007 05:12 AM, Melchior FRANZ wrote:
I would, for example, have felt responsible for your
location-in-air dialog, as I had worked a lot on GUI matters.
There were reasons why I didn't pick it up: (1) I wasn't at
my computer at that time.
Please check again the next time you are at
On 01/28/2007 05:12 AM, Melchior FRANZ wrote:
If one patch has been ignored for longer, point
to it again.
On 01/11/2007 03:55 AM, John Denker wrote:
1) Did you know that there are 8 different BRAVO intersections
in the database?
Until now there was no support in the code
Ron Jensen wrote:
I modelled a KT-70 transponder. It is at
http://www.jentronics.com/fgfs/Instruments-3d.tgz
Attached is a patch to install it in the c182rg.
On 01/28/2007 01:28 PM, Martin Spott wrote:
Did you check that this doesn't collide with the transponder that's
already present ?
On 01/28/2007 01:28 PM, Martin Spott wrote:
Did you check that this doesn't collide with the transponder that's
already present
Ah, yes, very newly present.
Here is the patch to remove my semblance of a transponder
to make way for Ron Jensen's vastly nicer transponder.
This is a patch
On 01/28/2007 04:43 PM, Martin Spott wrote:
[last week] I applied the patch which implemented your 'semi-transponder'
right the next day. Anything wrong with this ?
Definitely not wrong! Thanks!
Indeed this week's patches are dependent on last week's
patches. Only a few lines of last week's
On 01/29/2007 06:15 PM, Martin Spott wrote:
I don't think there's a real solution to this problems that adresses
all your concerns.
/All/ my concerns? As the saying goes: Do not let the perfect
be the enemy of the good.
I don't expect a SCM system to end world hunger. But there
are things
On 01/29/2007 11:01 PM, Dave Perry wrote:
This is exactly the situation that John Denker maintained was an
exception to the rule report position as the radial from the station
and DME distance. This pilot agreed with John.
Actually I have changed my mind about this. A couple of days
ago I
On 01/31/2007 11:53 AM, Torsten Dreyer wrote:
- starting fg with a c182
- opening property browser
- browsing to /instrumentation/heading-indicator
- observing properties indicated-heading-deg and offset-deg
- opening second property browser
- browsing to /orientation
- observing property
On 01/31/2007 05:18 PM, I wrote:
Another migration strategy: The only
aircraft that would require fiddling are ...
It's even easier than I thought. The three that
presently provide power to the so-called DG also
provide power to the hsi, so AFAICT the patch
can be dropped in with no
On 02/02/2007 10:20 AM, Stuart Buchanan wrote:
and have all the .nas files that are loaded by default defined in
preferences.xml. I've never liked the fact that we always pick up any .nas
files in the Nasal/ directory.
There are two sides to that coin.
a) There are plenty of situations
Torsten Dreyer wrote in part:
this one needs patching of all aircraft that uses the hsi.
I believe that is no longer true.
AFAIK, no aircraft require patching to use the new hsi.
More particularly, it is my /goal/ to make the new hsi
upward-compatible with the old hsi.
If that goal is
Here is the current list of bugs etc. from
http://wiki.flightgear.org/flightgear_wiki/index.php?title=Bugs
1 Known Bugs
1.1 Z-buffer burn-through
1.2 Memory leak
1.3 Numerous bugs in ATIS feature
1.4 Problems with --altitude option
1.5 Multiple bugs in the location-in-air popup
On 02/05/2007 07:55 PM, Durk Talsma wrote:
I've never seen any memory leaks that bad.
Could you please try it with the simulator /paused/?
A rather steady leak of 2 meg per minute is observed chez moi during pause,
no matter whether the aircraft is aloft or parked on the ground. Vastly
less
On 02/06/2007 03:47 PM, Tatsuhiro Nishioka wrote:
I calculated the position of CG with the equation obtained at:
http://www.paragonair.com/public/docs/FAA-Handbooks/8083-01_WnB/
8083-01_ch08.pdf
According to this document, the distance from the nose to the CG is
calculated as:
CGoffset
Can you pretend to be a computer?
Try interpreting the following trivial piece of nasal code by hand.
Then see if the nasal interpreter agrees with your interpretation.
node = props.globals.getNode(/foo/bar, 1);
bar = getprop(/foo/bar);
if (bar == nil) {
str = bar: nil, ;
}
On 02/07/2007 09:47 AM, Ron Jensen wrote:
While working on 3D cockpit instruments I keep hitting into issues with
internal floating point representation and the textranslatestep tag.
The step tag effectively truncates the property, 29.9199
becomes 29.91, so a (3D) readout reads off
On 02/07/2007 12:26 PM, Ron Jensen wrote:
How would the step function know to round to the proper number of
decimal places? In the 2D instruments a printf-style statement is used,
i.e. format%02.2f/format. However, we're not exactly printing in
textranslate.
I thought about a
On 02/07/2007 02:14 PM, Andy Ross wrote:
The patch itself looks sane and easy. But I think I agree with
John, this is a workaround for a design flaw in the step animation
that we should just fix.
:-)
So you want to pass in the floating point value 29.92 and a step of 10
and get back
Improved code. Previous version went against the POSIX convention.
# Following the POSIX convention,
# halfway cases are rounded away from zero,
# to the extent this is possible given the inherent
# inexactitude of the floating-point representation.
round = func(arg, quantum=1){
if (quantum
On 02/08/2007 12:35 PM, gh.robin wrote:
If it is FG cvs with OSG, it is not a surprise to me, i told before on
several
topics regarding autopilot, that it is not working.
Nobody but Lee answered to confirm that it is not working.
The default c172p in the current CVS is messed up in ways
On 02/07/2007 02:14 PM, Andy Ross wrote:
So if there's a design flaw here, it's at a higher level. Maybe
what's really needed is a digit extractor animation instead.
Good news: The /design/ is not as flawed as it looks.
All evidence indicates that the primary problem with the
On 02/09/2007 11:08 AM, Ron Jensen wrote:
I stripped the apply_mod() function out into its own small program for
analysis.
The experimental analysis confirms that the code is numerically
unstable.
I don't think there is any way to make it numerically stable.
The instability can be swept
On 02/09/2007 09:34 PM, Ron Jensen wrote:
[250 lines of stuff we agree about]
Except in your algorithm '0' can never be used as a scroll value.
Well, I fixed that just now. New version:
http://www.av8n.com/fly/fgfs/animation.diff
Anybody who wants to set scroll0/scroll is now free to do
In some parts of the world, (including the southwest
US), a goodly fraction of the localizers have an expanded
service volume (ESV), often quite a bit larger than the
standard service volume you see in the AIM.
The code in navradio.cxx has been ignoring the service volume
information in the
On 02/10/2007 09:48 AM, Dave Perry wrote:
On my system, I have the following running:
1. Moved the pa24 radio stack to Aircraft/Instruments-3d/, along with
the required changes to the pa24-250.
[etc.]
Yes, that's a good move.
While were on the subject ... could you please similarly
export
The standard altimeter (used by the default c172p aircraft and many others)
had been using an unhappy hodgepodge of layers. The analog Kollsman window
was unusable, because it was unlabeled, and the digital altimeter setting
was unusable, especially at altitudes near 2500 feet, partly from being
There is evidently at least one serious misconception in
the code that calculates atmospheric pressure, altimeter
settings, et cetera. This can be easily demonstrated:
Park at or near the threshold of runway 33 at Aspen
(KASE). Under standard conditions, observe that the
altimeter reads 7820 feet
On Sun, 2007-02-11 at 00:22 -0500, John Denker wrote:
Both the Weather Conditions popup and the atis.cxx code rely
on the pressure-sea-level-inhg property and use it in ways
that the altimeter setting should be used.
This is at least a misnomer, and probably a misconception
On 02/11/2007 01:42 PM, I wrote:
OK ... assuming by altitude they mean pressure altitude not true
altitude or absolute altitude or ...
Typo: I meant indicated altitude instead of pressure altitude.
Pressure altitude is something else yet again.
Sorry for any added confusion; this was a
Reference: Altimetry principles.
Lurid details including equations and derivations.
http://www.av8n.com/physics/altimetry.htm
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done
From
http://wiki.flightgear.org/flightgear_wiki/index.php?title=Bugs
1 Known Bugs
1.1 Incorrect altimetry.
1.2 Altimetry misnomers and misconceptions.
1.3 Z-buffer burn-through.
1.4 Memory leak.
1.5 Numerous bugs in ATIS feature.
1.6 Problems with --altitude option.
On 02/11/2007 11:29 PM, Dave Perry wrote:
By the way, I agree that the current algorithm in altimeter.cxx is
wrong. This evening, I had time to look at your posted patch and I
think it would give the right hi.
It is, for now, restricted to the troposphere (36000 feet and below).
Extending
Consider the following results of an experiment using fgfs:
alt: 662 mM: 0.0288 P: 99000.8462 T: 286.8563 rho: 1.1975
alt: 3462 mM: 0.0288 P: 89341.6721 T: 281.3920 rho: 1.1009
alt: 662 mM: 0.0289 P: 99000.8422 T: 256.9910 rho: 1.3404
alt: 3462 mM: 0.0289 P: 89341.6740
On 02/12/2007 07:24 PM, Dave Perry wrote:
This looks really slick,
:-)
... why is this patch good above the troposphere ( 100,000 ft.)? It
should give the same answer as the last patch, only much more
efficiently.
The tabulated numbers come from a three-layer model, namely
layers 0
On 02/13/2007 12:11 AM, Dave Perry wrote:
I can see how you generate a table that gives PA and C(s) for
layers with nonzero lapse rate. I assume you use equation (8) solved
for h to generate the table when lamda = 0.
Yes, equation 8, but I don't even need to solve for h.
That's the
On 02/10/2007 12:48 PM, John Denker wrote:
... other service volume issues.
The code has no understanding of how azimuth affects the
localizer.
I fixed this. There are now six localizer courses:
-- one front course
-- one back course (reverse sensing)
-- four false courses (two
On 02/13/2007 09:31 AM, Holger Wirtz wrote:
What I need is a simple number which should describe the
maximum range og a COM1. For example 5 km? oder 20 km???
As others have pointed out, the simple answer is line of sight.
See algorithms below.
COM1 in a Cessna is not as one of an Airbus.
On 02/15/2007 09:25 AM, Holger Wirtz wrote:
FG seems to have a built-in ATIS for KSFO 118.85 which overlaps with the
realtime voice communication. My question was actually how to tell FG
not to use its internaly ATIS.
A better solution would be to use 122.75 for air-to-air communications,
On 02/15/2007 04:55 PM, Alex Perry wrote:
More generally: It is always very important to distinguish between the facts
that arise from the
simulation of the planet (such as SLP and variation), and the facts that
arise from simulation of
the airspace (such as QNH and VOR alignment).
Yes.
On 02/12/2007 08:43 PM, Dave Perry wrote:
What I am proposing is to create a C++ function (say height_ft) that has
two arguments, P0 and P1 that does the interpolation in John's new patch
using his constants.
Then the kap140.nas could use that function, the encoder could use that
function
It appears that interest is coming from multiple directions,
interest in upgrading the audio overall, plus particular
interest in having usable ATIS audio. This is not unrelated
to the effort to handle non-ISA-standard-day weather conditions,
since if you're going to have a non-standard day, you
On 02/19/2007 07:40 PM, Dave wrote:
The ATIS as currently written *should* give usable altimeter and
visibility. Is this broken at the moment? If so, how and under what
circumstances?
The altimeter setting is incorrect in most circumstances
other than sea-level and/or ISA-standard-day
In the course of fixing up altimeter.cxx, I decided to
incorporate all of the features of encoder.cxx.
They were so similar in function that it didn't make
sense to maintain two of them.
In particular,
-- The basic altimeter is also an encoding altimeter.
If you don't want the encoding
On 02/22/2007 01:27 AM, John wrote:
Modern avionics and air data computers provide an instantaneous vertical
velocity and altimeter.
Yes.
Is there a property/variable in flightgear that does not contain the lag
present in simple baro systems?
Yes.
I'm under the impresssion that the
On 02/22/2007 08:32 AM, AJ MacLeod wrote:
On Thursday 22 February 2007 13:28, John Denker wrote:
Solving this problem is easy:
I'd say so too... for exact values rather which don't rely on modelled
instrumentation can't one just use the values provided under /position in
the property tree
On 02/25/2007 12:30 AM, Dave Perry wrote:
I have been communicating off and on with both John Denker and Roy
Vegard Ovesen off list concerning this topic. I am running an edit of
John's most recent altimetry patch and have modified kap140.nas,
altimeter.cxx, and altimeter.hxx so
There are two ideas that need to be kept separate.
a) The idea of an /class/ aka /object/, versus
b) the idea of an /instance/ of such a class.
As applied to altimetry:
a) Writing a single altimetry /object/ that can perform
either as a digital encoder *or* as an analog steam gauge
On 02/25/2007 12:49 PM, Roy Vegard Ovesen wrote:
I have to agree with Dave on this. The indicated altitude should _not_ be
quantized. The indicated altitude belongs to the altimeter part of the
class, and _not_ to the encoder part.
Parts? I didn't know the class has an altimeter part
On 02/25/2007 12:32 PM, Alex Perry wrote:
There are three types of altimeter in common use: (1) Air data computers,
which go to a lot of
trouble to report the instantaneous value.
Right.
Aircraft with such instruments should use the
environment value,
Is that a typo?
I don't know of
On 02/25/2007 02:39 PM, Roy Vegard Ovesen wrote:
I suggested an encoding altimeter as an instance that has both. Do you think
that makes sense?
Yes, that has been suggested. But what's the rationale?
It's not the craziest idea in the world... but I still
haven't heard an argument for it that
distinction,
and then sometimes within a few sentences they trample roughshod
over the distinction.
Not being clear in terminology and semantics was
one of your original complaints about the existing code.
Agreed.
On Sun, 2007-02-11 at 00:22 -0500, John Denker wrote:
While we're
On 02/25/2007 04:49 PM, Martin Spott wrote:
John, a significant part of introducing yourself to the list - the one
our readers will probably remember best - was you strongheaded
instisting of how to read VOR radials.
Well:
1) As you know, I changed my mind about how to report radials.
2)
I came up with an answer to my own challenge:
In the real world there are two types of encoding altimeters:
I) The so-called blind encoders are basically just encoders.
Their *only* output is digital and quantized. These can be
made non-blind by wiring them to a display, but the display
On 02/25/2007 06:36 PM, Alex Perry wrote:
There is no reason to have a long lag in the static system.
Interesting point, yes, you're right. On the modern instruments, anyway.
Maybe the old lag was
actually due to manufacturing tolerances and the like.
There are no relevant tolerances in
1 - 100 of 515 matches
Mail list logo
