2000-03-21 20:51:03 +00:00
|
|
|
// steam.hxx - Steam Gauge Indications
|
|
|
|
//
|
|
|
|
// Started by Alex Perry
|
|
|
|
//
|
|
|
|
// Copyright (C) 2000 Alexander Perry - alex.perry@ieee.org
|
|
|
|
//
|
|
|
|
// This program is free software; you can redistribute it and/or
|
|
|
|
// modify it under the terms of the GNU General Public License as
|
|
|
|
// published by the Free Software Foundation; either version 2 of the
|
|
|
|
// License, or (at your option) any later version.
|
|
|
|
//
|
|
|
|
// This program is distributed in the hope that it will be useful, but
|
|
|
|
// WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
|
|
|
// General Public License for more details.
|
|
|
|
//
|
|
|
|
// You should have received a copy of the GNU General Public License
|
|
|
|
// along with this program; if not, write to the Free Software
|
|
|
|
// Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
|
|
|
|
//
|
|
|
|
// $Id$
|
|
|
|
|
|
|
|
|
|
|
|
#ifndef FG_STEAM
|
|
|
|
#define FG_STEAM
|
|
|
|
|
|
|
|
|
|
|
|
#ifdef HAVE_CONFIG_H
|
|
|
|
# include <config.h>
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#include <simgear/compiler.h>
|
|
|
|
|
|
|
|
#include <time.h>
|
|
|
|
#include STL_STRING
|
|
|
|
|
2001-03-23 22:59:18 +00:00
|
|
|
SG_USING_NAMESPACE(std);
|
2000-03-21 20:51:03 +00:00
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* STEAM GAUGES
|
|
|
|
*
|
2001-06-05 22:10:25 +00:00
|
|
|
* This class is a mapping layer, which retrieves information from the
|
|
|
|
* property manager (which reports truthful and ideal values) and
|
|
|
|
* generates all the instrument errors and inaccuracies that pilots
|
|
|
|
* (err) love, of course. Please report any missing flaws (!).
|
2000-03-21 20:51:03 +00:00
|
|
|
*
|
|
|
|
* These should be used to operate cockpit instruments,
|
|
|
|
* and autopilot features where these are slaved thus.
|
|
|
|
* They should not be used for other simulation purposes.
|
|
|
|
*/
|
|
|
|
class FGSteam
|
|
|
|
{
|
|
|
|
public:
|
|
|
|
|
|
|
|
static void update ( int timesteps );
|
|
|
|
|
|
|
|
// Position
|
|
|
|
static double get_ALT_ft ();
|
2000-06-15 18:36:13 +00:00
|
|
|
static double get_TC_rad ();
|
2000-03-21 20:51:03 +00:00
|
|
|
static double get_MH_deg ();
|
|
|
|
static double get_DG_deg ();
|
2000-06-15 18:36:13 +00:00
|
|
|
static double get_DG_err ();
|
|
|
|
static void set_DG_err(double approx_magvar);
|
2000-03-21 20:51:03 +00:00
|
|
|
|
|
|
|
// Velocities
|
|
|
|
static double get_ASI_kias ();
|
2000-05-02 19:41:35 +00:00
|
|
|
static double get_TC_std ();
|
2000-03-21 20:51:03 +00:00
|
|
|
static double get_VSI_fps ();
|
|
|
|
|
2000-03-22 21:59:59 +00:00
|
|
|
// Engine Gauges
|
|
|
|
static double get_VACUUM_inhg ();
|
|
|
|
|
2001-01-23 07:17:47 +00:00
|
|
|
// Atmosphere
|
|
|
|
static double get_ALT_datum_mb ();
|
|
|
|
static void set_ALT_datum_mb(double datum_mb);
|
|
|
|
|
NAV1 is now the ILS-28R on airport KMYF,
NAV2 is now the VOR radial 068 from MZB,
ADF is now the Compass locator on the outer marker.
This combination is more than the legally required to
fly any of KMYF-ILS-28R, KMYF-LOC-28R KMYF-NDB28.
If you don't have access to the approach plates
and would like them, let me know and I'll scan them
(and put them on the webpage area).
The approaches do work; I've checked them all out in
terms of altitude profile, centerlines and other stuff.
In real life, the radar vectoring will basically abandon you
overhead KSEE airport at 4000 ft heading 210 or so. Sometime
later you'll be turned to a heading of 260 if the controller
doesn't have too much else to do, just before you hit the
extended centerline. You can't rely on that though.
Maintain 3500ft until established, 2100 ft until the outer marker,
If non-precision, maintain 1340 until crossing the radial,
then 900 thereafter until you miss, based on time from the NDB.
The miss takes you heading 270 to intercept a radial which this
hacky implementation will not let you set up the computer for.
The hacky math implementation does not take range and/or signal
strength into account, so you can fly to San Diego from England
by following the needle indication on the ADF. It is also
fairly inaccurate math; about as accurate as the real-life signals.
When we have a _real_ radio module, I will be very happy to
throw all that code away. For now, it makes it demonstratable.
Please notice the nastiness involving the "VARY_E" constant.
This is _not_ something that will go away with the radio module.
As far as I know, we don't have a routine that calculates
magnetic variation as a function of global position.
We will need one, probably within the next two months.
2000-03-26 16:52:36 +00:00
|
|
|
// Hacks ... temporary stuff
|
2001-02-25 04:45:26 +00:00
|
|
|
// static double get_HackVOR1_deg ();
|
NAV1 is now the ILS-28R on airport KMYF,
NAV2 is now the VOR radial 068 from MZB,
ADF is now the Compass locator on the outer marker.
This combination is more than the legally required to
fly any of KMYF-ILS-28R, KMYF-LOC-28R KMYF-NDB28.
If you don't have access to the approach plates
and would like them, let me know and I'll scan them
(and put them on the webpage area).
The approaches do work; I've checked them all out in
terms of altitude profile, centerlines and other stuff.
In real life, the radar vectoring will basically abandon you
overhead KSEE airport at 4000 ft heading 210 or so. Sometime
later you'll be turned to a heading of 260 if the controller
doesn't have too much else to do, just before you hit the
extended centerline. You can't rely on that though.
Maintain 3500ft until established, 2100 ft until the outer marker,
If non-precision, maintain 1340 until crossing the radial,
then 900 thereafter until you miss, based on time from the NDB.
The miss takes you heading 270 to intercept a radial which this
hacky implementation will not let you set up the computer for.
The hacky math implementation does not take range and/or signal
strength into account, so you can fly to San Diego from England
by following the needle indication on the ADF. It is also
fairly inaccurate math; about as accurate as the real-life signals.
When we have a _real_ radio module, I will be very happy to
throw all that code away. For now, it makes it demonstratable.
Please notice the nastiness involving the "VARY_E" constant.
This is _not_ something that will go away with the radio module.
As far as I know, we don't have a routine that calculates
magnetic variation as a function of global position.
We will need one, probably within the next two months.
2000-03-26 16:52:36 +00:00
|
|
|
static double get_HackOBS1_deg ();
|
2001-02-25 04:45:26 +00:00
|
|
|
// static double get_HackGS_deg ();
|
|
|
|
// static double get_HackVOR2_deg ();
|
NAV1 is now the ILS-28R on airport KMYF,
NAV2 is now the VOR radial 068 from MZB,
ADF is now the Compass locator on the outer marker.
This combination is more than the legally required to
fly any of KMYF-ILS-28R, KMYF-LOC-28R KMYF-NDB28.
If you don't have access to the approach plates
and would like them, let me know and I'll scan them
(and put them on the webpage area).
The approaches do work; I've checked them all out in
terms of altitude profile, centerlines and other stuff.
In real life, the radar vectoring will basically abandon you
overhead KSEE airport at 4000 ft heading 210 or so. Sometime
later you'll be turned to a heading of 260 if the controller
doesn't have too much else to do, just before you hit the
extended centerline. You can't rely on that though.
Maintain 3500ft until established, 2100 ft until the outer marker,
If non-precision, maintain 1340 until crossing the radial,
then 900 thereafter until you miss, based on time from the NDB.
The miss takes you heading 270 to intercept a radial which this
hacky implementation will not let you set up the computer for.
The hacky math implementation does not take range and/or signal
strength into account, so you can fly to San Diego from England
by following the needle indication on the ADF. It is also
fairly inaccurate math; about as accurate as the real-life signals.
When we have a _real_ radio module, I will be very happy to
throw all that code away. For now, it makes it demonstratable.
Please notice the nastiness involving the "VARY_E" constant.
This is _not_ something that will go away with the radio module.
As far as I know, we don't have a routine that calculates
magnetic variation as a function of global position.
We will need one, probably within the next two months.
2000-03-26 16:52:36 +00:00
|
|
|
static double get_HackOBS2_deg ();
|
|
|
|
static double get_HackADF_deg ();
|
|
|
|
|
|
|
|
|
2000-03-21 20:51:03 +00:00
|
|
|
private:
|
2000-03-22 21:59:59 +00:00
|
|
|
static double the_ALT_ft;
|
2001-01-23 07:17:47 +00:00
|
|
|
static double the_ALT_datum_mb;
|
2000-05-02 19:41:35 +00:00
|
|
|
static double the_TC_rad, the_TC_std;
|
2000-03-22 21:59:59 +00:00
|
|
|
static double the_STATIC_inhg, the_VACUUM_inhg;
|
2000-03-21 20:51:03 +00:00
|
|
|
static double the_VSI_fps, the_VSI_case;
|
2000-05-02 19:41:35 +00:00
|
|
|
static double the_MH_deg, the_MH_degps, the_MH_err;
|
2000-06-15 18:36:13 +00:00
|
|
|
static double the_DG_deg, the_DG_degps, the_DG_inhg, the_DG_err;
|
2000-03-21 20:51:03 +00:00
|
|
|
|
|
|
|
static int _UpdatesPending;
|
|
|
|
static void _CatchUp ();
|
|
|
|
|
|
|
|
static void set_lowpass ( double *outthe,
|
|
|
|
double inthe, double tc );
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
|
#endif // FG_STEAM
|