AP issue with UP and DN buttons

[Raller]

In the positive area the UP and DN buttons react correctly (each button stroke will increment the vertical speed commanded up or down by 100 ft/min per button press)

In the negativ area the DN button works fine, but if i press the UP button (to correct my descent rate), the VS value abruptly jumps back to zero! That is very disturbing.

Raller

[Taguilo]

Hi,

Thanks for detecting that.
Here is the fixed file. Please download, unzip and replace in PANEL\KAP140_HSI folder.

Tomas

[MikeFlight]

Thanks. But:

There is only one folder "KAP140_HSI.cab
How can I copy or overwrite the MV_KAP140Servos.xml?

[Raller]

THX to Tomas and the Support-Team
Raller

[MikeFlight]

Okay thanks. I did that, worked too. However, probably something must have gone wrong. The autopilot does not work anymore. Now I have to install the C310 completely again.

[Raller]

@MikeFlight
1. unzip the File "KAP140_HSI.CAB" with a ZIP-Software like 7z so that you have a Folder called "KAP140_HSI"

2. you can leave the unziped Folder, the Airplane can use both, either the FILE "KAP140_HSI.CAB" or the unziped FOLDER "KAP140_HSI"

3. make sure you use only one of the options in No.2, so if you want to work with the FOLDER from now on, you have to remove or rename the File "KAP140_HSI.CAB" so that only the FOLDER "KAP140_HSI" is left. (BTW that works in every Airplane under the Panel-Folder, thats the way how the MODs are implemented in some Aircrafts!)

4. now you can put the Patch-File in that FOLDER and replace the faulty file

5. done...

[fppilot]

This fixes the OP's identified issue. I still seem to be experiencing one issue. When I set the AP to climb to a higher altitude, I set that altitude, select ARM, then set my VS. The Alt Arm stays lit, the aircraft climbs to and levels at the armed altitude.

When cruising at a level altitude and deciding to descend to a new lower altitude, I dial in that lower altitude, I need to set ARM before I can select a VS. Fine. But once I set the VS the ARM annunciation goes out and I find I have to select ARM a second time or the AP descends right through the lower altitude and continues to maintain VS.

[Raller]

The ARM Knob is really confusing, i never use it. The KAP140 AP is also installed in the A2A 182 and i had to read a lot in the Forum to understand the AP!

I do it like this instructions:

• To capture the CURRENT altitude you are at, press ALT. It does not matter what the altitude is set to. Pressing ALT only captures the current altitude.

• To capture the specified altitude dial it in and then you must press ALT until the AP reads VS for Vertical Speed. Then you can press UP/DOWN to choose the rate to go up/down to the altitude.

That works fine without the ARM-Knob.

[fppilot]

The ARM Knob is really confusing, i never use it. The KAP140 AP is also installed in the A2A 182 and i had to read a lot in the Forum to understand the AP!

I do it like this instructions:

• To capture the CURRENT altitude you are at, press ALT. It does not matter what the altitude is set to. Pressing ALT only captures the current altitude.

• To capture the specified altitude dial it in and then you must press ALT until the AP reads VS for Vertical Speed. Then you can press UP/DOWN to choose the rate to go up/down to the altitude.

That works fine without the ARM-Knob.

Raller,
I have mixed results with the ALT button. I'm cruising at 3500 on AP. Let's say I want to climb to 4500. KAP 140 procedure is to dial in 4500 with the inner and outer knobs. That should Arm the AP for 4500. That works fine for me for climbs. Next is to press the ALT button to disarm the current altitude and annunciate VS, then to use the up key to set the VS. After that the AP should return to annunciate ALT Arm after a second or two. A long press of the ALT key works for me. In my case sometimes (not always) if I dial in a lower altitude and my press of the ALT key is too short the AP instead locks in the current altitude and the UP and DOWN keys are not available. The ARM key overcomes that if it happens.

See the segment at between 10 and 11 minutes into this video: https://www.youtube.com/watch?v=laz1jcwdLvQ, which by the way for all those reading is an excellent turorial video on the KAP 140.

