• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

Autopilot Current Heading Hold "bug free"

Joao Muas

Joao Muas

Messages
204
Country
portugal
Hello.

I'm writing a full feature XML autopilot gauge, but I'm stuck on this heading hold problem...

I want to be able to hold the current heading, but not by means of the heading bug... I need the bug free to change to selected heading on second click of the hdg hold switch.

First hdg hold switch click will hold current headind, second will go to selected, and third will disengage the hdg hold. It's cyclic.

Please help... I'd need to do the same for altitude hold...

Thanks.
 
The key to success is to use the stock HEADING_BUG_SET event.

Control the heading bug itself with a custom (L:HeadingBug,enum) variable, then whenever you enable Heading Hold, send the contents of your custom variable to HEADING_BUG_SET...

Code: 
<Click>
     (L:HeadingBug,enum) (>K:HEADING_BUG_SET)
     (>K:AP_HDG_HOLD_ON)
</Click>

This will allow you to move the visible heading bug without instantly updating the autopilot's heading hold function.
 
Last edited:
Instant 'lock' of Heading is done with this code;

AP_HDG_HOLD

Its clickzone would be;
(&gt;K:AP_HDG_HOLD)

However, turning on AP HDG to the 'setting' heading is done with this;
AP_HDG_HOLD_ON

The clickzone is;
(&gt;K:AP_HDG_HOLD_ON,bool)

and 'OFF' of course turns it off.

Its very difficult to work the code for 'both' of those commands into one click zone, but it is possible. If you figure a way to do it, I would be very interested in seeing how you do it. Bypassing 'on' and 'hold' would be a tricky feat of coding.
 
Bill, you must have written just before me. I didnt see your post before. Sorry.

I was thinking Enum. Interesting approach on how to work this.
 
n4gix said:
The key to success is to use the stock HEADING_BUG_SET event.

Control the heading bug itself with a custom (L:HeadingBug,enum) variable, then whenever you enable Heading Hold, send the contents of your custom variable to HEADING_BUG_SET...

Code: 
<Click>
     (L:HeadingBug,enum) (>K:HEADING_BUG_SET)
     (>K:AP_HDG_HOLD_ON)
</Click>

This will allow you to move the visible heading bug without instantly updating the autopilot's heading hold function.
Click to expand...

Looks like a very good solution, but I have no access do the EHSI itself, and I believe it sends directly to K:HEADING_BUG_SET, so I can't interfere...

lionheart said:
Instant 'lock' of Heading is done with this code;

AP_HDG_HOLD

Its clickzone would be;
(&gt;K:AP_HDG_HOLD)

However, turning on AP HDG to the 'setting' heading is done with this;
AP_HDG_HOLD_ON

The clickzone is;
(&gt;K:AP_HDG_HOLD_ON,bool)

and 'OFF' of course turns it off.

Its very difficult to work the code for 'both' of those commands into one click zone, but it is possible. If you figure a way to do it, I would be very interested in seeing how you do it. Bypassing 'on' and 'hold' would be a tricky feat of coding.
Click to expand...

I did figurered AP_HDG_HOLD and AP_HDG_HOLD_ON worked differently, but I had no success coding these two commands on the very same single area. I intended to do it using LeftSingle for one and RightSingle click for the other, but only the top one will work...

I'll go for the KISS option (Keep It Simple Stupid, and it applies to me). I'll keep the HDG button only for selected headings, and I have a STBY button left which activates WING LEVELER and ATTITUDE HOLD, and it will do very good for transitions, for that's what I want to deal with.

By the way, do you know how to engage a VERTICAL SPEED MODE, only controlled by the VSI bug, with no ALTITUDE SETTING? I tried the AUTOPILOT VERTICAL HOLD variable and some events like AP_VS_HOLD, but no luck...

Thank you for your answers.
 
Joao Muas said:
By the way, do you know how to engage a VERTICAL SPEED MODE, only controlled by the VSI bug, with no ALTITUDE SETTING? I tried the AUTOPILOT VERTICAL HOLD variable and some events like AP_VS_HOLD, but no luck...

Thank you for your answers.
Click to expand...

