If I have two AHRS can I get rid of my vacuum system?

[smwash02]

@RobertGary1Thanks for taking us along as you work through this with Garmin.

Your ice story and the flip cover likely have correlation in what the sensor was seeing as @takairsuggested.

We'll have to see what the RCA was, but if it really is a glitch in the airspeed reading that breaks the AHRS system, it wouldn't be far fetched to expect the same code to be shared across all their products. Thus, all would break under the same scenario.

You've 'inspired' me to grab a simple electric AI gyro that isn't Garmin (the rest of my stack is) to protect myself as I finalize my vacuum system removal. An AV-20 or AV-30 probably.

[takair]

4 minutes ago, smwash02 said:

@RobertGary1Thanks for taking us along as you work through this with Garmin.

Your ice story and the flip cover likely have correlation in what the sensor was seeing as @takairsuggested.

We'll have to see what the RCA was, but if it really is a glitch in the airspeed reading that breaks the AHRS system, it wouldn't be far fetched to expect the same code to be shared across all their products. Thus, all would break under the same scenario.

You've 'inspired' me to grab a simple electric AI gyro that isn't Garmin (the rest of my stack is) to protect myself as I finalize my vacuum system removal. An AV-20 or AV-30 probably.

Do a search on AV-20 and 30 here so you understand some potential pitfalls there as well. 

[takair]

2 hours ago, RobertGary1 said:

The automatic flip up cover failed and stayed closed.

Ahh!  I had one of those on my 150.  Great concept but it somehow managed to stay closed more than I liked.  I do agree though, that should manifest itself as a degrade, not loss of attitude.  I hope they figure this out....

[takair]

19 minutes ago, smwash02 said:

@RobertGary1Thanks for taking us along as you work through this with Garmin.

Your ice story and the flip cover likely have correlation in what the sensor was seeing as @takairsuggested.

We'll have to see what the RCA was, but if it really is a glitch in the airspeed reading that breaks the AHRS system, it wouldn't be far fetched to expect the same code to be shared across all their products. Thus, all would break under the same scenario.

You've 'inspired' me to grab a simple electric AI gyro that isn't Garmin (the rest of my stack is) to protect myself as I finalize my vacuum system removal. An AV-20 or AV-30 probably.

PM sent...

[DCarlton]

1 hour ago, takair said:

PM sent...

The Sandia AI that appears to also be marketed by King experienced an emergency AD.  I believe the Sandia unit is off the market.  The AV-30 now has reported issues (could be with the DG only; not sure); there are threads discussing AV30 software fixes.  I'm keeping my vacuum system now even if I install an electronic AI.  I considered the Sandia, then the AV30, and now I'm back to Garmin or perhaps just staying with steam gages for a while.  Problem with Garmin is I need to upgrade to a WAAS GPS or add another antenna.  

 

 

 

Edited May 20, 2021 by DCarlton

[LANCECASPER]

The Mid-Continent Lifesaver Gyro is still the gold standard in electric back-ups with plenty of built-in battery power to get back into VMC safely.

[Yetti]

Garmin software Engineer "what they hell did they do to this time?"

[N201MKTurbo]

I have been writing software to run machines for 40 years. My last employer liked to write software with so many safety checks in it that it would fault and shut down at the slightest hiccup. The customers complained that it was the most unreliable machine ever made. I went in and changed most of the faults so they just logged the fault and kept on running. The reliability of the machine improved greatly. 

I think Garmin might have the same idea and going to great lengths to make sure that they never show data unless they can guarantee that it is perfect. If they can't, they don't show anything. As was discussed here, unreliable data is much better than no data at all.

If I was the king of software at Garmin I would change it so if you lost some of the inputs, I would put a yellow X over the display with a message that the data is imperfect, but still show the best information I have. The message should say "Airspeed Error"

[RobertGary1]

I just spoke to Garmin. They did seem to have a proper level of concern. They are going to arrange for me to bring my plane to a Garmin dealer and if they cannot arrange it he said they may fly someone out. 

They do want to look at configuration but honestly if a configuration issue can go unnoticed for a year and then cause this it should be an AD in my opinion.

[Yetti]

39 minutes ago, N201MKTurbo said:

