Heading bug vs Course knob

[dancemad2]

Why when navigating on a VOR radial with AP, does adjusting the heading bug act like I am dialing the Course knob......?? This is using P3D v4 with the compatible A2A trainer, but also did this in P3d v3 with the compatible A2A trainer.

[flaminghotsauce]

Should be right if you're using the heading setting on the autopilot.

[Nick - A2A]

Hello Michael,

Sounds like you're encountering the more realistic autopilot simulation which the A2A guys have created. Unlike the default FSX AP, the real KAP 140 (and the A2A version of it) doesn't actually know the aircraft's current heading. Instead, the position of the heading bug allows it to work this out. Basically, the AP receives a signal telling it the error between the heading bug position and the current heading, not the heading itself. However, it's up to you to set the heading bug correctly.

You can read a fuller description by Esa ('AKar') here.

Cheers,
Nick

[AKar]

And just to add a couple of words, in principle the heading bug information is not needed for the tracking function (AP has no way of knowing its track-over-ground anyway). An example of such system that doesn't use it at all for tracking is the S-TEC System 30, used in A2A Pipers. The primary function of setting the bug in KAP 140 is because this autopilot is able to intercept and establish itself automatically. For this, it needs the desired track information to limit the intercept angle.

I am actually not sure how a real-life KAP 140 in this kind of configuration would behave if I was perfectly established on some radial (or GPS source) under NAV tracking, and then one rotated the heading bug progressively over. I'd presume a small change would do nothing, but at some point the system could get confused.

(I need to alter the Dropbox links in the post Nick linked into due to their recent change.)

-Esa

[Nick - A2A]

And just to add a couple of words, in principle the heading bug information is not needed for the tracking function (AP has no way of knowing its track-over-ground anyway). [...]

I am actually not sure how a real-life KAP 140 in this kind of configuration would behave if I was perfectly established on some radial (or GPS source) under NAV tracking, and then one rotated the heading bug progressively over. I'd presume a small change would do nothing, but at some point the system could get confused.

That's an interesting point Esa. At any rate, the algorithm in the A2A version will initially turn towards the heading bug in this situation. Even though it knows the CDI is still centered, I guess its little electronic mind 'thinks' the aircraft is turning so attempts to correct this, even before the CDI begins to move.

Nick

[AKar]

It should still be rate-based, so no first order turn command should come up due to heading bug swing, as the NAV error remains at almost nil, and the turn rate likewise.

This kind of a test would be very interesting to do with actual unit indeed, as it would give an insight in how it thinks, so to say.

Actually, I'll get back in to this.

-Esa

[dancemad2]

But shouldn't I be able to set up a heading on the heading bug knob prior to switching from Nav1 to Heading without affecting the current Vloc?

[Nick - A2A]

It should still be rate-based [...]

Yup - good point. Perhaps moving the heading bug triggers some sort of intercept routine in the sim version in that case, even if there's already no cross-track error and the turn rate is nil. Afraid my knowledge of PID algorithms falls a bit short here!

But shouldn't I be able to set up a heading on the heading bug knob prior to switching from Nav1 to Heading without affecting the current Vloc?

That, it seems, is the $64,000 question!

Nick

[AKar]

Yup - good point. Perhaps moving the heading bug triggers some sort of intercept routine in the sim version in that case, even if there's already no cross-track error and the turn rate is nil. Afraid my knowledge of PID algorithms falls a bit short here!

The specs list something they call "VOR Crosswind Compensation - Up to 30° right or left." This could be significant (or not).

There are a couple of points to understand here (not solely from technical interest but to pilots as well). First is that what I already mentioned: the heading generally does not match the present track. Any amount of crosswind component makes up the easiest and most important explanation. Second is that...well, in reality there is no D-key. The heading bug is only as good a reference as it is. And third, even if we assumed a perfect heading setup, it won't generally match the tracks of the VOR radials.

For the autopilot, it is totally insignificant which one or combination of previous causes the heading-to-fly the track to be offset from the actual track.

Flying a track is not a heading thing, but track error and error rate thing - this is what makes the autopilot generally much better tracker than a pilot flying on instruments: the autopilot is sensitive to "beam rate" (if speaking of VOR world), or the rate-of-change of the track error whereas it is extremely difficult for a human to monitor. Autopilot corrects immediately when it sees the needle to start moving away, whereas pilot typically only corrects when there already is a small error, and then in a non-exact, "let's try this change" kind of way.

