How does the Auto Pilot PathHold Works?

[RglsPhoto]

Hi,

Yestday I found something funny when the PATH HOLD is enabled.I took off from Vazini,QFE is 2892,so I set my altmeter to 2892 mmHg.After airborne,I climbed as 2000 feets per minutes and enable the AP in PATH Mode.

When my elevation was 10 000ft, I switch my altmeter to 2992 mmHg(That happened at 1817 game time).

With PATH Mode enabled,the A/C just automaticlly reduced the pitch angle when I adjusted the altmeter with the mouse scroll to increase to 2992 mmHg.When the adjusting was finished,the A/C reduced it's climb rate to the orginal one(2K ft/min).

If I reduced the altmeter,the A/C would increase the pich angle and descreased the angle to the orginal one after I finished the adujsting.

So my question is how the PathHold works in game,how it works in RL if the information is unclassified.

I also post my track file so you can check it in the track,or you can try in the game by youself.It's easy to reproduced.

Baro & AP PATH.trk

[WildBillKelsoe]

I'll take a look. but IIC, path hold maintains pitch angle per VVI. Alt hold maintains bank and altitude hold (meaning an orbit provided bank not greater than first degree (murder lol) on the ADI bank ticks.

 

finally, the alt/heading hold maintains your current altitude and heading (in a horizontal flight). If the stick is jerked at any mode apart from path hold, it will disengage the ape..

[BlueRidgeDx]

IRL, it literally maintains the flightpath that existed at autopilot engagement. Changing the altimeter setting should have no effect since the autopilot does not reference barometric altitude in this mode.

 

If I had to take a guess, I'd say that DCS is referencing barometric altitude rate of change (as displayed on the altimeter) as the baseline vertical reference. As a result, changing altimeter setting causes erroneous pitch commands that wouldn't occur if the code were referencing vertical speed as displayed on the VSI.

 

Ideally, it shouldn't be looking at either of these things, but rather the pitch angle itself.

Edited December 4, 2011 by BlueRidgeDx

[y2kiah]

Not pitch angle directly, in PATH HOLD mode pitch angle varies as airspeed (and AoA) changes. It makes the most sense for it to reference EGI, unless it's a legacy system that still references HARS or the baro. altimeter directly.

[RglsPhoto]

IRL, it literally maintains the flightpath that existed at autopilot engagement. Changing the altimeter setting should have no effect since the autopilot does not reference barometric altitude in this mode.

 

If I had to take a guess, I'd say that DCS is referencing barometric altitude rate of change (as displayed on the altimeter) as the baseline vertical reference. As a result, changing altimeter setting causes erroneous pitch commands that wouldn't occur if the code were referencing vertical speed as displayed on the VSI.

 

Ideally, it shouldn't be looking at either of these things, but rather the pitch angle itself.

I agree with you.Hope this would be fixed in the next patch

[RglsPhoto]

Not pitch angle directly, in PATH HOLD mode pitch angle varies as airspeed (and AoA) changes. It makes the most sense for it to reference EGI, unless it's a legacy system that still references HARS or the baro. altimeter directly.

 

In the track,EGI works properly,and the HARS is disabled(actualy I don't know how to use the HARS)

[BlueRidgeDx]

Not pitch angle directly, in PATH HOLD mode pitch angle varies as airspeed (and AoA) changes.

 

 

Quite right. I should have said Flight Path Angle (FPA), as referenced by the TVV. Not sure why I didn't... :music_whistling:

 

It makes the most sense for it to reference EGI, unless it's a legacy system that still references HARS or the baro. altimeter directly.

 

Right again. EAC uses the attitude, inertial velocity, and position data from the INS portion of the EGI (EAC becomes inoperative if the EGI is in GPS-only mode). It also takes airspeed, and barometric altitude input from the CADC.