Kahuna

Kahuna

Moderatoring
In 250 hours I have had 4 BMA G3 Lite lockups and 1 GRT lockup in flight. You would think that the chances of this happening in the same flight are near zero. Well near zero is not zero and it happened to me yesterday while on a return trip from Cozumel with our group on my last leg.

Whiz banging along smooth air, my BMA went TU with the following screen. Sorry for the crappy screen, but you get the jist.
bmalockup.jpg


I reset it and everything was fine.
About 60 miles later I was set up for a GPS approach into LZU. Weather was deteriorating with rain and low vis so I selected the GPSA approach into LZU. I had never done this approach in my RV8 into my home airport, but I thought it was worth trying based on my inbound direction it was easier to set up. So I requested it and punched everything in. As I got close to the airport, wx was getting worse, I decided I wanted the ILS 25 into LZU instead to get the lower minumums. I went to change runways on the GRT an wammo, locked up tight. Could do nothing on the screen. Froozen solid and I snapped this crappy picture.
grtlockup.jpg


I changed over my scan to the BMA G3 and was able to finish the landing uneventful.
Moral of the story is.
1. If you think these things are ready for prime time, think again.
2. Be ready for issues with all these gee whiz features
3. If you think having 2 differnt EFIS helps lower the risk, your probably right. But lower is not zero.
4. I highly recommend a power switch to reboot these things in flight. When they lockup, you dont want to have to kill your entire panel with an avionics sw or master sw. while working an approach or in the system.
Have a seperate sw on the EFIS for the ability to cycle the power in flight.

Be careful out there.
Best,
 
First ... I agree you must have a way to reboot your EFIS's inflight without effecting other systems (we have seperate CB's with Sporty's Yellow CB cabs on them for the EFIS's, the red ones are for trim and flaps.)

Two ... Looking at the screen shots and hearing your writen issues, are you are seeing a low or over voltage problem? Could they both be overheating?

Three ... no matter what system or systems we used they can fail and will fail at the wrong time. If you were using an vac system and the pump when out, there would have been no way to 'reboot' it. If you were using an VOR/ILS and the head or radio quit, then what? I have had both of the previous have happened to me ... the first one in a 421 and then the second in a King Air F90.
 
Always have a backup plan

Moral of the story is.
1. If you think these things are ready for prime time, think again.
2. Be ready for issues with all these gee whiz features
3. If you think having 2 differnt EFIS helps lower the risk, your probably right. But lower is not zero.
4. I highly recommend a power switch to reboot these things in flight. When they lockup, you dont want to have to kill your entire panel with an avionics sw or master sw. while working an approach or in the system.
Have a seperate sw on the EFIS for the ability to cycle the power in flight.
Click to expand...

Mike, sorry to hear of the stressful approach after what was no doubt a great trip! I have to wonder if two glitches within 60 miles is more than a coincidence. Might be time to take a hard look at the power feeds to your EFII to make sure nothing weird is going on.

Observations concerning the points you made above:
1) The digital flight instruments are probably as reliable as a vacuum system. Pumps and gyros have been failing for decades but have still been used in prime time. :)
2) We should be ready for issues with all the equipment in our panels, regardless of whether electronic or mechanical.
3) True.
4) I agree. Sometimes the best recourse is reboot, and we need to have an easy way to accomplish it.

Thanks for the report and reminder that anything in our panels can fail, and will probably do it at a time when least convenient.
 
Last edited:
n468ac said:
Two ... Looking at the screen shots and hearing your writen issues, are you are seeing a low or over voltage problem? Could they both be overheating?
Click to expand...

Overheating? ....I dont think so. But I have no way of knowing. These both happen in ~70F OAT cloudy skies and not hot. They have been in hot hot hot temps and I have not seen this. DOnt think it is heat related.

These are on 2 different busses. I have under and over audible voltage alarms with tight tolerances on the voltage for a quick alert(ACS2002 eng monitor). The system voltage was stable when this occurred. Alarms are trapped and must be acked to proceed and there were no alarms.

On the GRT, she locked up while pushing buttons to change runways so Im pretty confident its a software issue there.

On the BMA, I really dont know. It locks up like that when just flying along. I can make it lock up like that if I jump in, fire up, and taxi too quickly before the ahrs has a chance to stablize. But the fourish times it has done this in flight, I was not doing anything strange. Just cruising along.

And Sam, all good points.
Best,
 
Kahuna:

Sorry about your problems. That really sucks.

But on to more important issues: Where are your trip pictures for all of us wannabe's?
 
Lockup and vendor responsibility

According to G3, their program relies upon DOS. According to GRT, their product relies upons Windows.