I have been writing software to run machines for 40 years. My last employer liked to write software with so many safety checks in it that it would fault and shut down at the slightest hiccup. The customers complained that it was the most unreliable machine ever made. I went in and changed most of the faults so they just logged the fault and kept on running. The reliability of the machine improved greatly. 

I think Garmin might have the same idea and going to great lengths to make sure that they never show data unless they can guarantee that it is perfect. If they can't, they don't show anything. As was discussed here, unreliable data is much better than no data at all.

If I was the king of software at Garmin I would change it so if you lost some of the inputs, I would put a yellow X over the display with a message that the data is imperfect, but still show the best information I have. The message should say "Airspeed Error"

Depending on the SCADA/ DCS we hook up to, there are usually data quality bits sent along with the data.   Then an informed decision can be made.   Our little planes are woefully under instrumented compared to say a Natural Gas compressor out in the field.

 

[EricJ]

1 hour ago, N201MKTurbo said:

I have been writing software to run machines for 40 years. My last employer liked to write software with so many safety checks in it that it would fault and shut down at the slightest hiccup. The customers complained that it was the most unreliable machine ever made. I went in and changed most of the faults so they just logged the fault and kept on running. The reliability of the machine improved greatly. 

I think Garmin might have the same idea and going to great lengths to make sure that they never show data unless they can guarantee that it is perfect. If they can't, they don't show anything. As was discussed here, unreliable data is much better than no data at all.

If I was the king of software at Garmin I would change it so if you lost some of the inputs, I would put a yellow X over the display with a message that the data is imperfect, but still show the best information I have. The message should say "Airspeed Error"

Fault Modes and Effects Analysis (FMEA) was part of all system, software, and hardware engineering when I was developing avionics at Honeywell for Boeing airplanes in the early 90s.  Their training at the time was quite good.   It just takes discipline and thoroughness and a consistent strategy to make things very good and manageable.  At least, that was the lesson I got from it, and I used that training and approach throughout my engineering career with, I think, very good results and much better output than I would have had otherwise.

Whenever I see something like this I just think somebody dropped the ball somewhere in the development process, and the review and testing processes were insufficient to catch it.   But, that seems to have been an evolution in development processes in the last thirty years, as evidenced also by the 737 Max issues, which I don't think would have been possible in the previous environment.  Now we have things like Agile, which seems to be pretty much the opposite approach to designing for reliability. 

Reliability does cost money in development time and testing, but not doing it can cost more in the longer run.   Management is often pressured for the shorter term benefits.

 

[RobertGary1]

3 minutes ago, EricJ said:

Fault Modes and Effects Analysis (FMEA) was part of all system, software, and hardware engineering when I was developing avionics at Honeywell for Boeing airplanes in the early 90s.  Their training at the time was quite good.   It just takes discipline and thoroughness and a consistent strategy to make things very good and manageable.  At least, that was the lesson I got from it, and I used that training and approach throughout my engineering career with, I think, very good results and much better output than I would have had otherwise.

Whenever I see something like this I just think somebody dropped the ball somewhere in the development process, and the review and testing processes were insufficient to catch it.   But, that seems to have been an evolution in development processes in the last thirty years, as evidenced also by the 737 Max issues, which I don't think would have been possible in the previous environment.  Now we have things like Agile, which seems to be pretty much the opposite approach to designing for reliability. 

Reliability does cost money in development time and testing, but not doing it can cost more in the longer run.   Management is often pressured for the shorter term benefits.

 

How do you feel about Boeing hiring software developers in India with no aviation experience for $12/hr on the 737 MAX?

-Robert

[Yetti]

14 minutes ago, EricJ said:

Fault Modes and Effects Analysis (FMEA) was part of all system, software, and hardware engineering when I was developing avionics at Honeywell for Boeing airplanes in the early 90s.  Their training at the time was quite good.   It just takes discipline and thoroughness and a consistent strategy to make things very good and manageable.  At least, that was the lesson I got from it, and I used that training and approach throughout my engineering career with, I think, very good results and much better output than I would have had otherwise.

Whenever I see something like this I just think somebody dropped the ball somewhere in the development process, and the review and testing processes were insufficient to catch it.   But, that seems to have been an evolution in development processes in the last thirty years, as evidenced also by the 737 Max issues, which I don't think would have been possible in the previous environment.  Now we have things like Agile, which seems to be pretty much the opposite approach to designing for reliability. 

