Lear35A AP Problem

[ark 1,288]

Flew a short hop in the Lear35 from KLXV in Leadville, CO to KASE, Aspen, CO using the GTN750. Approach at Aspen was the VOR/DME-C with the DBL (Red Table VOR) transition.

This requires entering a holding pattern at DBL to reverse course for the approach. The holding pattern entry is a Teardrop, and at DBL the Lear35 (still in NAV GPS mode) turned and initiated the Teardrop entry correctly, but then failed to turn back towards the DBL holding fix as the GTN750's magenta course line was "directing".

When I flew the exact same flight plan with the GTN750 in the default Lear45, and in the Milviz C310, both a/c correctly turned back towards the DBL holding fix.

Although I can't think of any reason why the Lear35 failed to follow the GTN750's magenta course line back to the holding fix except for some type of bug in the autopilot, I'm certainly open to other possibilities.

 

A friend with the same Lear35/GTN750 setup had the same experience.

 

Al

[ark 1,288]

Similar to the above problem, I find that Lear35 AP coupled with the GTN 750 does not fly a complete procedure turn associated with a VOR or ILS approach. The a/c enters the procedure turn, but fails to turn back towards the final approach course as depicted by the GTN 750 magenta course line. Again, flying the same approach using the default Lear45 or Milviz C310 with the GTN 750, the procedure turn is completed as expected.

 

Is anyone aware of any plans to address the various AP bugs that have been discussed on this Forum? These AP bugs detract significantly from what otherwise is an impressive simulation.

 

Al

[bpcw001 22]

Al,

 

I am with you. The autopilot does strange things at times and does not follow what the GTN dictates.

Usually, as often in real life as well, manual interaction by the pilot clears the situation.

I have the impression that the turn rate of the Flysimware lear is pretty bad, even at low speeds, which makes the autopilot lose track of the GPS in tight turns.

Did you try a really low speed? Does it follow the GPS track then?

 

As for any plans - I have not heard anything from Flysimware yet. They appear to have gone completely silent. Somewhere here I read that Flysimware is essentially a one-man show, and that the guy already moved on to the next project. If that turns out true, we're screwed.

I even tried to fix some things myself, but unfortunately most of the gauges (like the altimeters, or the pressurization system) are not XML gauges, but compiled into the binary model. Thus, there is no way to fix stuff in the gauges like it is possible with other addons. The GTN lighting issue could probably be fixed in the 3D model only anyway.

 

I do repeat myself, but I also think that this Lear 35A is what could currently easily be the best business jet simulation out there, if only the few outstanding issues would be looked into.

I cannot understand how one could be so close to completion and not go ahead and finish the thing. What needs to be addressed is readily compiled here in the forum posts. The community is not that big and hence it should be no problem to gain the respective insights by just sifting through the couple of posts here. And we're all here to answer the developer if more information is needed for fixing.

[ark 1,288]

Dave,

It doesn't seem to be a turn rate issue. In the examples above, the Lear35 didn't even attempt to bank into a turn.

Al

[bpcw001 22]

Hm. Will have to try that one.

[MatzeH84 81]

I guess what you discribed is not an issue of the autopilot itself, but more of the combination with the GTN.

What you wrote is a perfect example. Situation: VOR at the field, ILS approach. You cross the field outbound radial XY to let's say 10DME, that's fine. But now the GTN does not connect the 10DME point to the next fix (FAF), so there is no path to follow for the AP, just the command to intercept the new inbound course- which it can't because the intercept angle is infinite. So the AP drops the NAV CAP mode and reverts to NAV ARM. You have to manually turn the aircraft to a heading on which the new commanded course can be intercepted. Once you do this, the AP will intercept and track inbound.

 

You cannot handle the GTN and this AP like a fully integrated FMS. After all, it's just a simple GPS system and a rather basic autopilot, which can only track a NAV signal or fly a heading.

[ark 1,288]

I guess what you discribed is not an issue of the autopilot itself, but more of the combination with the GTN.

What you wrote is a perfect example. Situation: VOR at the field, ILS approach. You cross the field outbound radial XY to let's say 10DME, that's fine. But now the GTN does not connect the 10DME point to the next fix (FAF), so there is no path to follow for the AP, just the command to intercept the new inbound course- which it can't because the intercept angle is infinite. So the AP drops the NAV CAP mode and reverts to NAV ARM. You have to manually turn the aircraft to a heading on which the new commanded course can be intercepted. Once you do this, the AP will intercept and track inbound.

 

You cannot handle the GTN and this AP like a fully integrated FMS. After all, it's just a simple GPS system and a rather basic autopilot, which can only track a NAV signal or fly a heading.

Matthias,

 

Thanks for the response.

 

As I mentioned above, in both of the cases I described the GTN750 correctly displayed a magenta course turn line but the Lear35 did not "make the turn" to follow it, but two other a/c using the GTN750 and basic APs did correctly make the turns, so I don't understand the point you are making.

I do realize the GTN750/Lear35 AP combination is not a fully integrated FMS (especially regarding VNAV), but if the GTN750 correctly depicts a magenta LNAV path, why shouldn't the Lear35 AP follow it as did the other two aircraft?

Al

[MatzeH84 81]

Ah, sorry I misread that. However, can you confirm that NAV CAP reverts to NAV ARM when the Lear loses the correct track?

[ark 1,288]

Ah, sorry I misread that. However, can you confirm that NAV CAP reverts to NAV ARM when the Lear loses the correct track?

 

Yes, Matthias, that is correct.

Al

[Raphael_Chacon 42]

Same here.... but at very low speeds seems to work (Quick test)

 

Hope its revised and corrected.  I love this bird!   :wink:

[ark 1,288]

Same here.... but at very low speeds seems to work (Quick test)

 

Hope its revised and corrected.  I love this bird!   :wink:

I made some additional flight tests, and yes, at 140 Kts the L35 did make the turn to complete the teardrop entry described in post # 1, but failed to do so at 150 Kts.

Al

[MatzeH84 81]

I still don't know if there is something to correct.

I can confirm that going too fast will trigger this problem. If the turns are tight and the speed too high, the turn radius will increase. The maximum turn rate isn't sufficient to stay on track, so the AP says 'I am out' and switches responsibility to return on track to the pilot.

Remember this is a 70's autopilot, not some fancy stuff we have now.

So either FSW had to increase the autopilot turn rates, or we must plan ahead, slow down sufficiently and expect to hand fly out back on course.

There was a real LJ pilot here in the forums, maybe he can give advise about this, too.

[bpcw001 22]

I still don't know if there is something to correct.

I can confirm that going too fast will trigger this problem. If the turns are tight and the speed too high, the turn radius will increase. The maximum turn rate isn't sufficient to stay on track, so the AP says 'I am out' and switches responsibility to return on track to the pilot.

Remember this is a 70's autopilot, not some fancy stuff we have now.

So either FSW had to increase the autopilot turn rates, or we must plan ahead, slow down sufficiently and expect to hand fly out back on course.

There was a real LJ pilot here in the forums, maybe he can give advise about this, too.

 

In general, you are right. But if it is a coded procedure with a procedure turn as in this case with the GTN even depicting it correctly, the GPS track can only be lost if the GTN determines that the aircraft cannot make the turn at the given speed and assumed max bank angle of 30 degrees, hence dropping navigation (NAV ARM) and waiting for manual intervention.

The GTN uses turn anticipation calculations, so this fits into the picture. I agree that there is probably nothing to be corrected here. Real-world systems have these restrictions too, and the nav system/autopilot combination will drop out if it determines that it cannot comply within given constraints with what you're asking for.