Auto TAS Calibration with GPS

[Etienne]

*heave*

What's the progress with this very useful feature? I am also suffering with a constant headwind...

 

[PhantomPholly]

I never went to test pilot school, but the Phantoms I flew all had a readout for CAS. My fuzzy understanding was that it compensated for all kinds of things including compressibility factors at high Mach; temperature; altitude; and attitude changes at slow airspeed which caused a high angle of incidence of the Pitot tube and potentially disturbed the static readings.

I know that my Lancair 235 had significant static issues - it worked down low at "normal" cruising airspeeds (generally matching GPS within a knot and a few feet of altitude at cruising speeds) but that it got progressively worse with altitude or low airspeed. Haven't spent enough time in my 320 to compare yet, but I have read that many Lancairs have imperfect static locations - not enough to prevent flying the airplane, but enough to give false indications of TAS.

So, rather than try to "fix" IAS why not just add CAS and use your own method of calculating / adjusting it? Or is that what we are already saying?

Also - all of my GPS's have generally agreed within a few feet for altitude - why do you say they are not accurate? I even did a "close pass" of a mountain peak of known height, and my GPS appeared to be significantly closer to the correct altitude than my baro.

If anything, I would thing that GPS at least gives a more CONSISTENT altitude readout, and might be a good candidate to replace baro for tight vertical spacing...

 

[khorton]

So, rather than try to "fix" IAS why not just add CAS and use your own method of calculating / adjusting it?  Or is that what we are already saying?

There is no way to independently calculate CAS with the information that is available in the EFIS.  The only way that Dynon can determine CAS is to calculate IAS (using the pitot and static pressures), and then apply some correction that would have to be based on data provided by the user.  E.g. - it could be a table of corrections to apply at different speeds, or a correction that was a function of AOA (if the Dynon AOA/pitot probe was being used).  Quite a bit of flight testing would be necessary to determine the corrections for each specific aircraft.   Another problem would be that the correction between IAS and CAS would likely change depending on flap position.

Also consider that if there is a difference between IAS and CAS, this is almost certainly due to static source position error.  Thus the displayed altitude will have errors too.  The errors in altitude should be acceptably small (i.e. less than 100 ft) in the vast majority of cases, unless there are large (greater than 10 kt) differences between IAS and CAS.

Personally, I would love to have way to input static pressure error corrections to the EFIS, to improve the accuracy of the displayed IAS, TAS and altitude.  But I recognize that not many people would be prepared to expend several flights gathering the data required to provide the corrections to the EFIS, so I know there is not a rational business case for this feature.

In many cases, OAT errors are also probably affecting the accuracy of the displayed TAS.  Many OAT probes are installed in locations that allow cabin air to heat the back side of the probe.  Also, for faster aircraft, ram temperature rise affects the temperature sensed by the probe.

If all we care about is accuracy of the TAS display, and we are happy to ignore errors in the IAS and altitude, then the simplest solution is to allow users to provide a table of corrections to TAS as a function of IAS (or perhaps TAS).  These corrections would be determined by classical airspeed error flight testing, and they would account for EFIS instrument error, static source position error and OAT error.

Also - all of my GPS's have generally agreed within a few feet for altitude - why do you say they are not accurate?  I even did a "close pass" of a mountain peak of known height, and my GPS appeared to be significantly closer to the correct altitude than my baro.

GPS altitude and barometric altitude are two different things.  It is completely normal, and correct, that they will differ.  The difference will increase as we increase the altitude above the source of the altimeter setting.

Don't confuse GPS altitude with barometric altitude.  If you are tying to measure the height of a mountain, then GPS altitude is the thing you want.  If you are trying to fly at a particular altitude in the airspace system, then barometric altitude is what you want.  

 

[Etienne]

The accuracy of TAS messes around with the winds aloft calculations... You can't really have a correction table for that, unfortunately... Anyway, the way I was taught
IAS is a pressure difference reading between pitot and static
CAS is IAS corrected for static port and construction errors
TAS is CAS corrected for altitude and temp...

So in my world, you can't really have TAS without CAS... But I live in Africa