Reliability does cost money in development time and testing, but not doing it can cost more in the longer run.   Management is often pressured for the shorter term benefits.

 

Just put it into the cloud, that should fix it.   I am still questioning the Colonial Pipeline mess if they had their control systems done right there should be no way to compromise Control on Operations.   For the business systems I would have just tossed the business computers and bought new before I paid ransom.

[LANCECASPER]

Although the problems are different, others are having challenges with the GI-275. I imagine that any new product as comprehensive as the GI-275 is going to have teething pains.

https://www.beechtalk.com/forums/viewtopic.php?f=21&t=194355

[EricJ]

13 minutes ago, RobertGary1 said:

How do you feel about Boeing hiring software developers in India with no aviation experience for $12/hr on the 737 MAX?

-Robert

I don't know what they did or are doing for implementers, but the results sure seemed different than they used to get.

There are a lot of high-paid domestic coders that produce crap, so that's not necessarily the difference.

 

[Yetti]

5 hours ago, RobertGary1 said:

How do you feel about Boeing hiring software developers in India with no aviation experience for $12/hr on the 737 MAX?

-Robert

All the steps that Eric outlined work well with coders no mater what they make.  Steps were skipped and tests were not not well designed.  Overall vision was missed.

My United buddy did do a runaway trim in the Sim.   He said it took both of them hauling on the yoke to keep it flying.   Can be done if you were in good shape.   Said it was like hauling a fish in and required good team work to not auger it.

 

Edited May 21, 2021 by Yetti

[GeeBee]

"Software glitch" is like "it must be the carburetor" of the 1970s. I don't think this case is that complex. We tend to blame things we don't understand happening on the most complex part of the machinery.

 

[Yetti]

12 hours ago, GeeBee said:

"Software glitch" is like "it must be the carburetor" of the 1970s. I don't think this case is that complex. We tend to blame things we don't understand happening on the most complex part of the machinery.

 

I have been doing software since 1984.  Operation IT since 2000.   Sensors and Software failures are not complex to me.  You have two devices running the same software doing the same thing at the same time.  Which means they are doing exactly what the programmer told them to do.   I do think there are two separate incidents going on at the same time.   The 175 product idea is a weird concept.  "Let's put all this information on a small round dial so people won't have to cut the panel."

 

[GeeBee]

No, but as you programmers say, "Garbage In, Garbage Out". The software can be just fine, but it's not getting the correct data, like a GPS ground speed which comes from a single source which is going to cause both units to fail....identically.

My point is this, before we blame the software, let's make sure the unit is correctly installed, and correctly configured. We have already discovered as I pointed out at the beginning of this thread, no airspeed input (the big red X was the clue). Now one has to figure out why the GPS ground speed back up did not work and I would look at the data input before the software. (Remember it was data input that kicked off this problem) Software is the last place I would look because it is well tested. There are several iterations of. the GI-275 software that can be loaded, but again that would be configuration error, not software defect.

I commented on this because when I was a kid, I used to work at an auto supply. When an engine was running badly, the first thing people would say is, "must be the carb". Most people would not know an idle tube from a main jet but when at a loss, they blame the thing they don't know or understand.

So let's make sure all the inputs are there and the configuration is correct before we go blaming the coders at Garmin.

 

 

[Will.iam]

16 hours ago, Yetti said:

All the steps that Eric outlined work well with coders no mater what they make.  Steps were skipped and tests were not not well designed.  Overall vision was missed.

My United buddy did do a runaway trim in the Sim.   He said it took both of them hauling on the yoke to keep it flying.   Can be done if you were in good shape.   Said it was like hauling a fish in and required good team work to not auger it.

 

When you get runaway nose up trim and fail to stop it (within 3 seconds will stall the aircraft with no elevator counter input) the elevator down force you are using to keep the airplane from stalling puts added pressure on the trim wheel and can in severe situations keep you from turning the trim wheel at all effectively locking it at that position. We were taught you have 3 options, if you have enough airspeed you can 1. letup on the elevator and allow the aircraft to zoom up this unloaded the horizontal stabilizer allowing you to rapidly turning the trim wheel that is now not as difficult to turn but you had to stop and push on the elevator before you bleed off too much speed and stalled it. At least this time you didn’t need as much elevator to counter and could work your way back to a trimmed flight condition. 2.  If you were slow you could add flaps and that would take some load off using the elevator as much thus allowing you to turn the trim wheel. Or 3. Do what they called the spiral of life and that was to change some of your up vector to a turning vector by rolling to 45 or even up to 60 degrees into a bank thus not having gravity bleed off your speed as fast and allowing you to unload the elevator to turn the trim wheel. I don’t hear people talk about the spiral of life technique anymore so I don’t know if they stopped teaching it or forgot about it. 

