what_next wrote:
There is unfortunately some confusion with these designators. In some airspaces (USA, North Atlantic, …) the precision is designated by a suffix like RNP 1 or RNP 5. Others (Europe!) use a letter as prefix like P-RNAV or B-RNAV for the same thing.
It is not the same thing. P-RNAV is essentially RNAV 1 which is not the same as RNP 1. B-RNAV is essentially RNAV 5. As far as I know, there is no RNP 5. Also, P-RNAV and B-RNAV are legacy designations. RNAV 1 and RNAV 5 are the designations properly used also in Europe.
The main difference between RNAV and RNP specifications is that RNP specifications require built-in integrity checking (such as RAIM) while RNAV specifications do not. That’s why RNAV specifications are typically used in airspace where radar is available (like most of Europe) while RNP specifications are typically used where it is not (like oceanic airspace) but also — obviously — for approaches.
Peter wrote:
A “classic 1980s/90s” system, where the autopilot gets its heading from the HSI course pointer and gets a fine adjustment from the HSI deviation bar voltage, is going to overshoot massively and then oscillate.
That’s what I was going to write: I’ve tried it in an SR22 with STEC 55X en route (at about FL100) to set the GPS sensitivity to 0.3 nm, and it started to oscillate right and left of the route. In case you ask, it was over Northern Lappland and I was bored. :)
Jacko wrote:
At least one training school (not far from Gloucester) teaches to set the GNS/GTN permanently to 0.3 nm full scale, rather than the usual “auto” setting. That’s arguably OTT, but it certainly sharpens up one’s en-route flying.
I have had extended, but friendly, discussions with said school.
It seems to me that their reason for doing this extend only to the passing of an Initial Skills Test and they agree that in the wide world it has no advantages.
Personally, I would expect an on-the-ball IRE to say “that is not how the system is designed to work” and mark the candidate down for lack of knowledge and ability to use the equipment as fitted, but that is clearly not happening as said ATO gets very good pass rates.
Also, I have found that in some navigators in some circumstances (GNS530 establishing on LPV approach) the results are not as expected, in that the LPV annunciator comes up much later than it would on the Auto setting, but, as you can imagine, the opportunities for testing and scaling this problem are small, so it is one of those things that I have seen but cannot swear to.
The whole PBN system is designed around RNAVX and RNPX, for all good reasons, and to throw away the whole PBN system and its assumptions for the sake of not forgetting to switch to RNP0.3 on unpublished approaches strikes me as arse about face.
Will try that too, my guess is that it will work better with the DFC90 … what do you think?
I have designed two DIY approaches for both my homefield and for the little strip in CZ where my company is. I have flown them both in VMC and I would fly the German one no problem down to 500 ft in actual IMC … but not the one in CZ: several chimneys close to the field, some (minor) hills, does not feel right to try that.
I’ve tried it in an SR22 with STEC 55X en route (at about FL100) to set the GPS sensitivity to 0.3 nm, and it started to oscillate right and left of the route.
In that case I wonder how it flies the final segment of a GPS approach?
My plane will fly in a straight line fine at 0.3nm FS but any intercepts etc are very under-damped
So “0.3nm always” would be very poor advice, to give out generally.
Some STEC55X installations have that osciallation problem, but I do not understand why it should be more pronounced with higher sensitivity.
Alexis wrote:
I do not understand why it should be more pronounced with higher sensitivity.
Peter’s graph neatly encapsulates why, but essentially it comes down to when (ie at what HSI deflection) the autopilot commands a rate one turn, the lag of that turn starting and being effective, and the rate at which the HSI deflection changes in the meantime. Try drawing it out to scale, with the simple assumption that the turn will be started with a half scale deflection, and include an accurate lag period for the turn and the radius of turn.
If you are already on the centreline, pointing in the right direction it will hold you, but it is quite likely that a 45° intercept will always diverge (in other words, not just be the under damped system in Peter’s graph, but actually divergent.)
but essentially it comes down to when (ie at what HSI deflection) the autopilot commands a rate one turn, the lag of that turn starting and being effective, and the rate at which the HSI deflection changes in the meantime
From my observation, the way the “classic” HSI-driven turns work is that for more than about 20 degrees of change you get limited by the autopilot’s certification limit (rate 1 for TC-driven APs, ~22 degrees of roll for AI-driven APs). Below that you are looking at a crude proportional control loop whose gain is directly related to the HSI full scale sensitivity. So at 0.3nm FS you have a lot of gain, which is what makes the control loop unstable.
Installing the Sandel EHSI has not changed this except it made it more precise. The SN3500 does have a roll steering option (which turns it into a roll steering converter) but that needs an ARINC429-emitting GPS which I don’t presently have. On a homebuilt one could convert the KLN94 data stream into ARINC429 and interpolate the samples… One roll steering converter maker (DAC I think) claimed this is impossible which I am sure is nonsense…
0.3nm should be stable when flying straight ahead. Except rwy20’s STEC55X case, which I believe is a defective installation, like many STEC ones are because STEC didn’t flight test all configs but got “based-on” STCs (in the good olde days). It should also be stable on the approach because you have no course changes before the FAF and the gradual gain windup (in a certified IFR GPS) from 1nm to 0.3nm enables the oscillations to die out during the windup period which lasts some tens of seconds. It is a primitive and sub-optimal but effective method.
The DFC90 scenario should be irrelevant to this discussion because (a) it was only ever certified for very few types so they should have flight tested it all around the speed and loading envelope and (b) all applicable installations should have roll steering anyway.
We need an “autopilot stability” thread 
but there is bugger-all expertise around to contribute to it. The designers seem to have mostly just hacked it, and anyway none of them will be posting here. They will either be banned by company policy or they have died of old age.
This all seems off topic but the manual GPS FS setting is central to flying DIY approaches and the 0.3nm behaviour follows from that.
I have just merged several threads on the same topic.
Peter wrote:
0.3nm should be stable when flying straight ahead. Except rwy20’s STEC55X case, which I believe is a defective installation, like many STEC ones are because STEC didn’t flight test all configs but got “based-on” STCs (in the good olde days).
I would also think that this is not normal, and was particular to that installation. Maybe going directly from 5 nm to 0.3 nm induced the autopilot to overcorrect towards the center, and it never stabilised there either because it was designed to do that only at lower speeds, or because that particular AP had some issues. I don’t remember seeing this behaviour during approaches with that plane, but we didn’t do any coupled GPS approaches and probably hand-flew most of the ILS ones (I don’t really trust or like the STEC that much). And I’ve never done the same experiment en-route with other Cirruses. The DFC90 shouldn’t ever have such issues in my opinion.
The whole PBN system is designed around RNAVX and RNPX, for all good reasons, and to throw away the whole PBN system and its assumptions for the sake of not forgetting to switch to RNP0.3 on unpublished approaches strikes me as arse about face.
Absolutely, I wasn’t advocating flying everywhere on 0.3, just remarking that’s what a well known school teaches.
As for AP instability, I have noticed that on my STEC 60-2. The answer is to follow the magenta line with heading bug, or watch a GPSS dongle do the same, or even fly by hand. Even that’s not a high price to pay to avoid scud-running.
