Avidyne Emergency AD

[poadeleted20]

If you're flying an Avidyne R9 or IFD540, you need to see this ASAP:

http://content.govdelivery.com/atta...e_attachments/391964/2015-10-51_Emergency.pdf

 

[bnt83]

Wonder if this is just the beginning or are there tons of defects yet to be found.

 

[poadeleted20]

The R9 system has been around for quite a few years, and this defect appears to be in software common to both the R9 and the IFD540, so I see no reason to believe there are other issues in the IFD540 based on this problem. Also, I would expect this to be temporary while Avidyne fixes the issue and sends out a software update, and you install the update.

 

[MAKG1]

I'm thoroughly astonished that such a critical feature is not in their prerelease regression test. Is there anything in IFR more critical than course deviation indication inside the FAF on an approach?

 

[RotorDude]

I'm thoroughly astonished that such a critical feature is not in their prerelease regression test. Is there anything in IFR more critical than course deviation indication inside the FAF on an approach?

As I read it, the bug shows up outside the FAF. Presumably all is OK on final approach.

 

[MAKG1]

You're right. It's the course to the FAF, not the final approach course.

Still, pretty damn critical. The FAF may be at 2000 AGL or lower and there can pretty easily be terrain or obstructions out there.

 

[RotorDude]

You're right. It's the course to the FAF, not the final approach course.

Still, pretty damn critical. The FAF may be at 2000 AGL or lower and there can pretty easily be terrain or obstructions out there.

Sure, that's why it's classified as emergency AD.

 

[MAKG1]

Sure, that's why it's classified as emergency AD.

Yeah, the FAA side makes a lot of sense to me. It's the Avidyne side that doesn't.

Safety critical systems require considerably more testing than consumer toys. A bug THAT serious should never make it out the door, and I'd expect course deviations to be a big focus for release regressions.

I'm sure Avidyne is not a pleasant place to be right now.

 

[wsuffa]

The R9 system has been around for quite a few years, and this defect appears to be in software common to both the R9 and the IFD540, so I see no reason to believe there are other issues in the IFD540 based on this problem. Also, I would expect this to be temporary while Avidyne fixes the issue and sends out a software update, and you install the update.

Supposedly the next release of the Avidyne software fixes the problem, but is still in the FAA approval process. No idea how much longer that will take, but I'll bet that it gets more scrutiny.

This is not a "minor" issue like the Garmin transponder timing bugs a few years ago.

 

[poadeleted20]

And for all you folks waiting for your brand-spankin' new IFD540, now you know why they used to say in the military that you never want to fly the A-model of anything.

 

[Brad Z]

And for all you folks waiting for your brand-spankin' new IFD540, now you know why they used to say in the military that you never want to fly the A-model of anything.

Avidyne is currently running a second contest to trade in your Garmin 430/530 for a IFD540 for free. Not sure I'd be rushing to schedule my install right now if I was the winner.

 

[AdamB]

Luckily there aren't that many approaches that are affected by this. Certainly not near the northeast where I do most of my flying.

I'm liking our IFD540 install so far. About a month old now.

 

[MAKG1]

A little terrain will change that. In my area, around 1/5 of the non precision RNAV approaches have a heading change at the FAF. I couldn't find any examples for precision approaches, but they are much rarer.

 

[mtuomi]

If I understand the AD correctly, this approach would not be survivable with Avidyne...

http://155.178.201.160/d-tpp/1505/06404RE.PDF

After BUSTE it would show a deviation from the final approach course, which would command you to turn right. You would be descending to 9700 feet, turning right towards mountain range that is higher than 10000 feet with peaks up to just under 11k.

In IMC, this would be a rather hairy situation.

 

[luvflyin]

Open the Pod Bay Doors HAL

 

[Comanche flyer]

The avidyne nightmare is just starting.

 

[Henning]

Yeah, the FAA side makes a lot of sense to me. It's the Avidyne side that doesn't.

Safety critical systems require considerably more testing than consumer toys. A bug THAT serious should never make it out the door, and I'd expect course deviations to be a big focus for release regressions.

I'm sure Avidyne is not a pleasant place to be right now.

More testing equals less profit, makes perfect sense in our society to release something with the least work one can get away with, since after all, the product at Avidyne is money, not avionics. Avionics are just a tool to make money, money is the final product.

 

[MAKG1]

More testing equals less profit, makes perfect sense in our society to release something with the least work one can get away with, since after all, the product at Avidyne is money, not avionics. Avionics are just a tool to make money, money is the final product.

Maybe in the short term, but it's hard to stay profitable when your POS software scares the customers.

Safety critical systems are VERY different from iToys.

 

[Henning]

Maybe in the short term, but it's hard to stay profitable when your POS software scares the customers.

Safety critical systems are VERY different from iToys.

Doesn't matter, only next quarter's bottom line matters, beyond that doesn't exist.

 

[denverpilot]

Doesn't matter, only next quarter's bottom line matters, beyond that doesn't exist.

Which is only different from you by 90 days vs 30 days.

It gets old hearing that people think businesses are evil because they have bills to pay. Your next month's bottom line is all that matters for you, too. Big whoop. What's the magic number not to be evil? A year? Two? Ten? A day? A week?

Not to mention that the above complaint is really only true for PUBLICLY held businesses. Over the years I've been involved with a number of privately owned businesses that chose to run in the red for growth via purchase of real estate, technology, or other CAPEX or even other more esoteric reasons for specific periods of time.

One friend joked that running at minimum profit (while laying the profit almost exclusively out to owners and investors in a private held firm) is the best taxation lowering strategy out there for such a firm.

Not all businesses are evil because they have to hit quarterly growth numbers. They chose to place themselves in that position by taking public investor capital.

Some of the best businesses I've worked for chose not to take public investor money and had good leadership making sure the place made a profit daily. They didn't wait for a quarterly deadline to cram things into the books that they'd have to "correct" later.

 

[Everskyward]

Maybe in the short term, but it's hard to stay profitable when your POS software scares the customers.

Safety critical systems are VERY different from iToys.

The reaction from customers is bad enough when it's an iToy. Whether the customer perceives the cost it too much with a software upgrade (see LogTenPro discussion) or the software loses a lot of function (see Tapatalk discussion). Many customers are lost this way. Incidentally, Tapatalk has improved somewhat since the new software's first release, but it has taken a while. At least it is more usable, for me.

 

[Matthew]

Interesting things at play - I worked for a salesman (he owned the company, and he was the kind of guy who could sell an icemaker at the North Pole). His comment, "Engineers want everything to be perfect, when it just has to be good enough."

That's a tradeoff and decision that has to be made every day on product development. When is good enough, good enough?

In certified s/w, there is normally a much more formal testing and documentation process that shows not only what was tested, how, and the results. This is why you will always pay much more for certified s/w for any product. As complex as s/w is these days, it is probably provably impossible to test everything.

 

[MAKG1]

It's provably impossible to test everything even with very simple software.

But you do want to design for fault tolerance and test all the critical things. If there are too many critical things to test, you might want to consider a different (and probably more modular) design.