Stumped with ADAHRS Failures

[jaredyates]

I thought I had just completed a Skyview installation with two screens and a primary and secondary ADAHRS. Everything was working great, I flew for an hour or so and completed the inflight compass calibration and AOA calibration. Then the next morning I started up to fly again, and after 30-60 seconds or so I get a red X on the PFD with "ADAHRS Fail Internal Error: Multiple Sensors". Ever since, that is all I can get it to do. All the while, the network configuration works perfectly and there are no other errors.

I put in a ticket with support and they say check the wiring. I inspected the wiring visually, no problems. I removed a known-good network cable from between the right screen and the com head and connected directly from the left screen to the primary ADAHRS, and no change. This is with the wires temporarily routed to ensure I can see the whole thing- there are no kinks or strain anywhere. It seems to me that this rules out any wiring problems, but honestly I would have rather found a wiring problem.

How can the primary and secondary units both fail, with no explanation from the system (or support, after I sent them the diagnostic file) about how or why or even what has failed? All the support tech said was that all of the sensors failed. Every sensor in the box, for both boxes? Did I get struck by lightning? What if this had happened some place other than home, or on the ground? Can the system really be that fragile and non-reporting?

What can I be missing here, and how can I get more information out of the system or anybody else about what is actually happening and what I should do to fix it? It seems extremely improbable that both ADAHRS units have failed, and if the next step is to send them in, that means a couple of hours of work, a couple of weeks of down time, and a likely diagnosis that everything is fine on a factory bench test?

I'd welcome any ideas about navigating out of this frustrating situation.

Pics of the screens: https://photos.app.goo.gl/HzgYpHhDZGusYiUEA

 

[Carl_Froehlich]

Try connecting one ADAHRS module at a time.

Years ago I had one bad module (bad out of the box) that resulted in the big red X when both modules were connected. Connecting one at a time the big red X went away. Dynon replaced the bad module and it has been working just fine for the last decade or so.

Carl

 

[Kevin D]

Jared,

PM me or call this weekend.
I had a similar hick up at initial setup and configuration.

Kevin D
Bearhawk #272

KCHD

 

[jaredyates]

Try connecting one ADAHRS module at a time.

Years ago I had one bad module (bad out of the box) that resulted in the big red X when both modules were connected. Connecting one at a time the big red X went away. Dynon replaced the bad module and it has been working just fine for the last decade or so.

Carl

Thank you Carl, I have tried that also.

 

[MikeD]

It would be highly unusual to have all sensors in both units fail simultaneously. Where are the ADAHR units installed in the aircraft? Could dynamic magnetic fields be causing these failures?

 

[jaredyates]

It would be highly unusual to have all sensors in both units fail simultaneously. Where are the ADAHR units installed in the aircraft? Could dynamic magnetic fields be causing these failures?

Thanks Mike, it could be something environmental. The two sensors are stacked in the wing root, though there is also a remote magnetometer in the wing tip. In a previous plane I ran the sensors in the same place and they worked well, as these did for a short time. I wish there was some way for the sensors to tell us what they think the problem is, as to narrow down what the problem is.

 

[MikeD]

The user data logs contain ADAHR elements. Do they contain any useful sensor failure info, either on the prior good flight, or current bad ground run up?

 

[jaredyates]

The most recent update to this saga, one month in, is that it's still broken. After half a day of troubleshooting the wiring and finding wiring to be not the problem, I sent the units in. They aren't willing to send replacement units, so I have to wait for the repairs on the old units. Last week it was hopefully by the end of the week. This week it was hopefully by the end of the week.

When we commit to an integrated panel, we are at the mercy of one supplier, who may or may not be able to manage their business as we would hope. All I've been able to gather so far is that the brand new 201 was defective on a few sensors. As of my last communication they had not yet listed specific failures of the 200.

Just insuring the airplane costs $10 per day. Overall fixed costs of owning our airplane that isn't usable are on the order of $25 per day, and we're up to 30 days so far, with doubts about being able to get it in the air to get to Oshkosh. This is thanks to the company that is "fully stocked" per the recent emails. I'm having a hard time not being really whiny about this experience.

 

[jaredyates]

An update to the update, realizing I might only be talking to myself here:
Today I called and asked for another update. It turns out either they misspoke or I misheard but the 200 was actually the unit with all the failed sensors, and the 201 was just fine, no problems at all.

