Menu

#2476 KAP140 Autopilot: wrong lock on invalid VOR/LOC/GS signals

2020.3
Fixed
Medium
2021-01-01
2020-12-16
No

Some time ago i found a bug with the default KAP140 autopilot implementation:
Currently, it locks the vertical and horizontal tracking modes if the indicated deviation is just within 3°. That is wrong (imho), because the Kap140 should not lock onto invalid signals.

This patch introduces a check for valid VOR/LOC as well as GS signals, and only if they are valid they will be catched. I deduct this from the manual, that says that GS will lock at about the outer marker (where the signal usually gets valid) - with the bug intact, the GS locks as soon as the VOR/LOC locks (which may even be the case when there never was a valid VOR/LOC in the first place!

1 Attachments

Discussion

  • James Turner

    James Turner - 2020-12-16

    Yes, seems sensible to me. Would you consider this safe enough to apply to the LTS branch as well?

     
  • Benedikt Hallinger

    Good question.
    I just did test entering APR from ROL and HDG and that worked fine.
    Let me test this for entering NAV and REV.... standby

     
  • James Turner

    James Turner - 2020-12-16

    Other question is, do we know which aircraft use the KAP140? We can people to test those on next, and if they report all is well, we can then consdier this for the LTS in a few weeks.

     
  • James Turner

    James Turner - 2020-12-16

    Err, 'ask people to test', is what I meant.

     
  • Benedikt Hallinger

    looked good in all modes with all interception methods :)

     
  • Benedikt Hallinger

    I know for sure the c172p uses it and also the c182s.

     
  • James Turner

    James Turner - 2020-12-16

    Okay, that should be quite enough to get some feedback indeed.

     
  • James Turner

    James Turner - 2020-12-17

    Merged to next as 0d546f53849dcbf6bb2f389224709b74c2f786c4

    Will ask people on the devel list to test, and then we can pick to LTS in the next few weeks.

     
  • James Turner

    James Turner - 2020-12-17
    • status: New --> Fixed
    • assigned_to: James Turner
     
  • Benedikt Hallinger

    Hello James,
    sadly i forgot one instance of the check, so the NAV-Arm is still buggy.

    Here is the fix for that attached.

     
  • Benedikt Hallinger

    I found and fixed another bug with annunciators wrongly lit in the more obscure click paths.

     
  • James Turner

    James Turner - 2020-12-27

    Patches merged to FGData next in commits ad6ab066ad49ba9c5ce13ce54315c7d0651bea07 and 080e1ed403b734765e7efaf92c2d7f5df520fd30

     
  • Benedikt Hallinger

    confirmed to work on next :) b42759704fafd28762

     
  • Benedikt Hallinger

    I revise; it seems part of the second patch is missing, specifically these bits:

    @@ -606,9 +610,12 @@ var navButton = func {
         annunciatorNavArm.setBoolValue(1);
         annunciatorAprArm.setBoolValue(0);
         annunciatorRevArm.setBoolValue(0);
    
    +    annunciatorGsArm.setBoolValue(0);
         annunciatorNav.setBoolValue(0);
         annunciatorRol.setBoolValue(0);
         annunciatorRev.setBoolValue(0);
    +    annunciatorApr.setBoolValue(0);
    +    annunciatorGs.setBoolValue(0);
    
         navArmFromHdg();
       }
    
    @@ -777,9 +796,12 @@ var aprButton = func {
         annunciatorNavArm.setBoolValue(0);
         annunciatorAprArm.setBoolValue(1);
         annunciatorRevArm.setBoolValue(0);
    
    +    annunciatorGsArm.setBoolValue(0);
         annunciatorNav.setBoolValue(0);
         annunciatorRol.setBoolValue(0);
         annunciatorRev.setBoolValue(0);
    +    annunciatorApr.setBoolValue(0);
    +    annunciatorGs.setBoolValue(0);
    
         aprArmFromHdg();
       }
    
    @@ -993,9 +1027,12 @@ var revButton = func {
         annunciatorNavArm.setBoolValue(0);
         annunciatorAprArm.setBoolValue(0);
         annunciatorRevArm.setBoolValue(1);
    
    +    annunciatorGsArm.setBoolValue(0);
         annunciatorNav.setBoolValue(0);
         annunciatorRol.setBoolValue(0);
         annunciatorRev.setBoolValue(0);
    +    annunciatorApr.setBoolValue(0);
    +    annunciatorGs.setBoolValue(0);
    
         revArmFromHdg();
       }
    

    The other ones from the patch were applied correctly.

    Lastly, i forgot to add this to the patch; the following TODO marker is resolved and can be deleted safely:

      ##
      # TODO:
      # NAV mode can only be armed if we are in HDG or ROL mode.
      # Can anyone verify that this is correct?
      ##
    

    Sorry for making this harder as it should be, but i still didn't figure out how/where i can clone fgdata to,so you can just apply a PR

     
  • James Turner

    James Turner - 2020-12-30

    Sorry, there was an error merging this one, I thought I'd fixed it manually. This is exaxctly what would be better if you could make commits yourself: when you make seperate patches, I have to guess which order to apply them in, since you don't make it clear.

    I thin k you have three patches pending now, so please do let me know which order they will work in :)

     
  • Benedikt Hallinger

    Hello James,
    no problem - all is applied good, except the last three parts i mentioned above.

    Here is my kap140.nas file for reference. i checked it agains the current next one and it also just shows the lines missing above; so just dropping in this one should do the trick.

     
  • Benedikt Hallinger

    Just wanted to confirm, it works with fgdata on next@97c9b06a7edb9c.

     

Log in to post a comment.

MongoDB Logo MongoDB