As we've all learned to appreciate (tolerate), Windows is the target of every hacker on the planet. Having built & repaired Windows pcs and pc networks for the better part of the last 20++ years, it would NEVER be my first choice to run my panel.

In this instance, a responsible software vendor would place this matter on the top of his priority list and potentially dispatch an engineer to your hangar so he can research the issue when the equipment craps out. That's what I did when I served as CEO of a national software development firm and my product was NOT being used at 10k AGL.

Assuming the vendor forces his (creative) programmers to produce code that never exceeds arrays causing aberrant conditions, and selects electronic components that can handle sags, surges, and transient spikes, it's possible to produce a reliable product on either operating system.

In both cases, another program may be dispatching a signal that the G3 and GRT were not programmed to handle. The common bus can also contribute "information" neither was programmed to handle. The G3 displayed EXCEPTIONS that are useless to the end user, and the other does what Windows typically does, FREEZE.

For the sake of all of, please contact the vendor(s) and let both know that you'll be producing a running dialogue on this forum and other forums to keep fellow pilots apprised on the problem resolution.

Feel free to contact me offline. Before I retired, I did a lot of disaster recovery work concerning other people's software.

No charge.
 
Excellent report!

Kahuna -

Great report on a bad day! I agree with you and Sam's posts - and add that the name of the game is backups, backups, backups! I spend a huge part of my life in simulators and simulations with sophisticated flying machines having their systems failed on me non-stop. I ALWAYS expect to be flying with nothing left but two half-dead AA batteries and a couple of pieces of re-used safety wire keeping me functioning. Do that four thousands of hours, and you are amazed when the real flight goes so well - and you become very paranoid, wondering what has failed that you haven't caught yet!

It's good to hear of other people's "incidents", as it reminds us to always be ready. I haven't had a lockup in my GRT systems yet, but I have the TruTrak as my prime backup, and good old partial panel as a backup to that (and I practice it!). Not going to try and troubleshoot your problem by remote control - it is clear that you have a well-practice backup plan yourself. I agree with those posts that point out that the old stuff can fail as well....

The best protection is a well-thought out operational redundancy scheme, practice, and currency!

Paul
 
n468ac said:
First ... I agree you must have a way to reboot your EFIS's inflight without effecting other systems (we have seperate CB's with Sporty's Yellow CB cabs on them for the EFIS's, the red ones are for trim and flaps.)

Two ... Looking at the screen shots and hearing your writen issues, are you are seeing a low or over voltage problem? Could they both be overheating?

Three ... no matter what system or systems we used they can fail and will fail at the wrong time. If you were using an vac system and the pump when out, there would have been no way to 'reboot' it. If you were using an VOR/ILS and the head or radio quit, then what? I have had both of the previous have happened to me ... the first one in a 421 and then the second in a King Air F90.
Click to expand...

If vacuum pumps are replaced every 500 hrs, they are as reliable as any electrical component. A vacuum system is a mechanical system totally separate from the electrical system, and when combined with an engine vacuum source backup, are nearly 100% reliable.
 
Kahuna said:
Overheating? ....I dont think so. But I have no way of knowing. These both happen in ~70F OAT cloudy skies and not hot. They have been in hot hot hot temps and I have not seen this. DOnt think it is heat related.

These are on 2 different busses. I have under and over audible voltage alarms with tight tolerances on the voltage for a quick alert(ACS2002 eng monitor). The system voltage was stable when this occurred. Alarms are trapped and must be acked to proceed and there were no alarms.
Click to expand...

Just thinking out loud ... Are they on the same ground bus?

I would also like to hear what support for both these products have to say.
 
Manufacturer Responce, Grand Rapids Technologies, Inc.

I happened to see a post about this lockup and forwarded it to Jeff in our software department. He was able to determine the problem and we will have a new release to this afternoon.

A few notes:
1) We address all software issues, and they are of the highest priority.
2) We have found Windows CE to be highly stable.
3) The software has been so reliable that most users are unaware that the display can be rebooted by holding down the left and right outer softkeys for 5 seconds.
4) For IFR our system is designed as a dual screen system with a seperate AHRS to allow a single display to be rebooted while the second display is still operational as another level of backup.
5) We can only address software or hardware issues that we are informed of, had I not seen this posting we would not have been able to make a fix.
6) The AHRS (Attitude) is independent of the display unit and is never effected by the display lockup, and a 10 second reboot would restore the display.


Todd Stehouwer
Design Engineer
Grand Rapids Technologies, Inc.
[email protected]
616 245-7700
 
Todd,
This was posted to both BMA and GRT efis messsage boards this morning before the post here.
It was too early to call and im out of the office all day.
I knew the messages would get there one way or the other.

