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
> f
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 us
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 tolerance
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 v
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 bypa
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 altitu
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 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)
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: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
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, obscu
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
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 tha
On Sunday 25 February 2007 06:30, Dave Perry wrote:
> I want both John and Roy to try this patch before we consider submitting
> it to cvs. Of course, anyone can try it and comment.
I had a nice flight over Norway today from ENHD to ENTO. ATIS at ENHD told med
that baro setting should be 29.50.
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 instan
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 kno
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 Sunday 25 February 2007 06:30, Dave Perry wrote:
>
> I want both John and Roy to try this patch before we consider submitting
> it to cvs. Of course, anyone can try it and comment. Is the encoder
> used anywhere other than by the KAP140? If so, we should use a separate
> instantiation as sugg
On Sunday 25 February 2007 17:49, John Denker wrote:
> On 02/25/2007 08:39 AM, Dave Perry wrote:
> >>> I also rearranged the truncation of pressure altitude in John's code so
> >>> the indicated altitude is computed before the pressure altitude is
> >>> rounded and saved. John, you may have alread
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?
> Clo
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"
* 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
* 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
SimGear/simgear/
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)
> > >
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 (http://williams.best.vwh.
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 modi
26 matches
Mail list logo
