On Sun, 2007-02-25 at 01:55 -0500, John Denker wrote:
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
I noticed today that functions calc_gc_course_dist() and calc_gc_lon_lat()
in simgear/math/polar3d.cxx wrongly assume that positive longitude
values are in the West, and negative in the East.
Apparently the functions were copied/adapted from the Aviation Formulary
site
On Sun, 2007-02-25 at 06:39 -0700, Dave Perry wrote:
On Sun, 2007-02-25 at 01:55 -0500, John Denker wrote:
On 02/25/2007 12:30 AM, Dave Perry wrote:
The altitude capture in the current cvs kap140.nas used
altFt = pressureAltitude + hpartial * (baroSetting - 29.92)
and
* Melchior FRANZ -- Sunday 25 February 2007:
Apparently, all users of the functions throughout sg and fg (and
there are quite some) hacked around this oddness, [...]
And the winners are ...
SimGear/simgear/environment/visual_enviro.cxx
SimGear/simgear/route/waypoint.cxx
* Melchior FRANZ -- Sunday 25 February 2007:
After looking into those files, it looks less dramatic. These
would be the only ones to fix:
SimGear/simgear/route/waypoint.cxx
SimGear/simgear/scene/sky/cloudfield.cxx
SimGear/simgear/scene/sky/cloud.cxx
FlightGear/src/ATC/approach.cxx
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
From: John Denker [EMAIL PROTECTED] I'm under the impresssion that the
property called environment/pressure-inhg[0] has a lag computed into
the final value. Is that correct or is that the instantaneous
value or pressure level the aircraft is at and what I'm looking for?
Close.
The
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 Sunday 25 February 2007 19:44, John Denker wrote:
Parts? I didn't know the class has an altimeter part separate
from the encoder part. The class can be /configured/ to be one
or the other. It cannot and should not be configured to be both.
I suggested an encoding altimeter as an instance
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
John,
I want to go back to the beginning of our discussion that led to a new
atmos.cxx and altimeter.cxx. My reason for wanting this code to read
the baro setting from the property tree and return to the tree the baro
offset is to make sure it is clear that these are different than the
altimeter
May I add just a short reminder to this discussion This does not
belong _directly_ to this topic, still I hope it might bring this
discussion with its feet back to the ground.
John Denker wrote:
I'm a real-world kind of guy.
[...]
Unrealistic features that increase the complexity,
On 02/25/2007 04:36 PM, Dave Perry wrote:
I want to go back to the beginning of our discussion that led to a new
atmos.cxx and altimeter.cxx. My reason for wanting this code to read
the baro setting from the property tree and return to the tree the baro
offset is to make sure it is clear
Ron Jensen wrote:
This looks right to me, I'd commit it if I had cvs access...
Someone with write access to the source directory should do that,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
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 Sun, 2007-02-25 at 15:14 -0500, John Denker wrote:
On 02/25/2007 02:39 PM, Roy Vegard Ovesen wrote:
I have not, and I don't think Dave Perry has either, expressed optinions to
indicate that the pressure altitude should not be quantized. What we have
said is that indicated altitude
From: John Denker
I don't know of any environment variable relevant to altitude
other than /environment/pressure-inhg. Using that bypasses the
lag associated with the /systems/static/pressure-inhg which
seems like a small and unimportant part of the overall air-data
task. It also bypasses
On Sun, 2007-02-25 at 16:19 -0700, Dave Perry wrote:
What is contested is how to model the baro shift. What you suggest is
retrieve the indicated altitude and then subtract the PA to get the
encoder baro shift and then add back in the PA. This means the
kap140.nas has to retrieve the value
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
On 02/25/2007 07:06 PM, Dave Perry wrote:
Summary proposed compromise:
1) Use an encoder instantiation (altimeter[1]) with quantum = 10 as well
as altimeter[0] with quantum = 0.
Yes, that seems entirely reasonable.
2) Leave the 5 new lines to allow unambiguous service to autopilot use
of
On 2/12 Dave Perry wrote:
It occurred to me that we should use John's interpolation function in
several other places:
1. We use a form of this function in kap140.nas without the efficiency
of the interpolation.
2. The encoder uses a similar interpolation that a general form of
this
23 matches
Mail list logo
