Moved discussion on AP from Community Aircraft Mods Megathread

Discussion Hub General Discussion
,
1

Since this is where all the Technical Modders hang out, I will ask this here, as the solution probably requires a MOD, after the problem has been identified.

Basic issue is
The C172 Classic, is using the incorrect BARO for its AP.
And I wonder how many other Aircraft, especially the more comp,es ones, with multiple APs, and multiple Baro setting for those AP, are doing, and if underneath, they are also suffering form similar issues.

Should be of Interest to anyone working on Garmin AP systems …

For the Asobo C172 Steam gauge, this is specifically what is happening

The Plane has 3 Baros :
(a) For the needle panel gauge, adjustable by a rotary control.
(b) For the KAP140 AP, adjustable by the KAP140 controls (Buttons & rotary knob)
(c) For the Transponder, that has no adjustment, and should be set calibrated to STD Pressure.

The problem is, the KAP140 AP is using the Transponder Baro, for it altitude reference,

so
Adjusting the KAP140 Baro has no effect. to correct for atmospheric pressure change.

This may go UN-noticed, if the Baros are set with the “B” key, as the B key sets all Baros, even the one in the Transponder that is meant to stay at Std Pressure , but does not-- so it tend to cover up the issue.

What is not clear to me is WHY the AP is using the Transponder Baro ??

In more complex aircraft, with dual AP systems, and Pilot & C0-Pilot Baro adjustments, I suspect its an even bigger mess !!

Are other Modders seeing this type of issue ?
What dictates which Baro, a given AP uses ?

Posted about this in Discussions, and BUG report, but nobody seems interested – its not like it is a Major issue to many, like a “Press any key to Continue”

I’m working on a KAP140 AP Mod, and this is one of many issue I am trying to address…

HELP !!!

2

NO, sorry – that is just so wrong … ATC always receives FL from the Transponder… It is calibrated and fixed to do that.
The ATC computers translates that FL0 - FL XXXX to altitude AMSL to display to the controller.

No matter what the pilot adjusts, ATC sees his correct height. (if transponder is calibrated/set correctly by the Aviation Techs)

If the planes Altitude is not what ATC has instructed, they will typically repeat the Altimeter setting to the pilot, and if the pilot says they have set the correct setting, and are at the stated altitude, and ATC still does see that altitude, then its a Faulty Transponder, and ATC may tell them to stop squawking the Incorrect Mode C altitude. – and tell them to get it FIXED before the next flight.

Unfortunately, it seems Asobo has got it wrong as well, not knowing the precise details of how it is meant to work.

The reason it “appears” to work in MSFS, is because if you are lazy, and Press “B”, instead of actually entering the altimeter setting , then the “B” has effectively incorrectly set the Transponder to read ASL, instead of FL, and the AP appears to stabilized at the correct altitude.

This issue will become even more of a problem, once the Airlines in MSFS, start having dual and dual+redundant APs, (Cat III) that have to be individually set by Pilot & Co-plot.
Then it will be a real mess…

=================

ref:

• Mode C altitude transmissions are independent of the barometric altimeter.
The transponder can get its information from one of two sources: an encoding altimeter, which transmits a pressure altitude reading to the transponder, or — more commonly — a blind encoder, an altimeter without needles or adjustment knob permanently set to 29.92 (pressure altitude).

In either case, the altimeter setting does not affect the altitude the transponder sends. ATC’s computers apply the current altimeter setting to the pressure altitude received, converting it to msl (which should match your indicated altitude).

Therefore, you cannot fool ATC by resetting your altimeter (of course, you could always fly the airplane a little higher or lower — that’ll fool ’em!).

ATC will most likely ask you to “stop altitude squawk” if your indicated altitude and the altitude received by ATC differ by 300 feet or more. The transponder transmits pressure altitude to ATC in 100-foot increments.

• For flight in controlled airspace under IFR, altitude encoders must be tested and re-certified every two calendar years. [91.411(a)]

1 Like
3

KT75C MOD (still in Alpha because of issue explained above)

trans
trans1920Ă—1011 175 KB

KT76C - Updated … With ability to display DME from Nav 1 or Nav 2 Radios.

The MSFS C712 Steam does not have a DME unit, and punching a hole in the panel to mount one is a difficult thing to do.

As a compromise, the Transponder can house a DME receiver, and display both DME distance, as well as DME ICAO ID.

1 Like
4

Now you know why it “Appears” to work in the default ASOBO planes :slight_smile:

Effectively, adjusting the AP’s Baro has no effect !!!

5

Ironically, Carenado may be doing the Gauges right (after all, they are copies of FSX gauges, where things did work correctly) … and the issue is caused by the Asobo incorrect model for the AP processing.

6

I was talking about the altimeter, not the AP. The default plane altimeters work just fine and are correctly correlated to the correct barometric pressure, even when you press B. The Carenado plane altimeters last time I checked were way off, by about .08 inHg. Again, the AP has nothing to do with the altimeter per se, or, as you noted yourself, shouldn’t anyway.

