OK, I think I got now, the blindfold example was very good. Indeed, the autopilot has to orient itself with the course pointer initially until the course deviation error starts to factor in and take over. With enough time, it probably would have managed to put me on the ILS even with the course pointer 30° off but that’s not a test I felt like doing in solid IMC 
HDG Datum is the heading error signal. CRS Datum is the Course error signal.
The interesting thing, having looked at the KFC225 properly this time, is that it doesn’t see the CP setting directly. It just gets an analog left/right turn signal from the HSI:
So the resolution between the instantaneous aircraft heading and the CP setting is done in the HSI (or whatever you have; an EHSI etc).
Some autopilots use the heading bug for this instead of the course setting. But maybe that’s only old stuff like the Piper Autocontrol?This happens when you don’t have an HSI: the AP takes the localiser error from the CDI (which doesn’t know about current heading, so it can’t output a course error signal) and uses the heading error from the DGI instead of a course error.
For an autopilot that has intercept and tracking capability, it has absolutely no way of knowing what the approach course is. In general, the only way that the autopilot knows what the no wind course is, is based solely on the HSI/EHSI/PFD course pointer. Put yourself in the position of the autopilot by placing a blindfold on. If you don’t have a friend (the course pointer) turn you towards the course to align you with the course, a voice command to turn left or right will not work. If you are misaligned with the final approach course by 10 degrees or so, the autopilot will try to fly the initial incorrect heading to hold the course, but will be able to overcome the apparent but not real strong winds and get you back to being on course. Don’t expect it to overcome 30 or more.
The ARINC 429 digital labels for the localizer and GS just replace the left/right and up/down analog signals with a digital version and do not have any directional content to them. Always make sure the course pointer is aligned with the course, or don’t expect it to work. You couldn’t do it either if you were blindfolded.
I don’t think I have ever let an autopilot or external Nav box set an inbound course of an approach I am going to track raw data. This was beaten into me from day 1 as poor practice, for precisely the reasons experienced.
When setting up an approach you should set and verify the inbound course in NAV mode if on a G1000 or similarly advanced avionics and can then switch to green needles when required. What I used to do with the 430W was set the inbound course on the HSI then use the 430 CDI page to fly the GPS track with the AP in heading mode. If you are flying an overlay or full RNAV approach you should verify tracks and distances line by line when setting up for the approach in similar fashion.
Some autopilots use the heading bug for this instead of the course setting. But maybe that’s only old stuff like the Piper Autocontrol?
This happens when you don’t have an HSI: the AP takes the localiser error from the CDI (which doesn’t know about current heading, so it can’t output a course error signal) and uses the heading error from the DGI instead of a course error.
If the course pointer is off in the G1000 it will also not capture and track the LOC correctly. Had this once when it didn’t auto slew to the correct inbound course.
Fundamentally, the AP needs to know two bits of information to track a localiser: localiser error and current heading. Inbound course is strictly speaking optional, but makes life a lot easier:
With no inbound course, the AP can’t figure out an initial direction to turn to intercept – it would have to try one direction, then turn the other way if the first guess was wrong… It would also have no way to tell when to stop turning until the localiser starts to move back.
Absolute heading doesn’t matter – just the difference from some datum. Using course as that datum allows two pieces of information to be encoded in one signal.
I would hope a digital AP like the DFC90 or G1000 would take a whole load of info:
This let’s it calculate an exact solution for intercept. Any error can easily be dealt with by running a PI loop over some error function that sums the localiser error and the rate of turn output from the exact solution.
This is all quite interesting – makes me want to build an autopilot…
If the course pointer is off in the G1000 it will also not capture and track the LOC correctly. Had this once when it didn’t auto slew to the correct inbound course.
In HDG mode, the heading bug is fed to the AP as a left/right voltage. That mode is very simple.
If you have an external roll steering converter, that generally fakes a heading bug so again this is fed to the AP as above, and the AP can fly anything the GPS tells it to, DME arcs, you name it, all in HDG mode.
I reckon the DFC90 is controlled laterally the whole time via ARINC429, and doesn’t give a damn about anything like the CP or the HSI heading bug, so the AP itself is probably the wrong place to look if it is behaving strangely.
I would look at how Achim’s Aspen EFD1000 is doing all that stuff…
The problem in your case is that the AP is looking at two inputs to its error function: Localiser and Course error. If the course is set wrongly, that error can easily dominate and it will turn toward the course rather than the localiser.
Some autopilots use the heading bug for this instead of the course setting. But maybe that’s only old stuff like the Piper Autocontrol?
