Melchior wrote:
>
> * Dave Perry -- Saturday 24 March 2007:
> > Does anyone know what happened to John Denker?
>
> My way or the highway?
>
>
>
> > I am still interested in the improved altimeter/atmosphere
> model being
> > added to FlightGear.
>
> So am I. I had just done code review an
On Saturday 24 March 2007 04:01, Dave Perry wrote:
> Hi all,
>
> Does anyone know what happened to John Denker? I am still interested in
> the improved altimeter/atmosphere model being added to FlightGear. I
> keep adding these back in after cvs/svn updates.
I think we should ask someone to add
* Dave Perry -- Saturday 24 March 2007:
> Does anyone know what happened to John Denker?
My way or the highway?
> I am still interested in the improved altimeter/atmosphere
> model being added to FlightGear.
So am I. I had just done code review and pointed out why *I*
didn't consider the patch
Hi all,
Does anyone know what happened to John Denker? I am still interested in
the improved altimeter/atmosphere model being added to FlightGear. I
keep adding these back in after cvs/svn updates.
Dave perry
-
Take Surve
On Tue, 2007-02-27 at 19:07 -0700, Dave Perry wrote:
Sorry,
I copied from the wrong version. I will add the missing line and delete
a declaration:
> Here is an obvious fix for this bug in the update code:
>
> void
> Altimeter::update (double dt)
> {
> if (_serviceable_node->getBoolValue())
On Mon, 2007-02-26 at 11:37 -0500, John Denker wrote:
> Hi --
>
> I made an /object/ to calculate the Kollsman shift.
>
>
> # Calculate Kollsman shift/ft versus setting/inHg
> # Computationally efficient if, for any given instance
> # of this class, the setting is not being changed often.
> # Ty
Hi --
I made an /object/ to calculate the Kollsman shift.
# Calculate Kollsman shift/ft versus setting/inHg
# Computationally efficient if, for any given instance
# of this class, the setting is not being changed often.
# Typical usage:
# kxx = atmo.Kollsman.new();
# kyy = atmo.Kollsman.new();
On Mon, 2007-02-26 at 04:57 -0500, John Denker wrote:
> Here is the nasal code to calculate the Kollsman shift.
>
> # Typical usage: indicated_altitude = pressure_altitude -
> kollsman(baro_setting)
>k_ft = k_set = nil;
>kollsman = func{
> if (arg[0] == k_set) {return k_ft}
> k
Here is the nasal code to calculate the Kollsman shift.
# Typical usage: indicated_altitude = pressure_altitude -
kollsman(baro_setting)
k_ft = k_set = nil;
kollsman = func{
if (arg[0] == k_set) {return k_ft}
k_set = arg[0];
k_ft = 145442.156 * (1 - math.exp(math.ln(k_set/29
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 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
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)
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: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
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 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)
> > >
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
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 that the
Hi All,
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 that the altitude capture in the
kap140 is using th
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 fun
30 matches
Mail list logo