This difference is so fundamental that it appears to be rather difficult to get an autopilot simulation "right". A common fallacy introduced by many FSX/P3D autopilots shows up like this: Allow for gyro drift in realism settings. Now, make the autopilot to follow a long-enough GPS route segment. Now as you see the DG slowly getting off the proper alignment due to gyro drift, the airplane will track proportionally offset from the actual track! As the DG gets more off, so does the airplane - perfectly tracking somewhat laterally offset from the magenta. This is clearly wrong. (I don't remember if A2A Cessnas showed this behavior, but at least RealAirs did.)

To underline, the accuracy of the heading bug position is not significant for the autopilot to track properly!

While I lack good data on the system (and a chance of trying this right away in real airplane), what I think is going on is that the 30° heading bug offset while the needle is not outside some limits is internally considered a limiting value in between tracking function and intercept function.


Let us make up a test scenario: an airplane tracking, say, VOR inbound, and being well established and the heading bug at the inbound course. Now, slowly start moving the heading bug off the nose either way, let us say right in this case.

So, my best guess (based on nothing! ) would be that the actual behavior ought to be something like this:

• - at first, nothing happens;
  - when you reach 30° off-the-nose with the bug, the airplane would probably follow the bug when turning it further off, but flying 30° left of it, that is, 30° to the beam's direction from the bug.

That's my bet, I hope to test this with the actual unit, or if someone's able, please do. Of course, the software versions may differ in behavior.

-Esa

[AKar]

But shouldn't I be able to set up a heading on the heading bug knob prior to switching from Nav1 to Heading without affecting the current Vloc?

By design, no. It is assumed that the bug remains at the track or thereabouts. The only "proper" way to preset the heading bug is to switch to the ROL mode before moving the bug. One may get away with small changes however while moving the bug in NAV, depending if I'm correct on the above, but that's not intended way to do it.

-Esa

[mallcott]

It may help to think of the heading bug as a `course-to-intercept` bug when in any NAV mode - and that intercept course should be within 30 degrees of the eventual NAV intercept.

It's function as a HDG `instruction` only really works in HDG mode, even though it appears to do the same job in NAV mode.

Effectively, remain in HDG mode until the localiser bar becomes active, and plot an intercept course that will bring you out at an angle of 30 degrees or less to the eventual intercept course, using the hdg bug.

So if planning to intercept a VOR on a course of say, 180° and you are approaching from a right-angled heading of 270° under a/p control requiring a 90° turn to starboard to acquire the localiser or VOR the heading bug will need to be turned progressively from 270° to <210° for the intercept to work, with 210 being the minimum setting before activating the NAV function, preferably with an off-track that is less than a full needle deflection.

The `modern` alternative is to fly the whole thing under GPS control, when the adjustment can all be managed by the a/p itself - which can be useful as a training aid to learn how far offtrack you need to start making that turn as it will show you how it intercepts from a wide angle, changing from a standard rate turn to one that optimises the smoothness of the NAV intercept.

[Nick - A2A]

Thanks for the added musing above Esa.

The specs list something they call "VOR Crosswind Compensation - Up to 30° right or left." This could be significant (or not).

This bit made me think, and I wonder if it's the autopilot's capability in HDG mode once NAV is armed to work out and fly a 45° intercept which is significant. At any rate, in the brief test I did in P3D earlier, if the HDG bug is rotated off-course (say left) by more than 45° once we're tracking the radial in NAV mode, then it seems we'll end up flying a course 45° right of the bug. For instance, if our radial is 90° and we spin the bug to 30° for some inexplicable reason, the resultant course will be 75° and obviously we'll no longer be tracking our radial. However, if the bug is rotated off course by less than 45°, the autopilot will eventually regain the correct course after its turn towards the bug, but it'll no longer be able to re-intercept the radial with any accuracy because it doesn't know exactly what heading to fly anymore.

In other words, it seems the AP algorithm always needs to know the heading (from the bug) as well as the turn rate and CDI deviation. In fact, I guess it's possible that interacting with the heading bug (even just turning it by 1°) actually triggers a bit of code which starts the 45° intercept routine, rather than the bug simply providing a 'voltage' to the autopilot's brain like the real thing (if I understand it correctly).

Perhaps this is a bit of a trivial debate, but it does help to give an idea of how these things 'think' doesn't it?

[...] and that intercept course should be within 30 degrees of the eventual NAV intercept.

Well - given the 45° intercept capability of the KAP 140 in HDG mode, this is not really the case. If fact, given sufficient room, the autopilot will happily begin its 45° intercept routine even if you're flying perpendicularly towards the radial you want to intercept when you arm NAV mode. Admittedly you do need to make sure there's more distance between you and the station than between you and the radial in order for it to complete this process. I'd certainly agree that any intercepts close to the station (let's say a localizer) should ideally be performed with the minimum intercept angle possible.

