Route Manager sets incorrect course to dest A/P in GPS slaved mode
We use the localiser position to prepare a list of matching frequencies sorted by localiser's distance to aeroplane, with closest first. In the special case of a paired runway, one with the same frequency at opposite ends, the facing-side bearing test is done from the runway threshold ( causing the AP/ILS kick ) rather than from the localisers position. For paired runways with same frequency ILS at opposite ends, the suggested fix stops the AP/ILS pids from going 'berserk' over the threshold. In...
I see that losing back-course signal to non-paired LOCs is not a good idea and is too much to pay for getting an incorrect localiser at specific airport(s). The fix for location of bearing fix may still have merit. Presently the localiser signal may abruptly go incorrect on passing the threshold. This would likely affect autopilot. Having the switchover point based on the VOR's location makes the plane far more likely to be on the ground and AP/'ILS' inactive. Tks
Suggest fix for navidUsable() for KJFK and other ILS problems
Please Ignore This is likely due to not keeping fgdata in sync.
The immersive scenery improvement at KBOS is great. It exposes a need for a way of selectively filtering objects for adjusting frame rate and spacing. Tks!
That title's as bad as saying Mozart wrote too many notes, I'll re-phrase