Wait, why do I have a secondary? Why do I have an $850 brick of weight and wires and plumbing, if the secondary 201 is just fine, but isn't doing any secondary reverting?

The answer from tech support, paraphrasing, was "Sometimes that happens."

Personally, I don't think it's acceptable to happen. I think that failures in the software are responsible for creating an expensive and hazardous situation, rendering the "perfectly good" secondary ADAHRS perfectly useless. The system should have the capability to express more of this to the user, or in the worst case, at least to their tech support people through the diagnostic files. Everything in the system, and tech support themselves, said that the only way for this problem to present the way it did was for both units to be failed.

We trust a company like Dynon with our lives, I think they owe it to us to explain what reversion capabilities the secondary has and doesn't have, and why it didn't revert in this case. Why didn't it give any diagnostic information about a failed primary and not a failed secondary?

If I put on my tinfoil hat, is this really just because the 200 was out of warranty and the 201 was still covered?

I asked the tech support fellow to escalate this to someone at Dynon and I don't know if that will come to anything, but this is an extremely alarming problem for anyone who thinks they have any redundancy with a Skyview system- and that's on top of a month of being grounded, with only having the good fortune to have the plane stuck at home and not halfway across the country or at some expensive or remote airport tied down in the sun and wind.

 

[Albee]

Very disturbing that one bad box can disable the system without taking down the twin data busses themselves. This wouldn't be the first time a SW or HW component shared between "redundant" systems failed simultaneously. Hopefully the buss transceivers are completely independent within each box. If I ever make good on my threat to add an IFR navigator, I'll be installing a backup PFD system from another manufacturer--so they'll have no parts in common to fail.

 

[maartenversteeg]

Your reporting on these issues is appreciated, you are certainly not just talking to yourself. I am very happy to share experiences of other pilots, I certainly don't want to have to experience all possible problems by myself

 

[Rhino]

Very disturbing that one bad box can disable the system without taking down the twin data busses themselves. This wouldn't be the first time a SW or HW component shared between "redundant" systems failed simultaneously. Hopefully the buss transceivers are completely independent within each box. If I ever make good on my threat to add an IFR navigator, I'll be installing a backup PFD system from another manufacturer--so they'll have no parts in common to fail.

Not all that uncommon on a serial bus if a problem creates a conflict between individual units rather than an issue with the bus architecture itself. It's not as common as it used to be, but it still happens.

 

[Tsperling]

I had the precise same problem yesterday, following an in-flight calibration of the AOA indicator on my last flight. In my case, I only have one ADAHRS, and oddly it shows that it "enabled" on one screen (on my screen 1), but "disabled Internal Error: Multiple Sensors" on my second screen.

It is not a connection problem, as the plane/system has performed flawlessly until I did the AOA calibration (by performing stalls) the other day.
Plus, when I boot up only one screen, it shows that the ADAHRS is "enabled" on whichever screen is booted up. But, once the other screen is booted up, the error comes up on screen 2 (the engine monitor screen)

Is it possible that the two screens somehow now have different sensor files? could that be the problem? Could it be solved by downloading the sensor file on the good screen that shows the ADAHRS "enabled", and installing (re-uploading) that file into the bad screen that shows the ADAHRS "disabled"?

Super frustrating, as my gut is that this is the result of a software problem with the AOA calibration process.

 

[djones]

I had the precise same problem yesterday, following an in-flight calibration of the AOA indicator on my last flight. In my case, I only have one ADAHRS, and oddly it shows that it "enabled" on one screen (on my screen 1), but "disabled Internal Error: Multiple Sensors" on my second screen.

It is not a connection problem, as the plane/system has performed flawlessly until I did the AOA calibration (by performing stalls) the other day.
Plus, when I boot up only one screen, it shows that the ADAHRS is "enabled" on whichever screen is booted up. But, once the other screen is booted up, the error comes up on screen 2 (the engine monitor screen)

Is it possible that the two screens somehow now have different sensor files? could that be the problem? Could it be solved by downloading the sensor file on the good screen that shows the ADAHRS "enabled", and installing (re-uploading) that file into the bad screen that shows the ADAHRS "disabled"?

Super frustrating, as my gut is that this is the result of a software problem with the AOA calibration process.

If any of you with this going on want to do a little experimenting, contact me through the support@dynon.com email.
I am trying to find out what's going on with these and have a file to load to see if it resolves the problem.