If you want a Honeycomb Alpha for Christma you better order fast because we are quickly running out of stock!

Jump to content

Archived

This topic is now archived and is closed to further replies.

PeterZ KCLE EDDN

Altimeter setting pilot/copilot fighting?

Recommended Posts

Hi there,

I just installed 1.04 and noticed that after 2 test flights (with AS2012) everything works well until I descent below transition altitude. At that point (I have copilot and checklists on) the altimeter goes nuts! My apologies but I don't know how to else explain it, it appears as if the last digit changes super fast but only by one digit, almost like a graphical glitch.

When I hold the "B" button, the altimeter shows the correct Hg or hPa, but the copilot never recognizes it as the right altimeter setting, and as soon as I release it the anomaly reappears. When this happened on my second flight I decided to turn off the copilot, and voila, the super fast changing of the last digit dissapeared.

So my guess is, with the copilot "on", she continuously tries to change the altimeter setting agains whatever I'm doing by pressing the "B" button. Strangely enough though, even if I stop pressing it (or setting altimeter manually) the fast last digit changing continues. This happens only on descent though.

I hope this makes some sense ;-)

Cheers,

Pete

Share this post


Link to post

Hi Pete,

as mentioned in the release notes and in the Vol6 StepbyStep EN - #222:

The QNH value entered in the MCDU PERF APPR page is used by the copilot. If no value has been entered there then the current ambient pressure value will be used (= keyboard ) by the copilot. Like in reality the copilot enters those figures in visible steps and not at once. Then there is a pause of 2 seconds - during which the user can enter a different value – before the checklists continues.

So my question is: Did you follow this sequence respectively entered a QNH value into the APPR page?

Hanse

Share this post


Link to post

Hi Hanse,

I noticed that in the descent, through the transition altitude, the checklist hangs on the Capt side unless the the setting is toggled from Hg to hPa and back to Hg.

Brgds

Rob

Share this post


Link to post

Completely agree with what Hanse is saying. I've had no such issues with it functioning as explained.

Happy landings!!

ROMAN78

Share this post


Link to post

Hi,

the problem has been identified i. e. the conversion table / - calculation (between in Hg and hPa) is different between the BARO display and the MCDU ..... so there are slight differences. We will look into it how to change ........

Hanse

Share this post


Link to post

Hi,

the problem has been identified i. e. the conversion table / - calculation (between in Hg and hPa) is different between the BARO display and the MCDU ..... so there are slight differences. We will look into it how to change ........

Hanse

Good, that you fund the problem :-) So we can expect a Hotfix for this problem?`

Share this post


Link to post

I have the same issue with the latest fix.

There is a graphical glitch and the altimeter goes crazy at transition altitude. I'm glad to see it wasn't just me.

Share this post


Link to post

Samething with me.. but what I tried is as soon as your asked to push the b key try to remember the numbers and then input them in the approach window I keep FSX atc open just to give me the baro no flight plan... When a new baro is issued by atc again enter it in the approach window I only get this problem when I'm using really weather data because it's changing all the time.

Share this post


Link to post

Hi,

just to let you know that the problem has really been identified. FSX calculates a conversion between inHg and hPa (1013 to 29.92 = 33.8570) - and 1013 is not accurate. The AXE uses the "real world" conversion rate which is 1013.25 to 29.92 (= 33.8653). So if on the keyboard is used the value is different from the value calculated by the MCDU and is not accepted. We are working on a solution and as soon it is available I will let you know.

Hanse

Share this post


Link to post

Did aerosoft seriously put up a hotfix for the livery manager why this issue is still a major problem?

Share this post


Link to post

Did aerosoft seriously put up a hotfix for the livery manager why this issue is still a major problem?

Yes, because the livery manager fix was done by a different developer of the project, that is in no way involved with problems like this, or VNAV, or LNAV. Those are all different people. So, if someone else can get a fix for something else out, why wouldn't they?

Share this post


Link to post

I understand that. Id just like an aircraft I paid for to be flyable. Haven't been able to in a week.

Share this post


Link to post

I can confirm the problem is gone when not using copilot. I'm also thinking activesky could be part of the problem. Any luck with a solution?

Share this post


Link to post

I can confirm the problem is gone when not using copilot. I'm also thinking activesky could be part of the problem. Any luck with a solution?

We are just not sure at this why this problem occurs for some users and not for the big majority, it is a very puzzling issue.

And yes, the fact we have one issue does not mean all the other developers stop working!

Share this post


Link to post

Do you have any suggestiOns? I reinstalled twice. Can you make v 1.03c available for those with this problem until its fixed. Please Mathijs?

Share this post


Link to post

Is there any news regarding this issue?

I just want to say that we are working on a solution. I will not state a date because we do not want a discussion like on the release date for the AXE.......

This is not a small isuue to be fixed by just changing a code line in the programming. It is a major change..... The root cause is that users want to use the FSX functionality = keyboard B for the ambient pressure. But FSX is using a wrong conversion rate between inHg and hPa (29.92 to 1013 instead of 29.92 to 1013.25 which we currently use for the AXE). Additionally FSX uses an irregular rounding..... So this means to fix that problem we now have to use the FSX conversion rate and also to add a leeway to solve the FSX rounding problems. The changes we have to make are effecting:

  1. QNH display i.e. the complete glareshield - VC cockpit

  2. MCDU - PERF - APPR page

  3. Checklist- and Copilot functionality

Please understand and we are doing our best to suit you ......

Hanse

Share this post


Link to post

Ok Hanse, I understand and thanks for your answer :-) But it worked in 1.03 and what have changed in 1.04?

Share this post


Link to post

Hi,

first: Why do you want to know? If you are really interested then please read all the previous threads regarding this subject. We had to change the BARO SETTING in 1.04 because of the other issues. Please keep in mind that this is a support and not a discussion Forum. All developers would like to use most of their time to fix issues, develop new features and solve real problems users have ......

Hanse

Share this post


Link to post
Guest
This topic is now closed to further replies.

×
×
  • Create New...