This is what I am using for VSI lock;


<Area Left="300" Top="576" Right="410" Bottom="649">
<Tooltip>Quick Select Vertical Speed Lock</Tooltip>
<Cursor Type="Hand"/>
<Click Kind="LeftSingle">
(&gt;K:AP_ATT_HOLD)
</Click>
</Area>

This isnt a bug reference 'on', just a 'lock'.

For some reason, this will turn off ALT locks. I have seen code from one of my other planes where conditional logic was written where when the selected altitude is near 1000 or 200 feet, the VSI is turned off and ALT is turned 'on' to go to the selected ALT. Pretty nice bit of logic, all automated.
 
lionheart said:
This is what I am using for VSI lock;


<Area Left="300" Top="576" Right="410" Bottom="649">
<Tooltip>Quick Select Vertical Speed Lock</Tooltip>
<Cursor Type="Hand"/>
<Click Kind="LeftSingle">
(&gt;K:AP_ATT_HOLD)
</Click>
</Area>

This isnt a bug reference 'on', just a 'lock'.

For some reason, this will turn off ALT locks. I have seen code from one of my other planes where conditional logic was written where when the selected altitude is near 1000 or 200 feet, the VSI is turned off and ALT is turned 'on' to go to the selected ALT. Pretty nice bit of logic, all automated.
Click to expand...

OK, that is indeed a lock; but a lock in attitude, not in vertical speed. I meant a vertical speed hold which could be adjusted by the VSI knob. I see there are variables and events available for that purpose, but they don't seem to work... your approach seems good, but you'll get your aircraft pitch locked and you have to use thurst to control vertical speed; I'd rather use rate of climb/descent to control vertical speed and the only way I can do it is by a diferent altitude selection... I think I saw true V/S control on autopilot on some addon I can't remember... thanks again.
 
That is a good point...

I'll reinvestigate my own controls. Mine is only a small 4 seat plane. It could be bad at high altitude.
 
If you write an xml part, you can make a switch or button cycle through commands.
This xml part will be simple compared to an xml gauge.

DG:eek:
 
Last edited:
Vertical speed is a sub function of the autopilot altitude hold function and can not be controlled separately.
A:AUTOPILOT VERTICAL HOLD,bool appears to be permanently true, whether or not the autopilot is switched on.
Roy
 
Last edited:
Roy Holmes said:
Vertical speed is a sub function of the autopilot altitude hold function and can not be controlled separately.
A:AUTOPILOT VERTICAL HOLD,bool appears to be permanently true, whether or not the autopilot is switched on.
Roy
Click to expand...

According to my testing (A:AUTOPILOT VERTICAL HOLD, bool) is permanently false...

In fact, in FS Vertical Speed Hold is "linked" to Altitude Hold, but there is a way to make it work separatly, using the solution n4gix pointed in the beginning of this thread, this time with the (K:AP_ALT_VAR_SET_ENGLISH)...

All we need is a dummy (K:AltitudeVarSet, enum) to manage the Altitude Setting display.

So when the autopilot ALT key is pressed we get

Code: 
<Click>
     (L:AltitudeVarSet, enum) (>K:AP_ALT_VAR_SET_ENGLISH)
     (>K:AP_HDG_HOLD_ON)
</Click>

Then, when we press the V/S autopilot key we get

Code: 
<Click>
     99999 (>K:AP_ALT_VAR_SET_ENGLISH)
     (>K:AP_HDG_HOLD_ON)
</Click>

Note the 99999 feet is an unreachable altitude, which is just what is needed to control de Vertical Speed, either up or down.

In both the above situations cases we have the VS knob to manage the rate of climb or descent, but with the V/S we have no effective target altitude.

I can think of a non precision approach, when you set the V/S and VSI knob to the desired descente rate, and set the missed approach altitude on the Altitude Setting gauge. If you miss the approach, you just press the autopilot ALT key, and adjust the VSI knob for the proper climb rate.

For this to work properly you must set the default_vertical_speed to 0.0 on the aircraft.cfg file and let the VSI knob "engage" the level change.
 
Last edited:
You must log in or register to reply here.
Back
Top