I ran into another expeience yesterday as well when just flying around and gaining more experience with this AP. At one point I set up a D-> to on the primary GNS. I went to the AP and pressed NAV. The ROL and NAV annunciations both lit up and the AP did not change to the D-> course. I floundered around for a minute or so, changing back and forth from HDG to NAV and with NAV the ROL continued to annunciate and the AP did not respond to the D->, What I found was though I had set the D-> on the GNS, I had not activated it! So the AP had no NAV course on which to establish. So for all reading, that is what to look for if that happens to you....

[Raller]

Great tutorial video. I don't know if the Milviz KAP140 AP is modeled in all its detailed features.

It has happened to me before that my speed (maneuvering speed) was to high and the AP could not follow the track in NAV Mode. But that should give an AP error.

I have to take my time and make a long flight only to learn and try out all the AP funktions. By now i only use the basic functions...

[Taguilo]

Great tutorial video. I don't know if the Milviz KAP140 AP is modeled in all its detailed features.

That tutorial is good starting point, even though it has some display inaccuracies and a wrong behavior when NAV source is switched.
Our KAP140 version is the most realistic (and detailed) done for FS, and so the reason for pilots being faced with unexpected behaviors.

It has happened to me before that my speed (maneuvering speed) was to high and the AP could not follow the track in NAV Mode. But that should give an AP error.

The KAP140 does not throw errors in flight. It just disconnects when any of flight parameters has exceeded its tolerance.
Unable to follow a NAV track is something rather usual in the real unit, so yes, what you are seeing in that case is what really happens in RL.

COMMENT: Please note there is something wrong in ARM button of VC model that makes it work bad sometimes. We will fix that as soon as possible.
The popup unit works as expected, however I've seen that it is not included in some panel configurations.

Tomas

[fppilot]

Great tutorial video. I don't know if the Milviz KAP140 AP is modeled in all its detailed features.

That tutorial is good starting point, even though it has some display inaccuracies and a wrong behavior when NAV source is switched.
Our KAP140 version is the most realistic (and detailed) done for FS, and so the reason for pilots being faced with unexpected behaviors.

It has happened to me before that my speed (maneuvering speed) was to high and the AP could not follow the track in NAV Mode. But that should give an AP error.

The KAP140 does not throw errors in flight. It just disconnects when any of flight parameters has exceeded its tolerance.
Unable to follow a NAV track is something rather usual in the real unit, so yes, what you are seeing in that case is what really happens in RL.

COMMENT: Please note there is something wrong in ARM button of VC model that makes it work bad sometimes. We will fix that as soon as possible.
The popup unit works as expected, however I've seen that it is not included in some panel configurations.

Tomas

Not sure if what I am seeing is what you describe. It occurred again today on my flight from KBMG - Bloomington, Indiana, to Omaha, Nebraska. Again, it happened a bit over two hours into the flight. Was cruising happily along on AP tied to a GNS flight plan. Again, I am using a combination of an RXPv2 GNS 530 and 430.

The GPS plan and track were correct. The AP was on NAV and tracking just fine. Then without any event, and on a straight segment (not at a turn) the AP's ROL annunciation lit up. The NAV annunciation also stayed lit. At the time my heading bug was set more than 90° to the left. The AP turned the Redux what appeared to be the heading bug setting. I reacted with countermeasures too early to confirm that, but it seemed obvious.
ROL and NAV stayed annunciated. The AP did not shut down! The AP at no time gave any indication of HDG. To remedy the situation required that I select a D-> to the next waypoint on my flight plan, and execute. The Redux then turned back to that waypoint and completed tracking the flight plan to conclusion.

This is now my fifth such experience. It seems more based on some timescale than on any navigation or aircraft control, or AP tolerance, or combination of those. In every instance it was over 2 hours into the flight. In every instance it occurred in simply normal flight cruise. I send a couple of PMs to Bill back over a month ago when these occurred during the Indianapolis to Denver flight I mentioned above. I believe that was prior to a pair of later update releases, so from that standpoint it is not something introduced by those.

