Auto TAS Calibration with GPS

[khorton]

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...

Fixing the problem at the aircraft level is easy to say, but not so easy to do.  The options are:
1. Do a trial and error looking for a better place to put the static port.  There is a fair bit of work to move the static port each time, and then you need several flights to get enough data to be sure you know what the errors are in the new location.  This exercise could easily take a half dozen different iterations on static port location, with two or three flights per iteration.  And there is no guarantee you will manage to find a better static port location.

2. Make modifications to the existing static port, such as putting a dam behind it to increase the sensed static pressure, which would decrease the IAS (and the calculated TAS).  But, while this modification may reduce the error to zero at one speed, the error will be different at other speeds.  There is no guarantee that a simple mod like this can produce acceptable errors at all speeds.  But, there is harm in conducting the experiment.

 

[PilotKris]

I'm confused why you're so keen on this feature not being implemented though...

Etienne

I thought I answered that already:

"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. "

That's why...

Additionally, the pitot-static/encoder system must be checked for accuracy bi-annually. The calibration equiptment would be unable to correct for (or verify) the "corrections" entered by the end-user.

Pitot-static instruments (even electronic ones) are an imperfect compromise at best. We as Pilots need to understand their limitations.

PilotKris

 

[khorton]

I fully agree that only a tiny percentage of Dynon EFIS users would expend the effort to determine the static system position errors on their aircraft.  Thus, while I would love to have the ability to correct these errors in the EFIS, I understand that Dynon must make a business case to develop this feature.  But, many purchasers base their purchasing decision on items on the feature list that they will likely never use.  Dynon may win some sales if users know that they could, if they chose to expend the effort, correct static system errors if it later turns out that their aircraft has this problem.

"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. "

We shouldn't prevent users from fixing errors just because that could allow them to make matters worse.  Taken to the absurd extreme, that would be a good argument to remove the altimeter setting knob, to prevent the case where the user sets the wrong value.

There are many possible ways to screw up pitot-static indications with the current EFIS (pitot or static leaks due to poor installation, static system errors due to poorly located static ports, plumbing the wrong tubes to pitot, static and AOA ports, flying into icing conditions with an unheated pitot tube, etc).  Significant errors would be detected during flight testing.  The possibility of a user making an error is not a sufficient reason to deny a capability, in my opinion.  I recognize that everyone is entitled to their own opinion.

Additionally, the pitot-static/encoder system must be checked for accuracy bi-annually. The calibration equiptment would be unable to correct for (or verify) the "corrections" entered by the end-user.

I would expect that any feature that allowed user supplied corrections to static pressure as a function of airspeed would be designed so the correction was zero below some low speed (e.g. if speed is less than 40 kt).  Thus no correction would be present during static system testing.

 

[PilotKris]

I fully agree that only a tiny percentage of Dynon EFIS users would expend the effort to determine the static system position errors on their aircraft.

Glad you agree

We shouldn't prevent users from fixing errors just because that could allow them to make matters worse.  Taken to the absurd extreme, that would be a good argument to remove the altimeter setting knob, to prevent the case where the user sets the wrong value.

Come on Kevin, that's a super weak argument (you can do alot better).
A wrong altimeter setting isn't the same thing as a hidden, dubiously derived "correction" that is also affecting the altitude being reported by the transponder.

There are many possible ways to screw up pitot-static indications with the current EFIS (pitot or static leaks due to poor installation, static system errors due to poorly located static ports, plumbing the wrong tubes to pitot, static and AOA ports, flying into icing conditions with an unheated pitot tube, etc).

Those errors are part of the reason why we have the requirement for bi-annual P/S checks. The airspeed indicator is also checked for errors/leaks and the testing equipment will read the "corrections" as errors.

Significant errors would be detected during flight testing.

Yes, they SHOULD be detected but, as you've already agreed, most builders can't or don't test as accurately as they should.

The possibility of a user making an error is not a sufficient reason to deny a capability, in my opinion.

Here's the problem.

The "corrections" will also affect the altitude reported by the transponder. That information is used by EVERY type of collision avoidance system out there. That means that Joe RV builder tooling around reporting the wrong altitude is screwing up our efforts to keep planes from bumping into each other. That's a potential problem for everyone (not just me).

As long as the "correction" only affects the IAS, as far as I'm concerned, knock yourself out.