Oh yes, and regarding the Baro alt and GPS alt:
GPS alt is your elevation above a calculated mean sea level called the WGS84. It's not perfect, but good enough for most applications.
Baro alt (assuming you have a very accurate and correct-for-that-spot QNH) should be rather close to actual trig-beacon altitude. The trig beacons' heights are determined from the real mean sea level and calculated using short hops from one mountain top to another. This should be the altitude displayed on maps (even for airfields).
If you're flying on a QNH given to you by an ATC 15 miles away on a services frequency, then your baro alt will probably be different to the GPS alt, because the QNH fluctuates by a significant amount from one place to another, even if separated by a small distance. That's why we have winds. Now everybody flying in a similar area has to be on the same QNH, even if it is slightly out, otherwise there would be a greater chance of an accident!. Imagine a single baro altitude (say 5000') being like the surface of a large, puffy duvet. As two aircraft approach the same point, if they're flying ob the same QNH and altitude, then when they arrive at the same place they will be at the same actual height, but the journey there, even though the altimeter hasn't moved a hairs-breadth from 5000' their actual altitude above sea level (and GPS altitude) will have fluctuated by probably more than 50'...

 

[PhantomPholly]

Thanks for both answers.

When I said my baro was "different," I was referring to rather significant errors (sometimes over 500' variance from GPS at 14,500' - rather disturbing if an aircraft bound the other way had the opposite error!) in my previous aircraft. That was undoubtedly due to poor placement of the static port, but to fix would have required placing new holes in my slick fuselage and experimenting to find a better location. Since the error was rather linear with altitude, this is the sort of installation error I would expect could be overcome with a function which builds a history of the difference between baro and GPS, which pretty much won't vary, and other parameters such as QNH, temp, and airspeed - which will vary. Although not strictly adhering to the theory of what CAS SHOULD be, for purposes of how most of us fly I still think it would be very useful. In computing, it is not necessary to let the user know HOW a calculated value is derived, only that it be suitable to the purpose for which it is intended.

My goal (and it may well be different from the goals of others participating in this thread) would be to get baro corrected to within around 25' and airspeed within a couple of knots of where they should be theoretically under virtually every flying condition - no matter how that is accomplished. Thus, a matrix history table of measured parameters plus a table of theoretical values ought to be able to interpolate a suitable correction under a wide variety of conditions despite many compensating errors. With this correction, CAS and baro should then be accurate even if your installation is not perfect. If the system monitored and recorded GPS conditions and continually compared those to pitot-static readings, it should be possible for the computer to do all of the necessary "test flying" without pilot intent or involvement.

That's my theory, anyway...

 

[khorton]

Thanks for both answers.  

When I said my baro was "different," I was referring to rather significant errors (sometimes over 500' variance from GPS at 14,500' - rather disturbing if an aircraft bound the other way had the opposite error!) in my previous aircraft.  

Unfortunately, although you may have read the answers, you don't appear to have yet understood them. Perhaps I was not clear enough. I'll try again. 

GPS altitude and barometric altitude are quite different things, and they would normally be expected to be different.  It is somewhat like comparing two thermometers, one that reads in degrees Fahrenheit, and one that reads in degrees Celsius.  If the two thermometers show different numbers, does that mean that one is right and one is wrong?

Lets go back to basics.  A barometric altimeter, like we have in our aircraft, measures air pressure.  The air pressure changes with altitude because the air at low altitude is being compressed by the weight of all the air above it.  The air at higher altitude has less weight of air above it, so the pressure is lower.  The relationship between pressure and altitude depends on the air density.  If the air was more dense, the weight would fall off quicker as the altitude increased, and the pressure would go down more quickly as the altitude increased.  Or, looked at another way, if the air was denser, we would need less thickness to have the same weight (and hence pressure) at the bottom.  So the pressure would decrease quicker with altitude as we went up.

Air density varies with temperature, pressure and humidity.  The International Standard Atmosphere (ISA), based on measurements taken all over the world, describes an atmosphere of average pressure, temperature and humidity.  Our barometric altimeters are calibrated to have the relationship between pressure and altitude that one would find if the actual atmosphere matched the ISA.  But, on any given day, in any given place, the actual conditions vary.  Variations in sea level pressure are accounted for by changing the altimeter setting on our altimeter.  But, our altimeters don't have provisions to correct for changes in temperature and humidity (this is a bit of a simplification - the full story is too long to put here).  Thus the relationship between pressure and actual altitude usually varies from that which our barometric altimeters were designed for.

Imagine that you are on the top of a 14,500 ft high mountain, looking down at an airport in the valley, with the airport at 500 ft above sea level.  You have radio contact with the airport, so you know what the altimeter setting is.  You have your GPS with you.  If the temperature and humidity on this day happen to match ISA conditions, and you set the altimeter setting from that airport in the valley into your altimeter, the barometric altimeter should show an altitude that matches the actual height of the mountain, as would your GPS (plus or minus the expected accuracy of each device).  But, if the temperature happened to be colder than ISA, the barometric altimeter would show an altitude that was higher than the actual altitude of the mountain.  If the temperature was warmer than ISA, the barometric altimeter would show an altitude that was lower than the actual altitude of the mountain.  The expected difference between barometric altitude and actual altitude is approximately 0.4% for every degree C that that actual temperature varies from standard.  If the 14,000 ft thick column of air between the top of the mountain and the airport had an average temperature that was 10 deg C warmer than ISA, we would expect a difference between the barometric altimeter and the actual altitude of approximately 0.4% times 14000 ft times 10, or about 560 ft.  But, all aircraft would have this same error, so it would not cause a safety problem with separation between air traffic.  If could cause terrain clearance problems in cold temperatures though - in Canada this is covered by applying cold weather corrections to approach minima, and in the US it is covered by ensuring the approach minima are high enough to cover the coldest temperatures expected in that area.

The bottom line - comparing your GPS against your barometric altimeter is telling you nothing about how accurate your barometric altimeter might be.  There are other ways to answer this question.  If you are interested in one approach, see Determining Static System Error on my web site.

 

[PhantomPholly]

Unfortunately, although you may have read the answers, you don't appear to have yet understood them. Perhaps I was not clear enough. I'll try again.

Hmmm, starting out like that you aren't liable to get many listeners.

As it turns out, however, it was neither the clarity of your writing nor my reading of it; it was merely your failure to respond to the actual statement I posited.

What your statement essentially asserts here is that it is not POSSIBLE to derive what a baro instrument SHOULD read given access to GPS and other local conditions. This is patently untrue, no matter how many websites you have. If there were not such a method for determining what the "right" measure should be, they would never have been able to rely upon it in the first place.

Based on factors you have mentioned the Dynon CAN (if all the appropriate sensors are installed) have access to sufficient environmental information (local baro setting, OAT, ground speed, GPS altitude) to compute a good usable approximation of what baro SHOULD read, excepting humidity. Humidity correction, however, is not the argument you made. Nor is it sufficient to say that there MAY be errors in other instruments (e.g. OAT). These too can be accounted for if we suspect they are predictably wrong - but THIS exercise is about correcting static port placement errors and using that adjusted variable, with others, to derive a better representation of baro altitude and a close approximation of "CAS." Now, if humidity would frequently account for more than 75' of error if off by less than 50% in the calculation, then that may be a stumbling block - but I suspect given GPS altitude and ground speed and indicated speed and OAT the computer could make a pretty good guesstimate to plug in for that factor. Certainly it would be better if the pilot could plug in temp and dewpoint and field elevation reported of the nearest airfield.

The point is that we don't need perfect measures on all inputs to derive a correction which IMPROVES our current readings. Obviously, the better the information you start with the less adjusting you need to do and therefore the closer to "perfect" it will be. Yet any improvement is still an improvement. It will still be "wrong," but in our world a "reasonable" wrong is often good enough. Given that all of these environmental factors can be held to be reasonably accurate, it should be possible through historical matrixing combined with current GPS and currently measured environmental variables for the computer to apply corrections which will be much closer to accurate than the original situation I referenced - all without pilot intervention.

Not perfect, but probably within acceptable parameters and certainly better than no correction at all.

Perfection costs more money than most of us can afford.

 

[PilotKris]

I see Kevin, the Static Source Position Error Crusader is at it again. He is bound and determined to stamp out SSPE...

While EFIS and ADC offer the ability to program out SSPE in both altitude and airspeed, the effort and added complexity of programming end-user correction values is, in my opinion, just not worth it. I'd like to see Dynon focus their efforts on other enhancements (like synthetic vision) than giving end-users the opportunity to introduce additional errors into their displays.

99.9999% of end-users just don't have both the flying skills and knowledge necessary to accurately determine what the SSPEs are throughout the flight envelope and then program those values into the EFIS. Even if they did have the skills, they'd also have to spend quite a lot of time do it. End-users are far more likely to screw things up than make things better.

I applaud Kevin's efforts to raise SSPE awareness and get builders to fix the problem mechanically (proper position and shape of the static source) as it addresses the illness, not just the symptoms.

Oh, and Phantom's idea of making the units "auto-correcting" won't work for several reasons. Two of the biggest are:

1. Would need 100% accurate Baro setting 100% of the time which is simply not possible (Garbage In, Garbage out).
2. WIND!

Let's not forget that even if we could get 100% accuracy in out Pitot Static instruments, they are still limited in accuracy by their very nature.

LOCAL altimeter setting is determined by what is observed from a local pressure instrument. It, by its very nature, is already compensated for temperature and humidity. It can be used by aircraft for terrain clearance in the local area only.

AREA altimeter settings were never expected to keep airplanes from hitting terrain. They are only meant to keep airplanes from hitting each other (and provide limited accuracy for terrain).

Above 18,000, we don't even care about the absolute accuracy of pressure altimeters. We only care about their accuracy relative to each other. Errors due to humidity, temperature, variations in air mass are absolutely irrelevant.

GPS derived altitudes (while they can be very accurate) have very little use in aircraft other than for limited terrain clearance.

PilotKris

 

[PhantomPholly]

I see Kevin, the Static Source Position Error Crusader is at it again. He is bound and determined to stamp out SSPE...

While EFIS and ADC offer the ability to program out SSPE in both altitude and airspeed, the effort and added complexity of programming end-user correction values is, in my opinion, just not worth it. I'd like to see Dynon focus their efforts on other enhancements (like synthetic vision) than giving end-users the opportunity to introduce additional errors into their displays.

99.9999% of end-users just don't have both the flying skills and knowledge necessary to accurately determine what the SSPEs are throughout the flight envelope and then program those values into the EFIS. Even if they did have the skills, they'd also have to spend quite a lot of time do it. End-users are far more likely to screw things up than make things better.

I applaud Kevin's efforts to raise SSPE awareness and get builders to fix the problem mechanically (proper position and shape of the static source) as it addresses the illness, not just the symptoms.

PilotKris

lol - well, if the only way to actually implement such a solution would be to have the user input values, I'd have to agree with you 100%. That dawg ain't gonna hunt...

And it may indeed be more complicated than I believe it to be.

On the other hand, if I knew exactly what the factors were (where to find the appropriate charts and tables to do the conversions) I could probably make a pretty good stab at an algorithm to record and use the data appropriate for the system to "guesstimate" a correction.

Thinking about it some more, however, and I realize the real challenge (as usual) isn't technical.

It would be a legal challenge for Dynon to offer such a solution. Even if the data were "better" after correction, some idiot would crash and have their lawyer blame the software.

The only platform that could safely use a solution like this would be something like the Enigma (which allows users to add their own software extensions).

Dynon -disregard this request. I want you to stay in business to support my EFIS!

 

[khorton]

Hmmm, starting out like that you aren't liable to get many listeners.

Sorry, I was a bit cranky that despite all my effort to convince you that GPS altitude was not the same thing as barometric altitude, you hadn't appeared to have gotten the message.  

As it turns out, however, it was neither the clarity of your writing nor my reading of it; it was merely your failure to respond to the actual statement I posited.

Hmm.  Now it is my turn to not understand.  Which of your statements has not yet been addressed?

Based on factors you have mentioned the Dynon CAN (if all the appropriate sensors are installed) have access to sufficient environmental information (local baro setting, OAT, ground speed, GPS altitude) to compute a good usable approximation of what baro SHOULD read, excepting humidity.

I wish it was possible to distill one year to training at test pilot school and 20 years of experience into a few short paragraphs, but that cannot happen.  So, please understand that my statements are crafted to attempt to provide clarity on specific aspects of the problem.  They should not be relied upon to provide complete knowledge of all aspects of the problem, as there simply isn't enough room to cover all possible bases.

I agree 100% that it is possible for Dynon to provide a way for users to give the EFIS corrections so it can provide more accurate barometric altitude, CAS, TAS, etc.  But, they cannot rely on GPS altitude as part of this solution.  I wish things were as simple as you suggest, but the laws of physics won't cooperate with us.  If you study the equations that describe how pressure varies with altitude, you will see that we would need to know how temperature (and to a lesser extent humidity) varies over the full altitude range between the source of the altimeter setting and our current altitude.  That information is not generally available, so there is no practical way to start with GPS altitude and arrive at a reasonably accurate barometric altitude.

The best way to address this issue is to resort to one of the classical flight test techniques - the speed course method.  In the old days this method relied on ground speed measurements from a stop watch and reference points on the ground.  Now days we can use GPS ground speed, which makes this method much more accessible.

For another perspective on how GPS altitude compares to barometric altitude, try this.

 

[PhantomPholly]

Sorry, I was a bit cranky that despite all my effort to convince you that GPS altitude was not the same thing as barometric altitude, you hadn't appeared to have gotten the message.

No worries, just a case of "email being the best way to derive disagreement from people with the same opinion." And in truth I was not much better, although my final response was somewhat tempered from my original draft...

Hmm. Now it is my turn to not understand. Which of your statements has not yet been addressed?

Well, now maybe you have addressed it and I didn't recognize it. Sometimes 20 years' experience is a disadvantage. Well, frequently, when talking to others not in your vocation.

I get the variable compressibility of gas. I also get that GPS may not describe a perfect sphere around a supposed theoretical center of the planet. However, the fact that the GPS has an algorithm to determine an "altitude" based on known 3 dimensional coordinates means that, for all practical purposes, GPS gives you an "absolute location" relative to the surface of the earth.

So, stating what I originally posited as an assertion in the form of a question...

Assmptions:
- You know an absolute location in space through GPS
- You have a good "approximate" (closest airfield could be a couple of miles away laterally / vertically) baro setting from ATIS
- You have an OAT not totally out of whack - say within a couple of degrees
- There are otherwise no unusual weather gradients at your exact location that would give you an "unusual pressure gradient" between the surface and your altitude (this is never true for ONE location, but would be statistically true for a system averaging across many days and locations)
- You pick a humidity range from a list of "Visible Moisture; Damp; Normal; Dry; Very Dry" to get you within +/- 20% (again, I think you could ignore this if averaged across many different days and flight conditions)

The Question:
Should you or should you not be able to CALCULATE what an accurate baro altimeter SHOULD read (e.g. +/- 75') given that information?

Given the above (which may be a stopper, and I will take your word as an expert in this field either way if you will please keep your answer tailored to my sort attention span), it is my belief that you could then deduce the correct static adjustment. It would then follow that you could then use that adjusted static value to derive a "better" CAS irrespective of GPS groundspeed (most folks seem to think that pitot angle is a small factor over most regimes of everyday flight).

I wish it was possible to distill one year to training at test pilot school and 20 years of experience into a few short paragraphs, but that cannot happen. So, please understand that my statements are crafted to attempt to provide clarity on specific aspects of the problem. They should not be relied upon to provide complete knowledge of all aspects of the problem, as there simply isn't enough room to cover all possible bases.

I haven't got 20 years of test pilot school, although I studied the basics in UPT and have flown supersonic (now what was it I used to fly?...). On the other hand, I deal every day with both business people who think computers are magic and programmers are lazy, and with programmers who think business people are crazy and stupid. Both are right, by the way...

;D

Anyway, I don't think it will take you more than a couple of paragraphs to validate or invalidate my theory, stated as a question above. I don't have enough brain cells left to wade through the full answer (and I did look at your links).

But alas, it is all moot. As I belatedly realized, Dynon would be foolish to offer such a solution or I would offer to write the code myself. The legal eagles would swoop down on any engineer foolish enough to suggest an algorithm providing INTERPRETATION of baro information - why, its' mere existence would be a challenge to lawyers everywhere to claim that it erred and caused an accident, even if the cause of hitting the ground were dry fuel tanks. And some stupid jury would agree with them.

 

[Etienne]

Despite the legal problems associated with the Baro calibration, is there anything stopping a TAS calibration, or even just a winds-aloft calibration?

By flying in a triangular (or even easier to calculate, a square) pattern, the correct TAS and winds can be calculated... When I fly long distances, it's usually at the same speed and altitude, so even just a single calibration would provide a much more accurate readout for 80% of my flying...

 

[khorton]

I get the variable compressibility of gas.  I also get that GPS may not describe a perfect sphere around a supposed theoretical center of the planet.  However, the fact that the GPS has an algorithm to determine an "altitude" based on known 3 dimensional coordinates means that, for all practical purposes, GPS gives you an "absolute location" relative to the surface of the earth.

So, stating what I originally posited as an assertion in the form of a question...

Assmptions:
- You know an absolute location in space through GPS
- You have a good "approximate" (closest airfield could be a couple of miles away laterally / vertically) baro setting from ATIS
- You have an OAT not totally out of whack - say within a couple of degrees
- There are otherwise no unusual weather gradients at your exact location that would give you an "unusual pressure gradient" between the surface and your altitude (this is never true for ONE location, but would be statistically true for a system averaging across many days and locations)
- You pick a humidity range from a list of "Visible Moisture; Damp; Normal; Dry; Very Dry" to get you within +/- 20% (again, I think you could ignore this if averaged across many different days and flight conditions)

The Question:
Should you or should you not be able to CALCULATE what an accurate baro altimeter SHOULD read (e.g. +/- 75') given that information?

Sorry, but this is not possible to the accuracy that you hope.  To do this with sufficient accuracy, you would need quite accurate knowledge of how temperature varied with altitude all the way between the source of your altimeter setting and your altitude.  On any given day, the variation of temperature with altitude is often quite different from that assumed by the International Standard Atmosphere.  The size of the typical variations are more than enough to make your proposed method quite inaccurate, unless we were close to the ground (perhaps on the order of 1000 ft AGL).  

Even if we made test measurements on many different flights, at different times of the year, the average temperature variation with altitude would likely differ from ISA, as the ISA is based on measurements from all over the world - it does not necessarily represent the average conditions seen in any given area.  Maybe if you did a sufficiently large number of tests, in a large number of locations, the average of all results would start to converge on the right answer.  But it would be much easier to simply use an already established test technique that could give the result you want in two or three flights.

The test method you propose is similar to one of the standard test methods to determine static system position error (called the tower fly-by method), so you are not completely out to lunch.  But in the tower fly-by test method, the errors are minimized by putting pressure and temperature sensors on a tower, having the aircraft fly by the tower, and using a camera and some trig to determine the altitude difference between the aircraft and the pressure sensor.  The altitude difference between the aircraft and the pressure sensor is as small as possible, usually less than 10 ft.  Over that small altitude range, the pressure is assumed to have the same variation with altitude as described by the International Standard Atmosphere, with a correction for the effect of temperature.

 

[TWTTBird]

I have a spreadsheet available to anyone who wishes which helps build a table of TAS vs EFIS displayed data. Input is 4 GPS headings and groundspeed. The headings should be roughly 90 degrees apart but they don't have to be exact. Output is 4 TAS and 4 wind vectors. The extra heading and GS allows the redundant calculations as a quality check. If an output differs by much, don't use that data point.

Email a request to: kuffel@cyberport.net

Tom Kuffel

 

[PilotKris]

I sure hope that all of this discussion is only a theoretical exercise... You're trying to polish a turd!

Pitot Static instruments are simply not accurate enough to even attempt to get the accuracy that you're wanting and toward what end? They'll still be inaccurate because of Temp./Humidity/Air mass errors. A $200 GPS will give you all of the practical information that you'll need for real world, tactical dynamic (on the go) flight planning.

What would you do with the hyper accurate information even if it were possible?

Calculate winds aloft to within 1/10 of a knot and 1 degree? It still won't change your groundspeed.

Know your true MSL altitude to within 10 feet? Still won't keep you from hitting the other airplanes that are using indicated altitude.

Know your true stall speed? You're not gonna flight plan with it so how does it help you anymore than indicated stall speed (which is marked on the A/S indicator).

Bragging rights on how fast your plane is? Heck, every pilot lies about that anyway.

You guys must have WAY too much time on your hands...

On the other hand, keep up your SSPE awareness campaign Kevin, that's a real issue that needs to be addressed by homebuilders.

PilotKris

 

[Etienne]

Try getting in to a short airstrip with no windsock. My D100 tells me there's no wind, but in reality, I have a 10mph tailwind... My rollout just increased by 30%.

That's the error I'm sitting with at the moment.

 

[khorton]

But, the IAS, TAS and wind accuracy on this landing would be same as they were when you did your performance testing to determine how much runway your aircraft needed. Runway performance testing should be done on a nice long runway, rather than doing it on the fly the first time you have a short strip to go into.

I do agree that it would be much better if the IAS, TAS and wind were accurate. But errors in those values should not cause an accident, if your flight testing was adequate.

 

[Etienne]

I agree with your points about testing being done on a long runway. This is a different scenario though...

My TAS is over-reading by about 10mph, which in no-wind situations results in a head wind indication of about 10mph.

So when on final approach a quick look at the wind info on the Dynon says that there is no wind, and all's good. Except that in the real world I actually have a 10mph tail wind... This is a big deal. My flight performance says that on a windless day, I should be able to stop in about 250m, but with a 10mph tailwind component, I'll stop in 350m.

This isn't the testing flight realm, this is day-to-day flying.

Obviously, I could do some mental arithmetic and compensation, but that's about as helpful and error-prone as not having a wind vector at all.

The fix required in this scenario is fairly trivial, certainly if we're not going for an accuracy on the TAS of 99% for all temps, alts and humidities! This is just a coarse adjustment along the lines of a mapping of a calculated TAS against a more accurate TAS, with simple straight-line interpolation between them. Even a single calibration value (the other being 0KTAS) will improve even the most mechanically correct system available.

 

[PilotKris]

Fix the problem, not the symptoms.

You've obviously got HUGE pitot static systems errors, most likey SSPE (Static Source Postion Error) if your indicated airspeed is off that much (10%+).

It isn't fair to expect Dynon to fix the problems you've built into your aircraft. Fix the problem and ALL the symptoms go away...

 

[Etienne]

Fix the problem, not the symptoms.

You've obviously got HUGE pitot static systems errors, most likey SSPE (Static Source Postion Error) if your indicated airspeed is off that much (10%+).

It isn't fair to expect Dynon to fix the problems you've built into your aircraft. Fix the problem and ALL the symptoms go away...

I hear what you're saying... I do have a SSPE, and I do intend to fix it.

I'm confused why you're so keen on this feature not being implemented though. If Dynon don't want to do it (which is contrary to what has been indicated at the beginning of the thread) then let them say so. If it is implemented and you don't want to make use of it, then don't, but don't spoil it for the rest of us.

I, however, am using the Dynon to make very accurate measurements of pretty much all the flight dynamics, and would find a very accurate TAS incredibly useful, especially over the cruising speed range! I would also like to have an accurate wind vector. Seeing as the Dynon is a digital instrument, it is capable of making corrections for mechanical and aerodynamic errors. This makes it an incredible advancement over steam gauges, which have set, and mostly linear ratios between the input parameters. A digital instrument doesn't have these constraints, and Dynon have already used this to their advantage in almost every aspect of the EFIS. (eg. Calibrating 0 KIAS)

The change that we're talking about here is probably 50 lines of code (about 2 days work for a single programmer), and it would be hugely beneficial to more than just one person.

If we can give the Dynon an edge over some other product, with a minimal amount of effort, then why not?

The same argument can be applied to a compass, be it electronic or magnetic... Why calibrate it? Because a) it's not that hard, and b) it results in a much more accurate navigation tool. Do you need to calibrate a compass? No, you can use a card that has a mapping from what the compass tells you to what you're actually flying. But it's not only a good idea, it's a legal requirement to have a properly calibrated compass. Inaccurate information is much more dangerous than no information.

Even with the world's best placed static port and dynamic pitot, there are still going to be errors. If you're lucky, they're small. If you're not lucky, or don't like having 3' probes sticking out from your spinner, along with the nightmare of feeding the pressure tubes through the crankshaft, then this feature will come in handy.

Whilst I concede that it is not the D100's place to correct vast inaccuracies in the placements of the static port (i.e. my example), I do still think it is worth the effort on Dynon's part to implement it. If they think otherwise, then so be it.

I'm bowing out of this discussion. I have contributed as much as I can.

Etienne