I fly this route multiple times each year, the most recent three occasions in the Milviz B55 with the same GPS combination. I have also flown the route in three other aircraft with RXPv2 GNS gauges and in no other case did i have such an experience.

This seems to be a timing loop issue. Duration into flight plan and perhaps timing of transition from one flight plan waypoint to the next. I have not had this occur less than two hours into flying AP on a plan. And on the one really long flight when it occurred twice, there was more than two hours of flight between the first occurrence (Kansas City) and the second (Denver).

Frank P

[bpieke]

Could it be that you are crossing a time zone boundary?

If the gauge uses the "local time" variable, these things can happen..

[Taguilo]

Then without any event, and on a straight segment (not at a turn) the AP's ROL annunciation lit up. The NAV annunciation also stayed lit. At the time my heading bug was set more than 90° to the left. The AP turned the Redux what appeared to be the heading bug setting. I reacted with countermeasures too early to confirm that, but it seemed obvious.

That is really weird. I understand you are saying ROL and NAV ARM messages appeared? But the aircraft seemed to turn towards HDG bug?
The KAP140 has no way to do that alone by itself.
When in NAV/APR/REV mode and signal (VOR/ILS/GPS) is lost, NAV/APR/REV shows flashing and roll mode reverts to ROLL. To recapture the signal simply press NAV/APR/REV to arm it again if you want to keep ROLL mode until capture, or press HDG if you prefer to fly current heading until capture. Once the signal is valid capture will proceed.

ROL and NAV stayed annunciated. The AP did not shut down! The AP at no time gave any indication of HDG.

As I stated before, AP won't disconnect if signal is lost. However, I believe something related to AP events might have happened.
Do you remember if you were typing at the moment the event occurred? The AP accepts FS key combinations to select HDG/NAV/APR/REV modes, so it is possible that HDG was selected without noticing, then another key press selected ROL when off course so NAV did not engage immediately but ARMed instead. It is the only thing I can suspect of.

At the time my heading bug was set more than 90° to the left.

A good advice, from real pilots, is to always keep the HDG bug linked with the current track, to avoid surprises like that.

Tomas

[fppilot]

A good advice, from real pilots, is to always keep the HDG bug linked with the current track, to avoid surprises like that.

That is something I do routinely. I had the HDG bug set up that way for the purpose of identifying this issue, which I had multiple experiences with. I was attempting to determine why the plane would deviate, and based on what. For instance, previously I felt that the issue occurred at a turn in the flight plan. My plans are relatively direct, so turns are not at all sharp. I suspected that the AP continued to track a course at the turn. This one occurred on V181 between LMN (lamoni) and OVR (Omaha). There is no turn.

As I stated before, AP won't disconnect if signal is lost. However, I believe something related to AP events might have happened.
Do you remember if you were typing at the moment the event occurred? The AP accepts FS key combinations to select HDG/NAV/APR/REV modes, so it is possible that HDG was selected without noticing, then another key press selected ROL when off course so NAV did not engage immediately but ARMed instead. It is the only thing I can suspect of.

I had not used the keyboard. What among what you mention would cause the AP to enter ROL and also stay in NAV? The AP did not annunciate HDG. HDG was not visually selected. But the AP turned the aircraft sharply in the direction I had the HDG bug set to. In the other instances of this issue the off course deviation was slight. Perhaps 20°. Also, understand this has happened now in five instances, so focusing on one instance with what-ifs does not seem right.

I am wondering if it is happening at a point of scenery loading. I am flying with Megascenery photo real scenery and have been in all instances. The first two times this occurred were when I was over Kansas City city megascenery, and into Denver megascenery city scenery. The third was over Nashville for which I have no city photoreal scenery, but was using Tennessee state megascenery. This latest one, yesterday, was nowhere near a scenery, but may have been near the Missouri-Iowa border.

I fly with this time of scenery almost exclusively and have had nothing like this happen with numerous other aircraft. I am suspecting some form of internal timing issue in the AP.

Frank