PilotKris

 

[khorton]

The "corrections" will also affect the altitude reported by the transponder. That information is used by EVERY type of collision avoidance system out there. That means that Joe RV builder tooling around reporting the wrong altitude is screwing up our efforts to keep planes from bumping into each other. That's a potential problem for everyone (not just me).

I fully agree that we should do everything possible to ensure that the reported altitude is as accurate as possible. So, if a builder has determined that his static system has errors, wouldn't it be better to give him a way to correct that, to improve the accuracy of the reported altitude? Why should we assume that he will screw up this correction?

I do agree that it probably makes sense to have reasonable limits on the magnitude of the correction that could be applied to the static pressure. But, wouldn't it be better to allow errors within those limits to be corrected?

Those errors are part of the reason why we have the requirement for bi-annual P/S checks. The airspeed indicator is also checked for errors/leaks and the testing equipment will read the "corrections" as errors.

Where is the requirement for accuracy testing of ASIs on amateur-built aircraft? I am certainly not aware of one. But maybe I missed it. Note that the presence of corrections would not affect the ability to do a leak check .

 

[PilotKris]

Kevin,

You've already acknowledged that the vast majority of end-users don't have the skill set necessary to "correct" or even quantify the errors in their pitot-static systems. Do you really want to bet your life that Joe Average didn't mix up the + & - sign and added (not subtracted) errors in his altitude encoder?

Think that builders can't make such a stupid error? There are dozens of just such mistakes documented right here in the in the Dynon forum. I never underestimate the ability of pilots to find new and even more creative ways of screwing up.

There is a really good reason the FAA requires the encoder to be re-certified just as often as the pilot (bi-annually), it's the safety of ALL the flying public (especially the ticket buying public).  Until there is a way to verify the accuracy of the "corrections" made by end users, my vote is to not give them ability to do it.

