Something is amiss with that screenshot, but it shouldn’t be the airspeed conversion. The error in pre-SU5 wouldn’t have even made a difference at that speed and altitude.
Thanks. I have never worked directly with the FDEs of any FSX or MSFS model.
Would the offset be applied to the raw IAS variable “AIRSPEED INDICATED” before being displayed on the analog or digital airspeed indicator, or does it modify the actual base sim variable itself? The reason I ask, is that I have been monitoring all the air data sim variables on each flight since SU5 HF2, and the IAS sim variable and the airspeed displayed on the ASI are always identical.
I am sorry, I don’t understand the question. Which offset, the position error? The IAS simvar and IAS shown on the indicator should always be the same. It will be different than the CAD simvar if the cockpit.cfg file has a position error defined in it.
That’s what I would have thought, since that is how a real ASI works. I guess MY question is: which is the CAD sim var? (formal name of the variable), as I had not found something equivalent to that in the list of sim variables, though I may have been looking in the wrong reference material.
I assume the CAD variable is used by the FDE for aerodynamic calculations involving the effect of airspeed on the flight model?
Typo on my part. CAS simvar, EDIT - though I guess I shouldn’t call it a simvar. I don’t know that there’s an actual simvar for it. I’m just used to reading it off the debug airspeed screen in the aircraft editor in debug mode.
1 Like
This is with clear skies and no wind. I’m definitely no expert, but I love reading the expert comments.
I’m willing to bet that it is being caused by overzealous density error calculation.
I might be wrong, but there’s always 1kt of wind usually in MSFS, even at its lowest
Havent test 0wind in a long time though
I’ll test on my side
Absolutely nothing to see here folks. Here is approx the same shot as the original, but in dev mode with the debug airspeed window showing so you can read all the airspeeds:
Note that the true airspeed is equal to the ground speed (no wind). Also note that there is only a one knot difference between the true airspeed and the calibrated airspeed. This is also correct. See this screenshot showing the conversion between KTAS and KCAS (within roundoff):
Last, but not least, notice the relatively large difference between KIAS and KCAS. This is due to airspeed indication error. Is this magnitude correct? I couldn’t tell you. But, I can tell you it is exactly what is coded in the cockpit.cfg file for this airplane (Cessna 172SP with Garmin 1000):
The first value (1.1236) is a scalar. The 2nd value (-13.4) is an offset. Apply the offset first to KCAS, then the scalar, to get KIAS. In other words, take 85, subtract 13.4, then multiply by 1.1236. What do you get? 80, which is the indicated airspeed.
No “overzealous density error calculation,” whatever that may be, or any other error. MSFS SU5 does airspeed conversions correctly (except for the very small areas where the atmospheric parameters are still a bit off).
1 Like
Thanks Awareplot - the dev mode readout is helpful.
In which case it appears that instrument/position error are calculated incorrectly for the C172S.
The difference between KCAS and KIAS should not be +5kts at 80KIAS:
Is someone here surprised…
I think you mean it is not represented accurately in the cockpit.cfg file. The airspeeds are calculated correctly for the given inputs. Since you have the data, you can now modify your airplane and give it the correct indicator error inputs.
1 Like
With utmost respect, the .cfg file is a direct function of the simulator and should not require modification to calculate the correct KIAS.
Furthermore, the linear function of an offset and a multiplier fail to accurately model the non-linear relationship as per the Cessna POH, as below:
That said, I am of the opinion that Asobo should focus on accurate flight/atmospheric/world models and leave [accurate] aircraft to third-party development, so it is positive to hear that the environmental aspects appear to be correct.
The problem is that it can’t easily be “calculated” by a fixed conversion formula (offset and multiplier) because the IAS/CAS relationship is non-linear.
“Instrument” error really would not be something that would likely be simulated in something like MSFS. It is simply a measure of a specific make and model airspeed indicator’s intrinsic accuracy with a known input pitot pressure. This can easily be measured on the ground on a test bench, (or in the aircraft) using a calibrated pitot-static pressure test set.
Older mechanical airspeed indicators can have substantial instrument error at the low end of their operating range, and much less at higher speeds. Modern air data computers which use solid state pressure transducers tend to have no “instrument” error whatsoever for raw dynamic pressure at any point in their normal operating range.
I suppose that an advanced add-on like the A2A series of GA aircraft in FSX and P3D might indeed simulate the known “instrument” error of a specific model of analog airspeed indicator.
“Position” error is another matter. That is caused by non-linear variations in sensed static pressure caused by airflow across the static port.
In a real aircraft, static source error can vary significantly with changes in airflow across the static port at various airspeeds and (especially) with changes in the angle of attack. The amount of error depends on the specific airframe, and exactly where the static port is located.
A digital air data computer designed for use in high performance jet aircraft will contain lookup tables to correlate IAS to CAS, and also to correct indicated altitude for airspeed.
This latter correction is especially critical in an aircraft certified for operation in RVSM airspace. All DADC’s in high-performance aircraft take pitot pressure and static pressure as inputs, along with air temperature. Most (but not all), also take an input from the angle of attack sensor(s).
The IAS vs. CAS and altitude correction lookup tables will not come from algorithms, but from data gathered during extensive flight testing.
Other air data parameters such as TAS and Mach will indeed be calculated by formulae, using CAS derived from the lookup tables.
I assume that a custom FDE for an advanced simulator add-on could use similar lookup tables to give correct CAS results across the entire flight envelope, rather than relying on a fixed conversion formula.
2 Likes
Thanks HalberQuacky,
I imagine this could be simulated formulaically or via lookup table, or a combination of both. Either way, as you say, instrument and position errors are extremely airframe/equipment dependent and I certainly wouldn’t expect Asobo’s models to be of such high fidelity. However I hope that this is able to be corrected by third-party developers, despite Asobo wanting to keep the flight model under wraps.
It has been a long time since I’ve used FSX but I don’t remember there ever being such a significant difference between TAS/CAS and IAS at ‘normal’ angles of attack. It would make for an interesting test if that is potentially where this code has come from.
Me thinks you’re making this much too difficult. We’re dealing with a simulation, not a real airplane/atmosphere. Indicator and position error must all be added; they do not exist in the simulator like they would in real life. There is no actual pitot tube, nor any static source that may not read the exact static air pressure. For airplanes with digital air data computers, there is no correction needed in the simulation. CAS is calculated from TAS, and IAS is made equal to IAS. No need for simulating the actual lookup tables unless you for some reason wanted to simulate some residual error that may exist after using those tables (due to airframe or static source accuracy variability or something).
The instrument error simulation provided for by the MSFS (and previous FSX) config files are simple linear relationships. Developers have the option of going beyond that to program their own gages to include more complex relationships (as you assumed).
I don’t understand the desire of some to want to conduct more “tests” of this sort. It is all very straightforward and documented in the FSX SDK.
The big advance in MSFS SU5 is that the conversion between TAS and CAS, which has been incorrect since FSX days, has been fixed. None of these other aspects being discussed (airspeed indicator error or static source error) have been changed or need to be changed.
5 Likes
I completely agree.
There was lots that I didn’t know there, thanks.
I think we’ve more than answered the OPs question.
2 Likes
As has the relationship between CAS and Mach at a given pressure altitude. That has been wrong (at altitudes above ~FL250) since FS9, and every developer of complex airliner add-ons in FSX and P3D (that operate at the flight levels) has had to write a custom conversion to derive displayed IAS from the Mach sim var, rather than using the native IAS sim var directly. I was pleasantly surprised while doing some test flights between FL300 and FL 390 in SU5 HF2 to find that long-standing bug appears to have been fixed.
2 Likes
Yes, that’s the same bug.