What about the other way around ? Calibrating GPS values continuously based on working sensors and use GPS relative data as a backup in case of sensor failure ? That should work well enough as a workaround while the issue is being sorted, in my opinion.
Originally Posted by w1pf
Sensor fusion is hard enough to do when you assume all your sensors are working correctly. When you add in "oh, and, toss out any sensors that you think are wrong" you end up in an unverifiable mess. ... A rule of thumb is that any variable you add into the decision process introduces at least one (and usually far more than one) potential defect.
Both good points - although opposing views.
Yes, W1PF, sensor fusion and data crosschecking validation approaches Doctorate-degree difficulty - what data do you really trust? However, NYT's suggestion that you can look for unexpected changes is a pretty reasonable, and long-established, method of data validation.
I do a lot of work with telemetry data. It's (sometimes) easy to spot "dropout" where the radio signal was interrupted and a value spikes, because value X(t) is starkly different than the surrounding data X(t-1) and X(t+1). It's also (usually) pretty easy to build a metric for how fast a value CAN change... AOA, for example, can only change by X degrees per second, due to the airplane and sensor physics. Any faster, and there's something worth flagging as a likely error. That has been previously mentioned in this thread, although I don't feel inclined to go find the exact quote.
On the other hand, it can be very hard to recognize frozen data, where the "sample and hold" process simply says "Gee, nothing new has been received, so I guess it's still the same as before." For example in this case, AOA started at X degrees before takeoff and didn't move... is that bad? Yeah, probably. But other parameters may not be so easy to recognize frozen sensors. I have had that happen many times working with flight test instrumentation data for nearly 30 years. It can be very hard to convince yourself that a parameter is not working.
So yes, it's pretty easy to say "that value must be wrong" IN SOME CASES. But not all. So building a definitive validation comes with its own risks.
Nonetheless, I suspect that it would catch enough errors that W1PF's concerns don't mean you shouldn't do it. Catching 50% of errors is better than catching 0% of them. And I think that with enough attention, especially with today's computing resources where you really CAN test every possible scenario, you could validate the model pretty well.