Also how are you able to rully regress the firmware in hours? Being in the software testing business for appliances for every OS known to man, I cant see getting a firmware out that quickly. Takes us a day with test automation harnesses that fill a room on appliances that dont have people in em. No rush there Todd. I have full confidence in the product. Just used it for an ILS into Columbus GA for an avionics checkout.
Best,
 
Last edited:
We took version 28 that has already gone through our test procedures and made the fix to that version. It was a small fix and was easily tested. If it had been a major fix we would have waited to add the fix to version 29 and had the full spectrum of tests that we run for a new release, this usually takes 2 months.



Here is a description of the problem from Jeff, our software engineer.


Display software version 28 contains a programming error that can cause
the display to freeze. If the synthetic approach function (SAP) is
armed (SAP-ARM), and destination runway data is not available, an
attempt to activate the localizer arm function (LOC in the ARM menu)
will freeze the display. Display function can be restored by rebooting
the display using the buttons or a power switch. Rebooting only the
display does not affect attitude sensor accuracy and it can be done in
flight. The safest way to reboot only the display unit is to hold in
both the leftmost and rightmost white softkeys for 5 seconds. A patch
to fix this problem will be made available on our web site as version
28d. Version 28d fixes a few problems and adds some missing features to
version 28. Version 29, which will contain significant feature changes,
is also expected later this month.

Jeff DeFouw
Programmer
GRT Avionics, Inc.






Todd Stehouwer
Grand Rapids Technologies
 
Thanks for the quick response Todd and Jeff.

While I am not too long from flying my GRT system, one *minor* complaint I have is the lack of documentation of certain features. I know some inroads have been made recently with regards to a more complete manual.

But things like how to reset the display by holding the left & right buttons simultaneously is a good thing to know and shouldn't be left out of the manual. Keep us in the know about these kinds of features!!

Thanks,
Scott
 
Vacuum suddenly looks awfully good.

So lemme see if I have this right.

Jeff, the GRT software engineer, said that "..if the synthetic approach function (SAP) is armed (SAP-ARM), but the destination runway data is not available, an attempt to activate the localizer arm function (LOC in the ARM menu) will freeze the display."

Surely there was a better way to resolve the unavailability of runway data than asking some poor pilot who's flying into LAX thru IMC at 125kts, talking on the radio to a tower issuing instructions at hyper speed, watching for traffic, and fighting turbulence to reboot by holding down two keys for 5 seconds.

Back in the dark ages of programming we called it error trapping.

Quoting Microsoft, "To prevent the application from crashing or behaving unpredictably, you can include macro code that intercepts the error and tells the macro how to handle it. The process of intercepting and handling a run-time error is called "error trapping." The set of instructions that tells the application how to handle the error is called the "error-handling routine" or "error handler."

Of course, we could be encouraged by the other suggestion assuming the first reconciliation method fails: "The AHRS (Attitude) is independent of the display unit and is never effected by the display lockup, and a 10 second reboot would restore the display."

Give me a break.

Vacuum suddenly looks awfully good.
 
MrNomad,

They **probably** know all these things ... after all they did seem to stumble upon getting something working as good as if not better than anything else in its class without a dissertation on error handling.

Flogging manufacturers in such a manner really does not help.

Also it appears that they were simply sharing (inside commentary on) what the **problem** was and that there was a s/w fix coming.

Let's give folks like this a chance to repair things when the inevitable error or mistake comes up. No matter how good the developer, there is a good chance that a complex s/w system will have an error that gets missed.

Anybody remember Ada??

James


James

MrNomad said:
So lemme see if I have this right.

Jeff, the GRT software engineer, said that "..if the synthetic approach function (SAP) is armed (SAP-ARM), but the destination runway data is not available, an attempt to activate the localizer arm function (LOC in the ARM menu) will freeze the display."

Surely there was a better way to resolve the unavailability of runway data than asking some poor pilot who's flying into LAX thru IMC at 125kts, talking on the radio to a tower issuing instructions at hyper speed, watching for traffic, and fighting turbulence to reboot by holding down two keys for 5 seconds.

Back in the dark ages of programming we called it error trapping.

Quoting Microsoft, "To prevent the application from crashing or behaving unpredictably, you can include macro code that intercepts the error and tells the macro how to handle it. The process of intercepting and handling a run-time error is called "error trapping." The set of instructions that tells the application how to handle the error is called the "error-handling routine" or "error handler."

Of course, we could be encouraged by the other suggestion assuming the first reconciliation method fails: "The AHRS (Attitude) is independent of the display unit and is never effected by the display lockup, and a 10 second reboot would restore the display."

Give me a break.

Vacuum suddenly looks awfully good.
Click to expand...
 