(BTW you do have your encoder re-certified every time you work on any portion of your pitot-static system before you turn on your transponder... don't you?)

As for airspeed corrections, like I already said, knock yourself out! I personally have better things to do as it doesn't really provide any real-world benefit. There is however (as the title of the tread asks), no way it can be done "automatically with GPS".

If you've got significant IAS errors however, you really should be looking for the real problem (like SSPE) as it is most likely affecting your indicated (and reported) altitude and that's a problem for all of us.

A much better solution would be for Dynon develop their own pitot/static/AOA probe (but I'm sure some creative builders would still find a way to screw up the installation... never underestimate).

PilotKris

 

[khorton]

If you've got significant IAS errors however, you really should be looking for the real problem (like SSPE) as it is most likely affecting your indicated (and reported) altitude and that's a problem for all of us.

I agree 100% that if there is a problem with the accuracy of the static source, that it should be corrected. But, given the effort involved to correct the error at the source, it is not realistic to expect builders of amateur-built aircraft to do that. I've been involved in testing to resolve such an issue on a type-certificated light aircraft, so I know how much effort it takes.

There isn't much point to you and I continuing to discuss the relative merits of allowing users to correct static source errors in the EFIS, as it is clear that neither of us is going to change our mind, and in the big picture, neither your or my opinion matters. Dynon has apparently already made up their mind on this issue, and they aren't going to change it based on our opinions.

A much better solution would be for Dynon develop their own pitot/static/AOA probe (but I'm sure some creative builders would still find a way to screw up the installation... never underestimate).

The Dynon pitot/static/AOA probe is not a magic bullet here. The accuracy of its static source will depend on where it is mounted. Under-wing static sources are problematic, as the wing by design modifies the air pressure around it so it can develop lift. It is a real trick to find an under wing location that is accurate at all speeds.

 

[PilotKris]

So Kevin, builders aren't smart enough to fix SSPE (or even follow directions from the kit providers re: SS location/shape) but they are smart enough to quantify and program corrections into their EFIS?... Good thing Dynon agrees with my viewpoint ;-) (Just kidding)

The FAA is never going to approve of user-entered, un-verified, non-certified "corrections" to altitude reporting systems. Re-introducing the possibilities for (amateur) human error sorta negates the whole concept of automated collision avoidance. See, even the FAA agrees with me ;-)

I agree that a Dynon designed pitot/static/AOA probe isn't a cure-all but at least it's a step in the right direction (curing the disease and not just covering up the symptoms) and unlikely to create more errors than it fixes. Come on Kevin, I'd think that you, The SSPE Crusaider, would LOVE the idea of a pitot/static/AOA probe from Dynon.

 

[khorton]

I agree that a Dynon designed pitot/static/AOA probe isn't a cure-all but at least it's a step in the right direction (curing the disease and not just covering up the symptoms) and unlikely to create more errors than it fixes. Come on Kevin, I'd think that you, The SSPE Crusaider, would LOVE the idea of a pitot/static/AOA probe from Dynon.

You've got me baffled here.  What is so magic about the static source on the Dynon pitot/static/AOA probe?  The accuracy of a static source depends on where it is located.  The static source on a Dynon pitot/static/AOA probe will be no more or less accurate than the static source on a conventional pitot/static probe.

 

[annken100]

I thought the dynon AOA/pitot tube didn't have a static port.  At least the one I have doesn't.  You still have to find an appropriate location for static ports.

Ken

 

[khorton]

I thought the dynon AOA/pitot tube didn't have a static port.  At least the one I have doesn't.  You still have to find an appropriate location for static ports.

Looking at the docs, it seems that you are correct. I'm not sure what PilotKris meant when he was pointing at a Dynon pitot/static/AOA probe as a solution to static system errors.

 

[PilotKris]

You've got me baffled here.  What is so magic about the static source on the Dynon pitot/static/AOA probe?  The accuracy of a static source depends on where it is located.  The static source on a Dynon pitot/static/AOA probe will be no more or less accurate than the static source on a conventional pitot/static probe.

There isn't any magic as they don't have one.

There currently isn't a static source on the probe and I'd like there to be one. That means that each builder has to design and build his own (located somewhere on the airframe).

There is a higher probability that the accuracy of a pitot/static probe will be higher than a static source located on the fuselage. But, you can't use a conventional pitot/static probe if you want the benefit of an AOA indicator. You have to use the Dynon AS/AOA probe (and make your own static source).

Get it?

 

[PilotKris]

Looking at the docs, it seems that you are correct.  I'm not sure what PilotKris meant when he was pointing at a Dynon pitot/static/AOA probe as a solution to static system errors.

What I said was that I'd like Dynon to focus their efforts in other directions than giving end-users the ability to "correct" Pitot/Static errors.

Developing such a Pitot/Sttatic/AOA probe would be a far better use of resources.

Before you lay into me again, I already stated that won't cure all the problems but at least it's a step in the right direction as they know alot more about the design issues involved than Joe Homebuilder.

I've got no issues with Dynon adding a TAS (not IAS and NOT Static Source) correction capability to their EFIS systems but I doubt that most people would be able use the capabilty. Alot more would be likely to benefit from a better designed static source.

PilotKris

 

[khorton]

Before you lay into me again, I already stated that won't cure all the problems but at least it's a step in the right direction as they know alot more about the design issues involved than Joe Homebuilder.

I wasn't trying to "lay into" you.  If you perceived these as personal attacks, I apologize, as they weren't.  I was just trying to correct some misconceptions.

I do agree that having a static source on the Dynon pitot probe would be a useful option for some people.  But it shouldn't be counted on to provide a more accurate static source than a rear fuselage location.  Rear fuselage locations have been successfully used on many type-certificated aircraft, and it seems that the location suggested by Van on RVs is reasonably accurate, if builders will simply use his recommended "pop-rivet" static source rather than trying to "improve" things by purchasing an expensive flush static port.

I was witness to one test program that attempted to find a suitable location for an under-wing pitot-static source.  The company flew many test flights trying different locations for the pitot-static tube.  They only achieved acceptable static source accuracy by manufacturing a custom Piper-style pitot-static tube with a specific angle on the bottom face.  Under-wing pitot-static tubes are problematic unless you have an excellent recipe on where to put them.

Unfortunately, despite your and my concerns, the vast majority of amateur-built aircraft builders have no idea how much error they have in their static source.  There are certainly amateur-built aircraft flying with well over 100 ft error in the static source (which affects the altitude reported by the transponder, and used by TCAS).  Probably less than 1% of builders have any idea what their static source errors are.  And the ones who know what the errors are currently have no easy means to correct them.  Too bad.