Cheers,
Nick

[mallcott]

Thanks for the added musing above Esa.

The specs list something they call "VOR Crosswind Compensation - Up to 30° right or left." This could be significant (or not).

This bit made me think, and I wonder if it's the autopilot's capability in HDG mode once NAV is armed to work out and fly a 45° intercept which is significant. At any rate, in the brief test I did in P3D earlier, if the HDG bug is rotated off-course (say left) by more than 45° once we're tracking the radial in NAV mode, then it seems we'll end up flying a course 45° right of the bug. For instance, if our radial is 90° and we spin the bug to 30° for some inexplicable reason, the resultant course will be 75° and obviously we'll no longer be tracking our radial. However, if the bug is rotated off course by less than 45°, the autopilot will eventually regain the correct course after its turn towards the bug, but it'll no longer be able to re-intercept the radial with any accuracy because it doesn't know exactly what heading to fly anymore.

In other words, it seems the AP algorithm always needs to know the heading (from the bug) as well as the turn rate and CDI deviation. In fact, I guess it's possible that interacting with the heading bug (even just turning it by 1°) actually triggers a bit of code which starts the 45° intercept routine, rather than the bug simply providing a 'voltage' to the autopilot's brain like the real thing (if I understand it correctly).

Perhaps this is a bit of a trivial debate, but it does help to give an idea of how these things 'think' doesn't it?

[...] and that intercept course should be within 30 degrees of the eventual NAV intercept.

Well - given the 45° intercept capability of the KAP 140 in HDG mode, this is not really the case. If fact, given sufficient room, the autopilot will happily begin its 45° intercept routine even if you're flying perpendicularly towards the radial you want to intercept when you arm NAV mode. Admittedly you do need to make sure there's more distance between you and the station than between you and the radial in order for it to complete this process. I'd certainly agree that any intercepts close to the station (let's say a localizer) should ideally be performed with the minimum intercept angle possible.

Cheers,
Nick

As in the real world, what is claimed as 45° is better thought of as 30°, as anyone who has ever used a KAP 140 outside of a simulated environment will tell you. I always regard the A2A version as being true-to-life, not just in keeping with the manual.

[Nick - A2A]

As in the real world, what is claimed as 45° is better thought of as 30°, as anyone who has ever used a KAP 140 outside of a simulated environment will tell you. I always regard the A2A version as being true-to-life, not just in keeping with the manual.

Well, in this case perhaps it's better-than-life™ then. The fact remains that if you do arm the NAV intercept in HDG mode at a 30° angle to the radial course, the autopilot will just increase the intercept angle to 45° anyway. Does the real unit act differently in this respect?

I appreciate that in ROL mode, the KAP 140 should maintain whatever intercept course you're already flying until it determines it's actually time to turn onto the radial.

Nick

[mallcott]

As in the real world, what is claimed as 45° is better thought of as 30°, as anyone who has ever used a KAP 140 outside of a simulated environment will tell you. I always regard the A2A version as being true-to-life, not just in keeping with the manual.

Well, in this case perhaps it's better-than-life™ then. The fact remains that if you do arm the NAV intercept in HDG mode at a 30° angle to the radial course, the autopilot will just increase the intercept angle to 45° anyway. Does the real unit act differently in this respect?

I appreciate that in ROL mode, the KAP 140 should maintain whatever intercept course you're already flying until it determines it's actually time to turn onto the radial.

Nick

It shouldn't do that if the other criterion are met - namely, localiser bar alive, and moving and the prevailing conditions not causing the aircraft to over-correct. If you want to fly an intercept from further out, then HDG or ROL mode is the way to do it, switching to NAV/APPR mode only when the criterion are met, should do fine.

I will check it out on my own system later, but I don't recall having issues with it increasing the angle of intercept on mine, but then I tend to fly onto the radial or localiser by hand most of the time.

The KAP 140 was less `surgical strike` than `carpet bombing` - good in its day but seriously lacking precision in comparison with what we fly now.

It was also known for doing strange things of its own volition with notable variations in HDG mode, so perhaps A2A are simulating this, too..?!