#2004 Route Manager sets incorrect course to dest A/P in GPS slaved mode

[Huntley Palmer]

This is seen on b1900d in A/P Nav mode when GPS panel ( to right of A/P selector panel ) is active, causing NAV1 input to be slaved to GPS.

e.g. Select --airport=KBOS --runway=14 Open F10-Autopilot-Route Manager, select Defaull SID for KBOS
Select Destination A/P KOWD ( Norwood, nearby with no SID/STARS ), Activate Route list shows:
KBOS 14, 14-3, 14-6, Dep-3, KOWD Runway 35
After takeoff, engaing A/P , plane correctly follows headings to 14-3, 14-6, Dep-3
But, for final heading to KOWD, which is at Hdg approx 270, plane follows Hdg 350 incorrectly. This heading, 350, is the destination's R35 runway orientation, not the hdg to the destinatin A/P.
Inspect property /instrumentation/gps/wp/wp[1]/desured-course-deg; it shows ~350 deg on this final leg, for the
previous legs the property shows the proper heading to next waypoint.
Thanks

[James Turner]

Ah, this is a problem indeed. The GPS assumes the inbound course for runway-waypoints is always the runway heading, i.e that you insert at least one approach point somewhere along the the approximate runway center-line. Otherwise the AP would effectively try to fly to the runway threshold at 270-deg course, and then start a turn to the runway heading, which would not work well.

I'm not sure what the correct behaviour should be here, basically. Suggestions?

[Huntley Palmer]

Hi, thanks for looking at this. I wrote up the ticket after helping someone with the Beech; agreed it's a somewhat improper demand on the RM but it happened.
You're saying, for proper operation, the penultimate WP must be on the runway's reciprocal bearing from the final WP at the threshold. With that condition met there is no need to force the A/P to fly the runway's heading from the penultimate WP because the heading to the last WP will be the runway's heading.
Force the A/P heading to the Rwy orientation only at the last WP, on the threshold ? If approach WP's, in line with the Rwy, have been properly set as required then the behaviour won't change. In the reported case the user will see the A/P properly reach the target airport and likely then do some wild manouvers. This seems to be a better hint that extra WP's are needed on the target's approach path rather than the A/P sending the plane away from the desired destination while miles away from there.
Thanks again !

[James Turner]

Well I'm discussing on the developer list, if we can do something smarter, but yeah I think this expected / normal case is there is at least one approach WP on the extended runway centerline, at some plausible distance (5 or 2 or 0.5nm) out from the threshold.

[legoboyvdlp]

This is the infamous issue discussed privately :)

[James Turner]

Yep, I'll fix it, it's on my list :D

[legoboyvdlp]

Bumped to 2020.4 milestone :-)