Last edited:
Loose ends in software need to be safety wired.

Thanks James and I appreciate your positive note and constructive attitude.

Destructive testing is an accepted software practice that pits one group of programmers against another with the explicit goal of flushing out defects before they are detected in the field such as those at the beginning of this thread. In some software development companies, bonuses are paid for every defect found but after destructive testing is complete, comraderie is engendered to seek out the solution.

Beta testing is another widely accepted practice which is used further along the software development process to accomplish the same goal. Detect and correct defects before the end user experiences them.

Just like every field of endeavor, some companies will demand a higher level of performance of their staff and therefore, their products will achieve a higher level of reliability.

In bookkeeping situations, software defects equate to lost dollars. Needless to say, in a cockpit, the situation is a little more upfront and personal. But unless the user community insists & demands higher quality, "reboot" will continue to be the vendor's suggested solution.

We may be "experimental" but that's not good enough when my grandson is sitting next to me on final. Loose ends in software need to be safety wired just like nuts and bolts.

It's not hard, it just requires organization and determination like that required to assemble an airplane.
 
Pick any two

MrNomad said:
... It's not hard, it just requires organization and determination like that required to assemble an airplane.
Click to expand...
There's an old saying that goes something like this: "Quick, Good, or Cheap. Pick any two."

I think the way Mike is doing it is smart - he doesn't have all his eggs in one basket. If I eventually equip my 8 for IFR, I'll have the GRT, and something with a completely different technology, like the VAL INS 422.
 
You can have all of that, for a price

By buying TSO'd avionics. Of course, you'll pay a lot more, but that's the point, isn't it? It's a personal decision, a kind of risk/benefit analysis every builder will have to go through. "Experimental" is not a brand name, it is a very accurate description of what you are buying.

Personally, being a software developer, when I saw this thread I was curious as to what the fix was. I didn't expect to ever find out since as a software developer, I know through experience that sharing that kind of thing in a public forum can lead to exactly this kind of response.

I've also experienced situations in try/catch/exception blocks (error trapping) where by the time the catch code is active, you have lost access to all of your variables and context, and the only recourse is to try to fail gracefully. Granted, it is far better to never, ever have your catch code invoked, but any software developer will tell you that in any kind of dynamic, interupt-driven situation, it is not possible to foresee every possible failure mode, unless you're staffed like NASA with triple, quadruple QA teams. That comes at a very high cost, which again explains the price difference between Avidyne/Chelton/Garmin and the experimental units we are privileged to be able to use in our airplanes, as long as the cost-benefit meets our personal needs.

MrNomad said:
Thanks James and I appreciate your positive note and constructive attitude.

Destructive testing is an accepted software practice that pits one group of programmers against another with the explicit goal of flushing out defects before they are detected in the field such as those at the beginning of this thread. In some software development companies, bonuses are paid for every defect found but after destructive testing is complete, comraderie is engendered to seek out the solution.

Beta testing is another widely accepted practice which is used further along the software development process to accomplish the same goal. Detect and correct defects before the end user experiences them.

Just like every field of endeavor, some companies will demand a higher level of performance of their staff and therefore, their products will achieve a higher level of reliability.

In bookkeeping situations, software defects equate to lost dollars. Needless to say, in a cockpit, the situation is a little more upfront and personal. But unless the user community insists & demands higher quality, "reboot" will continue to be the vendor's suggested solution.

We may be "experimental" but that's not good enough when my grandson is sitting next to me on final. Loose ends in software need to be safety wired just like nuts and bolts.

It's not hard, it just requires organization and determination like that required to assemble an airplane.
Click to expand...
 
perspective

Wow! This is really scary stuff! Guess it's a good thing I am only building a toy and not a 737-800!

Hwood
 
Costs.

