On 08/15/2008 06:53 PM, James Turner wrote:
> If you could enumerate the issues here, in a new thread, that'd be
> interesting.
Here's a start:
*) There should be false localizer courses abeam the antenna, as
there are in real life. This is implemented in the _Sport Model_
in navradio.cxx
*) There should be false glideslopes above the true glideslope, as
there are in real life. This should be straightforward to implement
in analogy to the localizer.
*) The code in navradio.cxx assumes the gs service volume is the same
as the LOC service volume, which is not correct.
*) The "intermittency" feature in navradio.cxx (near the edge of the
service volume) is a cute idea, and might look OK if only the flag were
fluctuating, but it is not at all realistic to have the needle fluctuating
at frame rate. Real-world needles have a strong low-pass filter in them.
*) In the real world, some localizers have an _expanded_ service volume.
The code needs to respect the range info in the database, rather than
relying on some compiled-in assumption. The _Sport Model_ handles this
correctly.
*) The "has_dme" code in navradio.cxx needs to find a DME if and only if
it is paired with the azimuth navaid (LOC or VOR). Right now it unwisely
accepts any DME on the frequency, even if it is thousands of miles away.
*) And it should check to see whether the DME receiver is tuned to the
appropriate DME frequency before playing the ident. Right now it
plays the DME ident without checking to see whether there is a DME
receiver on board, let alone checking its tuning, let alone checking
the audio volume or the routing through the audio panel.
NOTE: There is a tricky issue here, having to do with synchronizing
the audio for two almost-independent instruments:
-- In the aircraft, the DME receiver is independent of the azimuth
receiver ... except that sometimes the DME is remotely tuned by the
azimuth receiver.
-- Similarly, on the ground, the DME station is independent of the
azimuth station ... except that the audio ident is synchronized.
I don't see a reasonable way to put the synchronized audio feature into
navradio.cxx or into dme.cxx. Possibly constructive suggestion: create
a new module (azimuth_dme_shared_ident.cxx or some such) ... and let it
play traffic cop between navradio.cxx and dme.cxx. This looks like a
classic "multiple inheritance" situation.
Tangential remark: In the real world, this synchronization is not
handled in the aircraft at all; it is implemented in the ground station.
One could imagine, in the long run, moving some of these tricky
features out of the aircraft ... doing them on a per-station basis
rather than on a per-aircraft basis. Obvious candidates for this
include
-- local weather
-- choice of active runway
-- ATIS
-- synchronized ident
++ This has tremendous advantages in multiplayer situations, where you
would like all players to get a consistent view of the world.
++ But even in single-player situations, it is common for aircraft to have
more than one radio, and if you tune up ATIS on two (or three or four)
receivers you should hear the /same/ ATIS. This is another strong
argument for why ATIS should not be synthesized on-the-fly within the
radio. There is code in the _Sport Model_ to achieve consistency for
multi-radio ATIS.
*) Why does marker_beacon.cxx go to a lot of trouble to calculate term_tbl,
low_tbl, and high_tbl ... which are then never used?
*) The marker beacons need a high/low sensitivity switch.
*) The service-volume code in marker_beacon.cxx is not a paragon of clarity,
and produces results that seem unrealistic.
*) Remember, this is not a complete list.
> I don't know what the 'Sport Model' is, can you elaborate?
A summary of _Sport Model_ features can be found here:
http://www.av8n.com/fly/fgfs/README.sport.model
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