I have yet to get a Carenado AP to work properly, but, I chalk that up to my own inexperience. I’ve only tried to use it on an approach a couple of times, and I couldn’t get it to hook up, and, when I’ve used it enroute, I didn’t really know what I was doing, and all I was asking it to do was maintain current altitude, which it did after a couple of tries.

I don’t see that Asobo has done anything incorrectly about air pressure. When I compare ATIS to actual ATIS, they are usually within .01 or .02 of the current actual ATIS, and it’s possible they are using a different time METAR.

All this stuff you’re saying about Barometric pressure and the AP in the Cessna I haven’t experienced myself. The few times I’ve used an AP in the Cessna, it’s followed the altitude of the approach Exactly, following approach plate values (surprisingly so to me that I got it to work :slight_smile: ). Granted, the Approach I used most often was one I wrote myself. I have no idea about the accuracy of the in game approaches. From what I’ve read, NavBlue was a really bad choice for providing nav data.

(wind is a different story depending on the day. It seems like Asobo sets ATIS wind by the gusting value, IOW, the last value in the Wind value, as opposed to recognizing that G in front of it, as opposed to the actual base wind value.

7

Ok, I’m reading what you wrote in more detail now. And I’m not sure what you’re asking.

It seems like you’re asking where the AP gets it’s current altitude from? Or, you’re saying it should be wrong, but, somehow it’s not?

Have you looked at the gauge code in the default KAP140’s ? or other autopilots?

1 Like
8

Try reading it again, with reference to the better written text in the quote/

The AP is somehow getting its altitude reference from the Transponder’s Baro Sensor.

Yes, I am VERT familiar with the code I am Modding … :slight_smile:

The Code is an “Indexing” mess, and may depends on what other instruments are in the plane, which is crazy for common gauge code to be shared between different planes.

9

So, I finally get what you’re trying to say. You’re a little incorrect in your interpretation of what the AP is doing (it’s not using the baro from the transponder), but you were totally correct that the transponders are incorrectly written. They are using the “indicated pressure” sim variable (as is the autopilot, correctly so), and when you hit the B key, it changes the stored barometric pressure and therefore updates the altitude of the Transponder. It shouldn’t do that.

It’s ok that hitting the B key changes the standard barometric pressure in the autopilot, the pilot should be doing that anyway, as this autopilot has altitude features.

But, as far as the transponders are concerned, instead, the Transponder should be set by accessing the Pressure altitude sim variable. IOW, it should display the altitude that would be shown if the Altimeter were set to 29.92 inHg. This is hardcoded in the Transponder and not accessible to the pilot.

If anyone would like more realism, I can release updated standard transponders to the wild (KT76c, AS330, AS21). The only thing it does is display the altitude in the display of the Transponder as the Transponder would actually display it (confirmed by reading the manual of the KT76c). The altitude displayed on the Transponder will not match the actual altitude unless barometric pressure is 29.92 inHg.

1 Like
10

That’s it … you got it … :slight_smile:

That’s the easy part … getting Asobo to fix it, is the difficult part, before a flood of 3rd part plane are released, depending on incorrectly coded Asobo Gauges .

11

Posted a similar question in props but got no clear reply

I know this has been referred to before but there does not seem to be a definitive answer that I can find

I know the mods are loaded alphabetically , but are numbers before or after letters?
which is first 01Working title, or Working title??
What is the order of loading

How do we load types of mods
ie
Scenery>aircraft l(like c172mod) >livery>cockpit mods>gauges (like g1000)
or something else??
numbers load before or after letters??
Is there a definitive answer ?? I am sure many are confused as large numbers of mods are now available

Please straighten me out

Steve

12

The naming of the scenery/mods doesn’t matter. Loading files inside the scene matters.
For example.
Community/Livery01
Community/Livery02
it’s doesnt matter in most situation. Only if all files inside scenery will overwrite other files.

Community/Livery01/SimObjects/AirPlanes/zzz_Asobo_A320_NEO-TEST - low priority
Community/Livery02/SimObjects/AirPlanes/aaa_Asobo_A320_NEO-TEST - high priority

13

To help this propensity for your Longitude to climb when you disconnect AP, try to trim for straight and level flight before you turn on AP.

14

I love proper Englandish. Ta

15

NO, I was 100% correct (Unfortunately) … The Asobo MSFS has the AP using the Pressure sensor from the Transponder, and not the correct Pressure sensor, the AP would be using, (in RW) that is adjustable by the Pilot.

This is correctable, but requites a correct .cfg file, in a MOD, to override Asobo’s .cfg file, that is hidden in a .fsarchive file.

I am 100% confident that I am correct, after spending some considerable time, analyzing what is incorrectly happening, and then correcting it, so it operates correctly.

While, what is currently coded in MSFS is wrong, ironically, it is wrong in two places, that approximate to cancelling each other out, so on the surface, it “appears” as if it is working correctly, provided you use the “B” key to set the altimeters, and don’t rely on manually adjusting both the Panel Altimeter and the AP pressure sensor via the AP’s controls.

16

Here’s my point. If you removed the Transponder, the Autopilot would still work. The Autopilot does not depend on the Transponder in any way.

There are 3 barometric sensors in every plane. IOW, MSFS keeps track of the Standard pressure altitude in 3 memory locations. Then there are three independent “Indicated Altitude” memory locations. Completely separate from the gauges. Each gauge can access any of these “pressure sensors”, just like it would be in a real plane, where the transponder would be connected to its own pressure sensor that is somewhere in the plane, and the altimeter has it’s own pressure sensor. The Autopilot is also accessing a pressure sensor.

What you’re interpreting incorrectly is what the “B” key does. It resets all three “Indicated Altitude:x” values to the current Indicated Altitude based on the current actual barometric pressure.

So, you change the Kohlsman on the Altimeter, which is affecting only “Indicated Altitude:1”, and “Indicated Altitude:2” and “Indicated Altitude:3” are different from that, and they can be different than each other. Then you hit the “B” key, and all 3 “Indicated Altitude:x” values now equal each other at the current barometric pressure.

As we discussed, the problem with the Transponders is they are accessing “Indicated Altitude:3” instead of “Pressure Altitude:3”. As I said, when I corrected that in the Transponders, they were no longer affected by the “B” and always correctly displayed the altitude as if pressure was standard pressure 29.92 inHg. I think I sent you my corrected Transponder gauges?

As far as the Autopilot is concerned, keeping it as using the altitude it uses equal to “Indicated Altitude:x” (2 in the case of the KAP140, or the second altitude sensor), means that when you press the “B” key, it corrects to the current altitude pressure, just as if you turned the Kohlsman knob on the altimeter, because all three “Indicated Altitude:x” values get set to the current pressure altitude.

If you want to change that so pressing the “B” key doesn’t automatically set it to the correct Indicated altitude (as if you were setting the Kohlsman knob on the altimeter), you’ll need to set the autopilot to use the (standard) “Pressure Altitude:2” + equation based on the value you’ve set with the knobs on the AP for indicated pressure. Then, the “B” key will not affect the Autopilot’s altitude that it’s using.

17

If your happy with what you believe, I am happy with you believing that .
I do not feel the need to keep trying to explain this to you …

18

Here’s the code I’m talking about from the Autopilot

getBaroHPa() {
    return (fastToFixed(SimVar.GetSimVarValue("KOHLSMAN SETTING MB:2", "Millibars"), 0)).replace(/\d+(?=(\d{3}))/, '$&,');
}
getBaroInHg() {
    return fastToFixed(SimVar.GetSimVarValue("KOHLSMAN SETTING HG:2", "inHg"), 3);
}
getAltitudeDifference() {
    return Math.abs(SimVar.GetSimVarValue("INDICATED ALTITUDE:2", "feet") - SimVar.GetSimVarValue("AUTOPILOT ALTITUDE LOCK VAR", "feet"));
}

If you don’t want the “B” to affect it, you’re going to have to create new variables to store the gauge setting to replace the values being retrieved from “Kohlsman Setting MB:2”, “Kohlsmand Setting HG:2” and “Indicated Altitude:2” and calculate the indicated altitude you want from the “Pressure Altitude:2” and the values stored in those slots and I think set “Indicated Altitude:2” yourself.

This is the code from the Asobo KT76 to hold the altitude value it displays:

getAltitude() {
    return SimVar.GetSimVarValue("INDICATED ALTITUDE:3", "feet");
}

This is how I corrected the Transponder to correctly display Standard Pressure altitude

getAltitude() {
    return SimVar.GetSimVarValue("PRESSURE ALTITUDE:3", "feet");
}

I could have used “Pressure Altitude:1, 2, or 3” it wouldn’t have mattered, it would still display the correct value.

19

And I want to say, regarding what I said about the Autopilot, I don’t know that you have to set “Indicated Altitude:2” yourself, but it will take some study of the logic so the gauge uses Pressure altitude and your setting, and doesn’t access the automatically reset “Indicated Altitude:2” value.

20

Ok, one more try… I’d have to do testing to see if hitting the “B” key resets the “Kohlsman Setting xx:xx” values. If it doesn’t, then the software is short circuiting the equation by using “Indicated Altitude:2”.
It should instead use some equation to calculate indicated altitude from pressure altitude and the kohlsman settings (in the 2nd register).

If it does reset the “Kohlsman Setting xx:xx” values, then, you’re going to have to store the values being displayed in the gauge yourself and then use those independent stored values with the pressure altitude to calculate the actual altitude that you want to be using.