Everyone talks about the cost differences between the feature rich, highly tested EFIS systems (didn't want to say more expensive as there is more than just a cost difference involved with them), however, I'd suggest that the cost different narrows greatly when you think about the delta cost between the Garmin/Chelton/Avidyne systems and the cost of the souls on board.

BTW, Mike, to make this a little more interesting. If that GRT screen shot was at, and I'm assuming after the failure point, and you took the picture while still in the air, you must have been in a pretty scary position. The ALT is 1990, so take away the 200' of ILS precision and the fact that you were at 500/min on the GS, each 5 seconds of difference between freeze and picture was another 100' of descent..... You were getting mightly close to the ground!!!! Double YIKES... Glad you had something for backup and that the double failures weren't closer together.
 
I took the BMA pic airborne, I took the GRT when on the ground.

THe GRT lockup was really a non event. Even the loss of 2 efis's at the same time while on approach is really no big deal. I have the MX20 giving me a lot of data on position and altitude. All GPS of course and ..... there is George who I immediately engaged when the GRT went TU. George is great and does a way better job than I can anyway. George has never let me down. He and I have become very cose friends over the years.

I did notice some of the other posts using words like scary and so forth. Not scarey at all. I have had some scary moments flying. This was not one of them. I got so much backup and so much cross reference information, there is no worry for me in the panel systems. I attribute that to a lot of flying, wiring it myself, and knowing the plane inside and out including every gee whiz feature and how it works. Spreading different manufactures on the panel has attributed to good success for me.

Best,
 
MrNomad said:
Thanks James and I appreciate your positive note and constructive attitude.

Destructive testing is an accepted software practice that pits one group of programmers against another with the explicit goal of flushing out defects before they are detected in the field such as those at the beginning of this thread. In some software development companies, bonuses are paid for every defect found but after destructive testing is complete, comraderie is engendered to seek out the solution.

Beta testing is another widely accepted practice which is used further along the software development process to accomplish the same goal. Detect and correct defects before the end user experiences them.

Just like every field of endeavor, some companies will demand a higher level of performance of their staff and therefore, their products will achieve a higher level of reliability.

In bookkeeping situations, software defects equate to lost dollars. Needless to say, in a cockpit, the situation is a little more upfront and personal. But unless the user community insists & demands higher quality, "reboot" will continue to be the vendor's suggested solution.

We may be "experimental" but that's not good enough when my grandson is sitting next to me on final. Loose ends in software need to be safety wired just like nuts and bolts.

It's not hard, it just requires organization and determination like that required to assemble an airplane.
Click to expand...

Actually, if you look at their website, they clearly state that version 27 of the code is "stable" and 28 (the version in question) is not recommended for IFR (i.e. it's beta test...use at your own risk). Their process worked precisely as intended.
 
NOTHING is perfect!

It is all very good to expound on how to write perfect, error-free (or error-trapping) code, but I have yet to find any human organization that has done it. I can't tell you how many times my team (as in-flight operators) have had to patch code in the spacecraft systems in-flight, because we ran into a bug, or had to change functionality on the fly. And yes, in the space program, we employ thousands and thousands of programmers (government and contractors) and spend way more money than we want to know about to make things "perfect"....you will still have an error rate.

Anecdotal evidence is generally useless, but if you want to use it, I have had more vacuum pump failures (4) than EFIS failures ()) in 30+ years of flying. That just means I am waiting for my first EFIS hic-up! But I am prepared with a backup scheme when it occurs.

I thought that GRT turning around a software patch in less than a day was pretty remarkable - but if you don't, then that is what the free market is all about. Oh - I haven't heard what the Blue Mountain fix was yet?
 
Ironflight said:
I thought that GRT turning around a software patch in less than a day was pretty remarkable - but if you don't, then that is what the free market is all about. Oh - I haven't heard what the Blue Mountain fix was yet?
Click to expand...
And my 2 cents is that you probably won't, at least not on an open forum such as this. Thanks GRT for being willing to examine corrections out in the open for all of us to benefit from your expertise.
 
RVbySDI said:
And my 2 cents is that you probably won't, at least not on an open forum such as this. Thanks GRT for being willing to examine corrections out in the open for all of us to benefit from your expertise.
Click to expand...

Steve:

Not so fast, BMA actually hosts the BMA EFIS forum. Check thier web site. The owner and engineers "speak" with the customers daily on the forum. They are very open. GRT monitors the Yahoo Groups GRT EFIS forum.

Jekyll
GRT Horizon 1 owner.
 
Loaded and tested GRT Fix today....

Sorry about the BMA comment - I try really hard not to say negative things about companies and/or stuff I have not direct experience with - I didn't intend to bash, I was just honestly being curious, but I see how it came across wrong! :eek:

I loaded the updated software from GRT today and went for a local test flight, Did my usual EFIS check flight, which includes Acro to make sure that nothing is going to lock up do to maneuvering, and then did some approaches in VFR conditions, changing modes like crazy, to see if I could get any lockup. All worked great - didn't have any problems. Admittedly, that is a very non-definitive way of testing software, but at least I could not repeat Kahuna's reported problem with the fixed software. :D

Paul
 
Jekyll said:
Steve:

Not so fast, BMA actually hosts the BMA EFIS forum. Check thier web site. The owner and engineers "speak" with the customers daily on the forum. They are very open. GRT monitors the Yahoo Groups GRT EFIS forum.

Jekyll
GRT Horizon 1 owner.
Click to expand...
I stand corrected on the BMA forum. Along with Paul, I should not be making negative statements concerning things I am not directly involved with. I am open for whatever flogging I deserve.
 
Ironflight said:
It is all very good to expound on how to write perfect, error-free (or error-trapping) code, but I have yet to find any human organization that has done it. I can't tell you how many times my team (as in-flight operators) have had to patch code in the spacecraft systems in-flight, because we ran into a bug, or had to change functionality on the fly. And yes, in the space program, we employ thousands and thousands of programmers (government and contractors) and spend way more money than we want to know about to make things "perfect"....you will still have an error rate.
Click to expand...
Paul - just curious. Is the code in question developed using the DO-178B process? If so, what level is the code?

Many companies and agencies put a lot of faith in the DO-178 process, but I have always been sceptical. At best, the code is only as good as the functional spec it is designed to meet, and it is pretty much impossible to write a perfect spec for a complex system. There are too many situations that you can't predict, and these situations will often expose flaws in the functional spec.

Part of the problem is users who prefer to purchase systems with a lot of functionality. Simpler systems are easier to design and test, but simple systems don't sell as well as ones with more functionality.
 
Sorry Kevin - I think you're beyond me! Part of the problem in working in the government is that I get shielded from many commercial processes and controls, so I am not familiar with the DO-178B that you speak of. I can tell you, however, that it takes more people than I can count to review and approve changes to our code! We all subscribe to the axiom that "better is the enemy of good", and if something is working, going in to make "improvements" always risks making something else worse. You have to remember that our basic flight software on the Shuttle is now 25 years old, and while we have made many mods and upgrades, the fundamental code remains the same. That means that as Industry's processes and models for building code have developed, we have not really been a part of that. Our controls and processes grew up before anyone really thought about software controls, and then many things were developed based on our experiences....

You're right that writing a good, clear spec and requirements is a major step in getting a good product. Unfortunately, with a "Research Program", you frequently don't know what you need until you have built it - many times, the specs get written after the fact - not a great way to do business, but the reality in research!

Paul
 
Ironflight said:
Part of the problem in working in the government is that I get shielded from many commercial processes and controls, so I am not familiar with the DO-178B that you speak of.
Click to expand...
Paul:

That's a blessing -- not a problem. ;)
 
Thoughts...

Hi,

A couple of thoughts(another $0.02).

From GRT perspective - the 27 version is considered the 'stable' release, 28 is a 'beta'.
I really like the fact Jeff was able to specifically identify, explain / notify and fix the problem - it is just a combination that hadn't been caught - bug.

Kahuna - did you have a second GRT screen (I think not)? One question I was interested to know - assuming the AHRS is still doing it's thing sending the serial data, MFD1 locks due to a bug, does MFD2 just continue working?

And finally it comes down to backups, for my personal minimums, more than one, and sometimes more than two (ie. tie break) methods of getting information or control is the key. George is our friend.... Kahuna - 'had it covered'

Carl
 
zkvii said:
Kahuna - did you have a second GRT screen (I think not)?
Carl
Click to expand...
No, Single GRT screen.
I like to spread my EFIS risk across the manufactures.
Just a personal choice. For system issues, as well as company viability.
Best,
 
Dual Screen GRT

zkvii said:
Hi,

Kahuna - did you have a second GRT screen (I think not)? One question I was interested to know - assuming the AHRS is still doing it's thing sending the serial data, MFD1 locks due to a bug, does MFD2 just continue working?
Carl
Click to expand...
If it is a screen lockup, it only affects one screen. The other remains fully functioning. I have experienced this in testing. The lockups were due to poor voltage source at the time.
h
 
Unreal expectations

As a few more knowledgeable than I have commented, it is impossible to write flawless software.
In the early days of digital cockpits in the B737 we used to see 20nm instant Map shifts on lift off and Autopilots trying to control ASI with Elevator and Auto-throttle at the same time.
When the manufacturer addressed the problem on ?Version7? with ?7 Interim?, it was such a disaster that the pilots referred to it as ?7 retro?.

Any one who flew the B747-400 knew that if the FMC annunciated "Re-syncing Other FMC" and you TOUCHED ANY KEY, during the process, then you could be entertained as everything progressively failed.

So let?s get off GRTs back. They have a good product and an excellent sense of corporate responsiblilty.

Kahuna did the smart thing and had redundancy.

Airbus, when they made the first fly by wire A320, on the Flight Control Software, they used different Chips, programmed by two teams in two different languages.

For 'Experimental' it is up to the builder to ensure he has sufficient redundancy whether operating IFR or VFR.

Pete.
 
Dgamble said:
You can have all of that, for a price, by buying TSO'd avionics.
Click to expand...
I've seen crashing bugs with TSO'd avionics, and many non-crashing bugs too. But, I agree that I would expect a higher software quality with TSO'd avionics. TSOs are a double-edged sword though. If there is a bug, it is extremely expensive to fix it, as the new software needs to get approved. The vendors usually won't release a new software release to fix just one bug, unless they are facing an AD, or have a major aircraft installation approval at risk.
 
Steam Guages Please!

fodrv7 said:
As a few more knowledgeable than I have commented, it is impossible to write flawless software.
In the early days of digital cockpits in the B737 we used to see 20nm instant Map shifts on lift off and Autopilots trying to control ASI with Elevator and Auto-throttle at the same time.
When the manufacturer addressed the problem on ?Version7? with ?7 Interim?, it was such a disaster that the pilots referred to it as ?7 retro?.

Any one who flew the B747-400 knew that if the FMC annunciated "Re-syncing Other FMC" and you TOUCHED ANY KEY, during the process, then you could be entertained as everything progressively failed.

So let?s get off GRTs back. They have a good product and an excellent sense of corporate responsiblilty.

Kahuna did the smart thing and had redundancy.

Airbus, when they made the first fly by wire A320, on the Flight Control Software, they used different Chips, programmed by two teams in two different languages.

For 'Experimental' it is up to the builder to ensure he has sufficient redundancy whether operating IFR or VFR.

Pete.
Click to expand...

Peter,
My company recently had a 737 loose all glass panels AND the standby ADI at the same time! Nobody seems to know why either???????

The 777 recently had a huge control software bug surface, and threatened the safety of several flights at cruise altitude. Ten years in service, and still suffering from software bugs!

F-16's have earned the moniker "lawn dart" in no small part due to to computer controlled flight controls.

Airbus software flaws are legendary at this point, so no sense mentioning them.

Now, can somebody remind me why we are choosing to install this type of technology in our recreational aircraft, and "low-bidder" equipment at that!
The airframe manufacturers know this technology is marginally reliable, and therefore install "round dial" backups in every installation.
 
Mark I Eyeball

Good question John.
Quote: ..............Why are we choosing to install this type of technology in our recreational aircraft,?

Well, I can only speak for myself. As I said in the 'Fabulous Fuse' Post.
Quote: .....................if I lost ALL electrical power, I have a map, a watch and a Magnetic Compass, and believe I could find a runway and do a flapless, no ASI approach to an acceptable landing...... IN DAY VMC. Aussie Sunshine that is.

IFR. Well, I would have to have a long hard think about that. On my very last trip on the B777 I went around in tropical Asian Thunderstorms from the 100' due to 18Kt tailwind. (Singaporean ATC lost to much face and refused to change the active runway). I had a fabuolous FO calling headings to avoid the cells and 200 tonnes of Aloominum, as you call it, to smooth the ride. I don't really fancy doing that in Riveting Experience, my RV-7.
A bit too riveting for me.
Pete.
 
IFR with Budget Glass

Peter,

Appreciate your consideration, but since the topic of this thread was a failure of a glass cockpit in IFR operations, maybe you could give your 2 cents worth on IFR operations with this equipment. I understand that VFR failure of this stuff is a non-issue.

While you're at it, what was the low down on the 777 software problem?
 
Yukon said:
The airframe manufacturers know this technology is marginally reliable, and therefore install "round dial" backups in every installation.
Click to expand...

The airframe manufacturers know that vacuum based technology is marginally reliable, and therefore install whiskey compass backups in every installation...
 
Because...

Yukon said:
Now, can somebody remind me why we are choosing to install this type of technology in our recreational aircraft, and "low-bidder" equipment at that!
Click to expand...
Because even with the very few problems we have seen, it's far better than what we had before.

Walking is more reliable than your car, but you still drive.

Anything can break or fail. Plan for it, and you'll be ok, and while it's working, you'll be happier.
 
Old Timers Disease.

John,
I do not remember seeing a software problem on the B777. In actual fact the aircraft was excellent; ?twas the first Boeing I liked. After the DC-9, the B737-300 and B747-400 were just agricultural. Solid airframes, but dreadful ergonomics and cramped cockpits. The B777 cockpit was excellent and the flight controls (FBW) superb. But I digress.

Here?s my 2 cents worth; which is actually only US$0.15 due to the Aussie Dollar exchange rate, so you will have to make some allowance. I also stress, that I am not an Engineer, nor an FAA legal guru who knows what is ?required?. It is just an old pilot?s point of view; one that has had enough frights, thank you.

If I was to do an IFR RV, I would do it the way a mate, Gerry Elliott (B747 driver), has done his. This is NOT the only way as shown by plenty of others who?s excellent panels have graced this site. But it is expensive and heavy. See pic below.
? Two Buses. A main and a Standby. (Main bus switches are out of sight on the right, behind the roll bar in the pic of VH-SOA and a GNS480 now fitted above the radios.
? Two Batteries, one for the Main Bus and one for the Standby Bus; but probably only one Alternator.
? Two GRTs on the Main Bus, with dedicated GPS.
? Electric Standby AH, ASI and Altimeter on the Standby Bus.
? AUTOPILOT with ALT Hold. Best money spent.
? Cockpit lighting on both buses. A maglite in the mouth is not comfortable- so I am told.
? Heated Pitot. Surely only one; but then again, we don?t see the icing in Aus. that you see in North America.
? Clock for timing letdowns. (The ?Bus has a ?Chrono? Switch which brings up a Clock on the EFIS PFD. Would be great on the GRTs. You reading this Todd)
? Decent chart holder for Letdown Plates. You must be able to refer to the Plates at a glance.
?
There is probably more, but this is where I would start.

Just my 1.5 cents worth.
Pete.
PS. Don?t want to start a Pub fight, but I might have a few Cbs.
soaifrpanel3nl.jpg
 
Steam gauges in Certified installs

Yukon said:
Now, can somebody remind me why we are choosing to install this type of technology in our recreational aircraft, and "low-bidder" equipment at that!
The airframe manufacturers know this technology is marginally reliable, and therefore install "round dial" backups in every installation.
Click to expand...

The Manufactures aren't installing the backup steam gauges due to "marginally reliable EFIS systems", they *are* installing them because *none* (with one exception as noted below) of the certified EFIS systems (except the Chelton system) are certified as "primary".
 
Cars, Lawnmowers and Jetskis

Mickey,
The choice we are making here is not between driving and walking, or even flying and not flying.......We are talking about appropriate and cost efftective technology for our recreational airplanes.

Since you brought up cars, consider the BMW 7 series. BMW jumped onto the technology band wagon full speed with this one and have regret ever since. Electronic transmission, nav system, door locks, seat positioner yada, yada yada. The resale value of a 7 series BMW is about half that of it's analog counterparts. (Take a look at this link, you'll get a good laugh....all the topics we have been discussing, only in a BMW!)

http://townhall-talk.edmunds.com/direct/view/.ef21ed0



Mickey, ask yourself this question. Has a crank down window ever failed me?
Has a carburetted auto ever failed to get you to the airport? Choose your technology wisely if your life depends on it. Ask Kahuna!

Mickey, I am not a technophobe. I own every new gadget that comes on the market. I don't, however, use my lawnmower to shave, and I certainly wouldn't use my windows laptop to navigate my family to grandma's house.

Just this week, my jetski quit, for undetermined reasons, my skiboat wouldn't start because of an electrical problem, and my best buddy had a hard drive
failure on his PC. At this point in history, I would use cutting edge technology sparingly when life and limb depend on it.

Like KAhuna said, this stuff is not ready for prime time.
 
Last edited:
Reliability

aadamson said:
The Manufactures aren't installing the backup steam gauges due to "marginally reliable EFIS systems", they *are* installing them because *none* (with one exception as noted below) of the certified EFIS systems (except the Chelton system) are certified as "primary".
Click to expand...


Allan,

I don't know from primary or secondary certification. I just know Boeing has been installing the best of this stuff for the last 15 years, not toy RV glass, and still puts in round dial gyro, standard airspeed and altimeter, all independent of the air data bus. The standby ADI even has an ILS indicator built in.

This stuff quits often enough to justify a 100,000 dollars worth of backup equipment. Just imagine what kind of glass 10K will buy????
 
Computer software

Yukon said:
Great Byte article on software developement.
http://www.byte.com/art/9512/sec6/art1.htm
Click to expand...
John, That is a good article. As someone who has been working with computers and writing
software since the 70's I am very aware of the issues of software development. That's why I
said above that anything can break or fail, and you need to be able to handle that failure.

If I were outfitting my RV8 for IFR (I may upgrade at a later date) I'd be sure to have redundancy.

This is not a difficult thing to do in experimental aviation. You can install a nifty EFIS that may or
may not work, enjoy it's clear advantages when it is working, and fall back to another system if the
computer fails. Mike's story above shows that this is possible, not hard to do, and can even be
done with two different computer systems.

Assuming a really conservative 99% uptime for each EFIS, 99% uptime on two different systems is 99.99% uptime.
That's 0.01% downtime. Over a 2000 hour period, that's about 12 minutes. Add a third system, and
you're down to about 7 seconds of downtime in 2000 hours of flying. It may not be good enough for everyone,
but it's good enough for me.
 
You must log in or register to reply here.