The glideslope station was only searched once whenever the NAV station
changed. However, sometimes a mismatching G/S station is found, since
another G/S station is still closer when the NAV station changes.
When this happened, the G/S station was never updated again (while the
NAV station stayed in range), resulting in the NAV receiver providing
correct localizer, but bad G/S data (data matching another, remote station).
Issue is fixed by alternating between searching NAV and G/S stations.
This property is true if the active frequency is tuned to a
paired LOC/GS frequency in the range 108.00 - 111.95 with a
odd 100kHz digit (108.10, 108.15, 108.30, 108.35 ...)
It only indicates, that this _is_ a LOC/GS frequency,
it does _not_ provide any indication if a LOC/GS station is
actually being received.
- wrap the ident-generating code into a class
- move dme-in-range property into dme.cxx
- move dme-ident generation into dme.cxx
- support ident-button and volume for dme idents
- use globals.get_aircraft_position instead of properties
- some minor cleanup
Allow switching off slaved-to-gps (resynch NAV radio/update all NAV outputs)
Allow tuning NAV stations and keep DME alive when slaved to GPS
Clear station ID and heading when loosing NAV signal
Uninitialized variables were sources for NaN values.
Once NaNs are passed to Nasal (through (tied) properties), these cause
a crash. Nasal cannot handle NaNs - it interprets these as pointer values...
* When the nav-radio is slaved, calculated radial/target-hdg-deg
(needed by some autopilot logic)
* Handle editing (including deletion) of route waypoints correctly,
including deleting the active waypoint
* Add a signal to the route manager when the last wpt is reached, and
use it in the GPS to revert to OBS mode.
* Change the altitude handling to use the specified cruise altitude
* Fix a bug where autopilot/locks/altitude was treated as a boolean
- false LOC courses and GS lobes
- LOC sensitivity based on runway dimensions
- GS cutoff based on range
- More accurate GS deviation computation, making final approach more stable
Here is a little patch that changes the behaviour of the VOR CDI and OFF-flag
for indicators like the HSI when getting outside the range of the VOR
station.
Currently, when flying at a distance between the effective_range and twice the
effective_range of a VOR station, the in-range property is computed based on
a random value, causing the OFF Flag and the CDI bar to perform an ugly
jitter.
The attached patch introduces a new property signal-quality-norm which is
computed based on the distance to the station and the range. It is 1.0 when
the distance is less than the range and decreases by 1/x^2 for distances
greater than the range leading to a signal-quality-norm of 0.25 for distances
two times the range, 0.125 for three times the range and so on.
The in-range flag is tied to a signal-quality-norm greater than 0.2 (fixed
squelch).
The CDI and GS needle deflection is multiplied with the signal-quality-norm.
The benefit is:
- Ability to animate the OFF-Flag with a smooth transition.
- CDI and GS needle deflection shows correct values when in range
(signal-quality-norm=1.0) and show some wrong indication when the range is
exceeded
- CDI and GS needle start to move, even when the OFF flag is visible
- No more jitter for flag and needles
See the new SenecaII ki525a hsi as an example at
http://www.t3r.de/fg/navpatch.jpg
The numbers on the image are:
(1) the new property signal-quality-norm
(2) distance exceeds the effective-range by 30%
(3) NAV flag has a rotation animation bound to signal-quality-norm and is
partially visible
(4) CDI is partially deflected even with NAV flag shown
This implementation better matches reality - at least, how I observed it ;-)
SGPropertyNode to guarded ones. This is also done for JSBSim/JSBSim.hxx,
for which JSB had given explicit permission a while ago. I postponed that
back then, but now is the time.
anything in the nav tree is valid or not.
- Fix an order problem between caching data values and searching for a new
station that could cause odd and unexpected and hard to reproduce results.
Added a convenience function to estimate the time to intercept the selected
radial give the current heading and speed. This can be useful to a flight
directory to compute the point to switch from armed to coupled mode at just
the right time so the pilot can roll out onto the desired heading on the
desired radial.
Add a first whack at estimating a ground track heading error (difference
between aircraft heading and ground track directon.) This needs more work
and testing.