[RobertGary1]

3 hours ago, GeeBee said:

No, but as you programmers say, "Garbage In, Garbage Out". The software can be just fine, but it's not getting the correct data, like a GPS ground speed which comes from a single source which is going to cause both units to fail....identically.

My point is this, before we blame the software, let's make sure the unit is correctly installed, and correctly configured. We have already discovered as I pointed out at the beginning of this thread, no airspeed input (the big red X was the clue). Now one has to figure out why the GPS ground speed back up did not work and I would look at the data input before the software. (Remember it was data input that kicked off this problem) Software is the last place I would look because it is well tested. There are several iterations of. the GI-275 software that can be loaded, but again that would be configuration error, not software defect.

I commented on this because when I was a kid, I used to work at an auto supply. When an engine was running badly, the first thing people would say is, "must be the carb". Most people would not know an idle tube from a main jet but when at a loss, they blame the thing they don't know or understand.

So let's make sure all the inputs are there and the configuration is correct before we go blaming the coders at Garmin.

 

 

A configuration issue isn’t very calming though as how many other could be out there for years and not know they have a configuration issue until a critical time ?

In the software world we wouldn’t consider that a user error but a design error that such a configuration could be done 

[Yetti]

1 hour ago, Will.iam said:

When you get runaway nose up trim and fail to stop it (within 3 seconds will stall the aircraft with no elevator counter input) the elevator down force you are using to keep the airplane from stalling puts added pressure on the trim wheel and can in severe situations keep you from turning the trim wheel at all effectively locking it at that position. We were taught you have 3 options, if you have enough airspeed you can 1. letup on the elevator and allow the aircraft to zoom up this unloaded the horizontal stabilizer allowing you to rapidly turning the trim wheel that is now not as difficult to turn but you had to stop and push on the elevator before you bleed off too much speed and stalled it. At least this time you didn’t need as much elevator to counter and could work your way back to a trimmed flight condition. 2.  If you were slow you could add flaps and that would take some load off using the elevator as much thus allowing you to turn the trim wheel. Or 3. Do what they called the spiral of life and that was to change some of your up vector to a turning vector by rolling to 45 or even up to 60 degrees into a bank thus not having gravity bleed off your speed as fast and allowing you to unload the elevator to turn the trim wheel. I don’t hear people talk about the spiral of life technique anymore so I don’t know if they stopped teaching it or forgot about it. 

He said they reeled in the trim like you would a fish.   Push down on the elevator then as you let up the other guy would grab some trim.   Keep repeating.  They really had to work to make it work.

[Yetti]

3 hours ago, GeeBee said:

No, but as you programmers say, "Garbage In, Garbage Out". The software can be just fine, but it's not getting the correct data, like a GPS ground speed which comes from a single source which is going to cause both units to fail....identically.

My point is this, before we blame the software, let's make sure the unit is correctly installed, and correctly configured. We have already discovered as I pointed out at the beginning of this thread, no airspeed input (the big red X was the clue). Now one has to figure out why the GPS ground speed back up did not work and I would look at the data input before the software. (Remember it was data input that kicked off this problem) Software is the last place I would look because it is well tested. There are several iterations of. the GI-275 software that can be loaded, but again that would be configuration error, not software defect.

I commented on this because when I was a kid, I used to work at an auto supply. When an engine was running badly, the first thing people would say is, "must be the carb". Most people would not know an idle tube from a main jet but when at a loss, they blame the thing they don't know or understand.

So let's make sure all the inputs are there and the configuration is correct before we go blaming the coders at Garmin.

 

 

GPS never went offline.  see the other threads with the logs.  Separate the incidents.  They are separate routines in the program.

[rbp]

follow-up to this thread:
 

 

[GeeBee]

4 hours ago, Yetti said:

GPS never went offline.  see the other threads with the logs.  Separate the incidents.  They are separate routines in the program.

Yes, I saw that, I also saw a huge EPE in the GPS. That raises questions.